Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Allow Docker Swarm only on the node network: TCP 2377 for manager control, TCP and UDP 7946 for membership and discovery, and UDP 4789 for the VXLAN overlay data path by default. Restrict all three to trusted Swarm-node addresses, keep Docker’s generated iptables chains, and place administrator rules in DOCKER-USER. Treat published service ports as a separate allowlist because routing mesh makes each published port reachable on every node, including nodes running no task.

The procedure below covers host firewalls based on iptables, UFW, and firewalld, explains the current nftables limitation, and gives verification and recovery steps. Docker documentation checked on 2026-10-15 notes that the data-path port can be changed, while port 7946 cannot; encrypted overlays may also require IP protocol 50.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Docker Swarm firewall ports at a glance

Every participating node must be able to exchange the control, membership, and overlay traffic shown below. The source range should be the smallest private or otherwise trusted network that contains all managers and workers. Do not expose the overlay port to the public internet: VXLAN on UDP 4789 has no authentication.

Traffic Protocol and port Where to allow it Purpose
Manager control plane TCP 2377 Between trusted Swarm nodes; especially managers and joining workers Cluster join and manager control traffic
Node discovery and membership TCP 7946 and UDP 7946 Between every manager and worker Gossip, discovery, and membership communication
Overlay/VXLAN data path UDP 4789 by default Between nodes that carry the overlay network Container-to-container and ingress overlay packets
Encrypted overlay traffic IP protocol 50 (ESP) Between nodes when encrypted overlays are enabled Encapsulated encrypted overlay packets
Published application ports Application-specific TCP or UDP ports From approved clients or load balancers to every node in the routing mesh External access to Swarm services

Port 4789 is configurable with docker swarm init --data-path-port. If the cluster was initialized with another UDP port, open that port instead of 4789 on every node and document it as part of the cluster configuration. Port 7946 is not configurable through that option.

#1 Best Overall
Sale
Compressed Air Duster,130000RPM Super Power Cordless Air Duster,Rechargeable Brushless Blower,3 Gear Adjustable Blower with LED Light,Dust Remover for Computer/House/Outdoor/Car
  • Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
  • With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
  • Wide Application: attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
  • Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
  • Economical &Reusable: Built durable materials with a long-lasting battery,our CAGIWIRU air duster it's a sustainable alternative to disposable air cans.

Understand which traffic the firewall must protect

Control and membership traffic

TCP 2377 carries manager control and join traffic. A worker does not need to accept manager control connections from arbitrary clients; it needs them from the manager addresses that administer the cluster. TCP and UDP 7946 are required among all participating nodes, not merely between managers. Blocking one direction can produce intermittent membership failures that look like a node or network problem.

Overlay data traffic

UDP 4789 carries VXLAN packets for overlay networks, including the ingress network used by routing mesh. Permit it only on the interface and source CIDR used for node-to-node traffic. A perimeter firewall should never forward untrusted internet traffic to this port. If encrypted overlays are enabled, allow ESP (IP protocol 50) between the same node addresses and apply a policy that rejects unencrypted packets arriving on the data-path port.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Published service traffic

A service published in ingress mode is not confined to the node that currently runs its task. The routing mesh listens on the published port on every node and forwards an incoming connection to an active task. Consequently, a client allowlist must be applied to every node, and every node’s perimeter exposure must be reviewed when a new port is published.

Inventory the cluster before writing rules

Firewall changes are safest when the cluster topology and service exposure are written down first. Perform this inventory on an administrative terminal and keep the results with the cluster runbook.

  1. Record every node’s private address, hostname, manager or worker role, and the interface that carries Swarm traffic. Confirm that all nodes can route to one another on that interface.
  2. Record the manager addresses that issue joins and administrative traffic. The manager control rule can then be limited to those addresses instead of an entire data-center network when the design permits.
  3. Check the data-path setting. On a manager, inspect the Swarm configuration and confirm whether initialization used a custom value for --data-path-port. Use that UDP value consistently on every host firewall.
  4. List every published port with docker service ls and docker service inspect SERVICE_NAME. Note whether each endpoint is TCP or UDP and which client networks should reach it.
  5. Identify whether any overlay network was created with encryption enabled. Encrypted overlays change the required protocol set because ESP must pass between nodes.
  6. Choose one firewall control point per host. Mixing a distribution frontend, hand-edited iptables rules, and an independent nftables policy without documenting precedence makes troubleshooting difficult.

