Learn Flannel - Firewall & Host Networking

#Introduction

All Flannel traffic eventually crosses the host network, and the host network has a firewall. If the tunnel port is closed, the network looks healthy in the documentation but connections between nodes always fail. This is one of the most confusing problems for new Flannel users.

Episode 15 secures the host path thoroughly: the ports that must be opened for each backend, how to pick the right host interface via --iface, and how to avoid IP conflicts on busy networks.

#Ports That Need to Be Opened

#VXLAN: UDP 4789

The default backend needs UDP port 4789 open between nodes. On a host with a firewall, open this port:

sudo ufw allow 4789/udp
sudo ufw reload

The sudo ufw allow 4789/udp command opens the VXLAN encapsulation port. Without it, Pod packets between nodes will not arrive even if the routes and leases are healthy.

#WireGuard and IPsec

WireGuard listens on UDP 51820, while IPsec uses port 500 for IKE and 4500 for NAT traversal. Open all of them according to the backend in use:

sudo ufw allow 51820/udp
sudo ufw allow 500/udp
sudo ufw allow 4500/udp

The ipip backend uses IP protocol number 4, which is not opened via a port but via a protocol permission. Make sure your firewall allows that protocol if you use ipip.

#Cloud Security Groups

#AWS, GCP, and Azure

Cloud providers block inter-node traffic at the security group or VPC firewall layer, not in the host iptables. The rules you must add follow the backend in use:

Source: 10.0.0.0/16
Protocol: UDP
Port: 4789
Description: Flannel VXLAN antar node

Every provider has its own syntax, but the pattern is the same: allow inter-node traffic for the Flannel backend port. Add rules for the node subnets, not for all public IPs.

#End-to-End Verification

After opening the ports, test directly between nodes:

nc -uvz <ip-node-lain> 4789

The output of nc -uvz <ip-node-lain> 4789 confirms that the UDP port is reachable between nodes. If it times out, check the security group and the host firewall in order.

#Picking the Right Host Interface

#The Multiple Interface Problem

Modern nodes have many interfaces: eth0 for the main network, eth1 for storage, docker0 for containers. flanneld guesses the interface from the default route, and that guess can be wrong. The result is a tunnel built on the wrong interface and inter-node traffic that fails.

#Solution: --iface or Iface in net-conf

Force the interface choice explicitly:

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan"
    },
    "Iface": "eth0"
  }

The flanneld --iface eth0 command can also be used as a flag. Pick the interface that really leads to the other host network, usually the one kubelet uses for control plane communication.

#Verifying the Choice

Check the IP used by the flannel.1 interface:

ip -d link show flannel.1
ip -4 addr show eth0

Compare the local value in ip -d link show flannel.1 with the eth0 IP. If they match, flanneld is using the correct interface.

#Avoiding IP Conflicts

#Conflicting CIDRs

IP conflicts happen when Flannel's network overlaps with an existing network, for example a VPC that already uses 10.244.0.0/16 for another service. The symptoms are chaotic: routes toward Pods also capture traffic from other services. Before installing, make sure Flannel's network does not conflict with the VPC CIDR or your on-premises network.

ip -4 addr show
ip route show

The ip route show command shows the networks currently used by the node. Compare them with the Network field in net-conf.json to make sure there is no overlap.

#Consistency Between Nodes

IP conflicts also occur when two clusters use the same Flannel network and are merged. Every cluster must use a unique CIDR. When planning multi-cluster, allocate a different CIDR for each, for example cluster A with 10.244.0.0/16 and cluster B with 10.245.0.0/16.

#Testing the Host Network Thoroughly

#From the Node Side

Besides checking ports, make sure the host networking is healthy overall. Check that all required interfaces are up, routes between nodes exist, and no route leaks from other networks are covering Flannel's routes.

ip -br addr show
ip route show | grep -E "10.244|default"

The output of ip -br addr show shows an interface summary, and the route command shows the Pod network along with the default route. Together they give you a complete picture of the host's condition.

#Document Ports per Cluster

Keep the list of ports and security groups in the documentation or in the infrastructure repository. When a new node is added or a cloud environment is replaced, this list becomes the guide that prevents firewall problems from recurring.

#Conclusion

Episode 15 secures Flannel's host path: opening the VXLAN, WireGuard, and IPsec ports in the firewall and security groups, picking the right host interface, and avoiding CIDR conflicts.

Key takeaways:

• VXLAN needs UDP 4789; WireGuard needs UDP 51820; IPsec needs UDP 500 and 4500.
• Cloud security groups must open the backend port between nodes.
• A wrong host interface is a classic cause of cross-node failure.
• Use the Iface field or the --iface flag to force the interface choice.
• Flannel's network must not overlap with existing CIDRs.
• Every cluster must use a unique CIDR to be safely merged.

In the next episode, episode 16, we will tune performance: performance optimization and MTU — computing the correct MTU with the 50-byte VXLAN overhead, avoiding fragmentation, and enabling direct routing for faster intra-subnet traffic.