Use a concrete internal range in examples, such as 10.20.0.0/24, only after confirming that it matches your environment. Replace it with the actual node CIDR; do not copy an example range into production.

How Docker’s iptables integration works

Docker creates and maintains several chains, including DOCKER-USER, DOCKER-FORWARD, DOCKER, DOCKER-BRIDGE, DOCKER-INTERNAL, DOCKER-CT, and DOCKER-INGRESS. Docker evaluates DOCKER-USER before its forwarding and ingress chains, making it the administrator’s insertion point for host policy.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #2
EVEO® Screen Cleaner Spray Kit (Streak-Free) TV Screen Cleaner for Smart TV, Lcd, LEd, Oled | Computer Screen Cleaner Spray and Wipe Microfiber Cloth - TV, Monitor, Laptop, iPad, Car - 6.7oz 1 Pack
  • Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
  • Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
  • Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
  • Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
  • Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth

Do not delete or flush Docker’s chains and do not disable Docker’s iptables management unless you replace every required networking rule yourself. Port publishing, bridge forwarding, NAT, and overlay connectivity can fail when those generated rules disappear. Rules accepted or rejected in DOCKER-USER may never reach later rules in FORWARD, so ordering matters.

Docker also requires IP forwarding for its default bridge configuration. When Docker enables forwarding, it may set the default FORWARD policy to DROP. Inspect the resulting policy with iptables-save rather than assuming a distribution default. A host firewall must allow the intended node traffic through the chain that actually receives it.

Build an iptables policy

1. Define the trusted node network

The following commands use shell variables to make the scope explicit. Run them with root privileges after setting the interface, node CIDR, and data-path port to your values.

SWARM_NET=10.20.0.0/24
SWARM_IFACE=eth1
DATA_PORT=4789

If managers and workers use separate networks, use separate source rules for each network or list the individual node addresses. Do not broaden the source to 0.0.0.0/0 for convenience.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

2. Allow node-to-node packets on the host input path

These rules cover connections addressed to the host itself, which is where manager, membership, and VXLAN packets commonly arrive. Insert an established-connection rule first so replies to permitted sessions are not discarded by a later default drop.

iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 2 -i ${SWARM_IFACE} -s ${SWARM_NET} -p tcp --dport 2377 -j ACCEPT
iptables -I INPUT 3 -i ${SWARM_IFACE} -s ${SWARM_NET} -p tcp --dport 7946 -j ACCEPT
iptables -I INPUT 4 -i ${SWARM_IFACE} -s ${SWARM_NET} -p udp --dport 7946 -j ACCEPT
iptables -I INPUT 5 -i ${SWARM_IFACE} -s ${SWARM_NET} -p udp --dport ${DATA_PORT} -j ACCEPT

For an encrypted overlay, add ESP from the node network:

Rank #3
Sale
BladeHawks RGB Gaming Mouse Pad Extra Large Extended 31.5x12 Inch-Black | LED mouse pad with 14 lighting modes, covers keyboard & mouse, anti-slip rubber base, waterproof surface, USB powered
  • 【Large size】:Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
  • 【LED backlight mouse pad】:Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
  • 【Anti-slip rubber base】:Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
  • 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
  • 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
iptables -I INPUT 6 -i ${SWARM_IFACE} -s ${SWARM_NET} -p 50 -j ACCEPT

Protocol 50 is not TCP or UDP; do not write it as a port rule. If your host uses multiple interfaces for node traffic, repeat the policy for each deliberately selected interface.

3. Put forwarding policy in DOCKER-USER

Packets destined for containers and ingress services traverse forwarding chains. Add the node-network allowances to DOCKER-USER as well when the host’s packet path requires it, and put the established rule before any restrictive rule.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
iptables -I DOCKER-USER 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I DOCKER-USER 2 -i ${SWARM_IFACE} -s ${SWARM_NET} -p tcp --dport 2377 -j ACCEPT
iptables -I DOCKER-USER 3 -i ${SWARM_IFACE} -s ${SWARM_NET} -p tcp --dport 7946 -j ACCEPT
iptables -I DOCKER-USER 4 -i ${SWARM_IFACE} -s ${SWARM_NET} -p udp --dport 7946 -j ACCEPT
iptables -I DOCKER-USER 5 -i ${SWARM_IFACE} -s ${SWARM_NET} -p udp --dport ${DATA_PORT} -j ACCEPT

Whether a particular packet needs both INPUT and DOCKER-USER treatment depends on its destination and the host’s routing. Observe counters with iptables -L INPUT -n -v, iptables -L DOCKER-USER -n -v, and iptables -L FORWARD -n -v while testing. Do not add a blanket drop to DOCKER-USER until all required Docker forwarding and return traffic has been explicitly allowed; an early drop can make every published service unreachable.

4. Restrict published ports

Assume a service publishes TCP 8443 and should be reachable only by clients in 192.0.2.0/24. Apply the policy to the externally facing interface on every Swarm node:

CLIENT_NET=192.0.2.0/24
PUBLIC_IFACE=eth0
iptables -I DOCKER-USER 1 -i ${PUBLIC_IFACE} -s ${CLIENT_NET} -p tcp --dport 8443 -j ACCEPT
iptables -I DOCKER-USER 2 -i ${PUBLIC_IFACE} -p tcp --dport 8443 -j DROP

The accept rule must precede the drop. Repeat the pair for each approved client network and for each published TCP or UDP port. If you need to distinguish the original published destination after Docker’s destination NAT, use conntrack’s original-destination matches, such as --ctorigdst and --ctorigdstport, and test the performance impact on a busy host. A broad rule on the post-NAT container address can accidentally affect unrelated services.

Using UFW without bypassing Docker policy

UFW is a frontend to netfilter, not a separate packet path. Basic host-input rules can express the Swarm node allowlist:

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #4
Sale
Vaydeer Wrist Rest for Keyboard and Mouse, Computer Ergonomic Wrist Support Pad, Soft Memory Foam Arm Cushion for Desk, Palm Hand Office Laptop Typing
  • 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
  • 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
  • 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
  • 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
  • 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
ufw default deny incoming
ufw allow from 10.20.0.0/24 to any port 2377 proto tcp
ufw allow from 10.20.0.0/24 to any port 7946 proto tcp
ufw allow from 10.20.0.0/24 to any port 7946 proto udp
ufw allow from 10.20.0.0/24 to any port 4789 proto udp

Use the custom data-path port in the last command when applicable. Add an ESP rule through the underlying iptables policy if encrypted overlays are used; UFW’s port syntax cannot represent protocol 50 as a UDP or TCP service.

UFW’s normal incoming rules do not automatically solve published-port exposure. Docker’s NAT and forwarding chains can process container traffic before a simple UFW rule, and routing mesh exposes the port on every node. Put the client allowlist and any explicit published-port denies in DOCKER-USER, then use ufw status numbered and iptables counters to confirm which layer is making the decision. Distribution packages differ in how UFW integrates with Docker, so validate after upgrades rather than relying on a remembered rule order.

Using firewalld

With firewalld, place the node interface or source network in a zone intended for trusted cluster traffic and add only the Swarm ports required by that zone. A source-based rich rule is narrower than assigning an entire interface to a permissive zone. For example:

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.20.0.0/24 port port=2377 protocol=tcp accept'
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.20.0.0/24 port port=7946 protocol=tcp accept'
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.20.0.0/24 port port=7946 protocol=udp accept'
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.20.0.0/24 port port=4789 protocol=udp accept'
firewall-cmd --reload

Replace the source and data-path values, and add an IPv6 policy if the Swarm uses IPv6. Firewalld’s zone rules still do not replace a published-port policy in DOCKER-USER. Keep Docker’s generated chains intact and check the active ruleset and counters after reload. Exact firewalld integration and persistence behavior is distribution-specific.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Current nftables limitation in Swarm mode

Docker documents its nftables backend as experimental and states that overlay-network rules have not been migrated. Therefore, nftables cannot be enabled while the Docker daemon is running in Swarm mode. A host may provide an iptables-nft compatibility command, but that does not mean Docker is using a native nftables Swarm implementation.

Follow the Docker Engine support statement for the release installed on each node. Do not migrate a working Swarm host to a hand-written native nftables policy merely because the operating system defaults to nftables for other services. If you must change firewall backends, test a disposable cluster, verify overlay and ingress traffic, and schedule a coordinated rollback path.

Best Value
Sale
Under Desk Cable Management Tray No Drill, Metal Mesh Cable Management Under Desk with Clamp Mount, 2 Hole Cable Tray with Wire Management and Cord Organizer for Home Office Standing Desk
  • 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
  • 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
  • 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
  • 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
  • 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Encrypted overlays: add ESP and reject plaintext

When an overlay network is created with encryption, permit IP protocol 50 between participating nodes in addition to the normal control and data-path ports. Docker’s example for refusing non-encrypted packets on the data-path port is:

iptables -I INPUT -m udp --dport 4789 -m policy --dir in --pol none -j DROP

Adapt the port, interface, source restriction, and insertion position to the host. The rule checks for an incoming UDP data-path packet with no IPsec policy and drops it. Place an explicit allow for valid encrypted traffic and node sources before any broad drop, and confirm the behavior with counters. A rule that omits the source or interface can affect other overlay designs on a multi-tenant host.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Persist and safely reload the policy

Commands entered with iptables are normally ephemeral. Use the persistence mechanism supplied by the Linux distribution, such as an iptables-save service, a systemd unit, or the firewall frontend’s permanent configuration. There is no single Docker-prescribed command that works on every distribution.

  1. Save a known-good ruleset only after testing both allowed and denied paths. Review it for accidental public accepts and for the presence of Docker’s chains.
  2. Arrange startup ordering so the base firewall is available before Docker creates networks, while ensuring Docker can recreate its own chains after a daemon restart.
  3. Reboot one non-critical worker first. Confirm that it rejoins, overlay networks pass traffic, and published services remain reachable according to the client allowlist.
  4. Test a manager restart separately. A firewall that blocks TCP 2377 can prevent a worker from rejoining even though existing tasks continue briefly.
  5. After a Docker Engine or distribution firewall update, rerun the verification checklist and inspect whether chain names, backend selection, or forwarding defaults changed.

Verification checklist

From an allowed node network

  • Test TCP 2377 to each manager address with a tool such as nc -vz MANAGER_IP 2377 during a controlled maintenance window.
  • Check TCP and UDP 7946 between every pair of participating nodes. UDP has no handshake, so combine packet captures or firewall counters with Swarm health observations.
  • Verify the configured UDP data-path port between nodes using counters or a packet capture on the Swarm interface. Seeing packets on the public interface is a sign of an incorrect route or scope.
  • Deploy a temporary service on an overlay network and confirm that tasks on different nodes can communicate.
  • Publish a test service and connect through the intended node addresses, including a node that does not host a local task.

From a denied network

  • Confirm that TCP 2377, TCP and UDP 7946, and the data-path UDP port are unreachable from an untrusted address.
  • Attempt each published application port from a client outside its allowlist. It should fail on every node, not only on nodes without a task.
  • Check that a denied packet increments the expected DOCKER-USER or host-firewall counter and that no later Docker rule accepts it first.

On each node

  • Run iptables-save and verify that Docker’s chains exist, the intended rules are in DOCKER-USER, and the FORWARD policy does not contradict the design.
  • Inspect docker node ls for a stable Ready or Active state and review daemon logs for membership, VXLAN, or IPsec errors.
  • Check interface and route selection with ip address and ip route. A correct rule on the wrong interface is functionally the same as no rule.
  • Record firewall counters before and after a test so a successful connection is tied to an observed rule rather than inferred from an application response.

Troubleshoot common failure patterns

Nodes appear down or workers cannot join

Check TCP 2377 from the worker to a manager and both protocols on 7946 in both directions. A rule that permits manager-to-worker traffic but blocks worker-to-manager replies can produce repeated join attempts. Verify that the manager advertisement address is reachable on the interface covered by the firewall rule.

Overlay services work on one node but not across nodes

Inspect UDP 4789, or the custom data-path port, between the specific nodes hosting the tasks. Confirm that an upstream security group or perimeter firewall is not filtering VXLAN. If encryption is enabled, check ESP and the policy match; allowing UDP alone is insufficient.

Published services are reachable from an unintended network

Check every node, including nodes with no local replica. Put the source allowlist and explicit deny in DOCKER-USER, verify rule order, and account for Docker’s destination NAT when matching the published port. Do not assume that a host-level UFW allowlist automatically governs ingress forwarding.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

All container networking broke after firewall changes

Compare iptables-save with a known-good copy. Look for flushed Docker chains, a blanket FORWARD drop inserted ahead of established traffic, or a disabled Docker iptables setting without replacement NAT and forwarding rules. Restore Docker’s chain management, restart the daemon during a maintenance window, and then reapply the administrator policy in DOCKER-USER.

Rules disappear after reboot or daemon restart

Install the distribution’s persistence service or configure the chosen frontend’s permanent rules. Verify startup ordering and test a reboot. A saved ruleset should not contain stale container addresses; use source networks and published-port policy rather than task IPs that change during rescheduling.

Choose a firewall approach deliberately

Decision axis Questions to answer Safe acceptance criteria
Docker Engine support Is the backend supported by the installed Engine release while the daemon runs in Swarm mode? The release documentation explicitly supports the selected backend; native nftables is not assumed for Swarm.
Network scoping Can rules restrict source CIDR and interface for node traffic? 2377, 7946, the data-path port, and ESP are limited to the node network.
Docker chain integrity Do Docker-generated chains remain managed by Docker? Administrator rules live in DOCKER-USER; generated NAT and forwarding chains are present.
Routing-mesh control Are published ports filtered on every node? Each application port has an explicit client or load-balancer allowlist and a tested deny path.
Persistence Will rules survive reboot and Docker restart? A documented distribution mechanism reloads policy and is tested on a worker before managers.
Observability Can operators see which rule accepted or dropped traffic? Counters, logs, and packet captures identify the chain and interface involved.

Hardening principles for production

  • Keep managers and workers on a private network or a VPN with authenticated, restricted membership. Firewall rules are not a substitute for network isolation.
  • Never publish 2377, 7946, or the VXLAN data-path port to the internet. Published application ports should be exposed through an intentional load-balancer or client allowlist.
  • Use separate CIDRs when control traffic and data traffic have different trust requirements, and bind rules to the correct interfaces.
  • Document every service publication, including protocol, client ranges, and the nodes covered by the routing mesh. Remove the firewall exception when the service is removed.
  • Monitor counters and daemon logs after changes. A rule that has never matched may indicate the wrong interface, route, address family, or chain.
  • Review the policy whenever Docker Engine, the Linux distribution, or the firewall frontend is upgraded; backend behavior and defaults can change.

Operational conclusion

A reliable Swarm firewall is an allowlist with two layers: tightly scoped node-to-node rules for TCP 2377, TCP and UDP 7946, the configured UDP data-path port, and ESP when required; plus separate client rules for every routing-mesh published port on every node. Preserve Docker’s chains, put custom forwarding controls in DOCKER-USER, avoid native nftables assumptions in Swarm mode, and verify both permitted and denied paths after every reload or upgrade.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.