Learn Flannel - Traffic Management (iptables/nftables)

#Introduction

Not all traffic stays inside the cluster. There is traffic from Pods to the internet, to other nodes, or to services outside the subnet. This is where traffic management works.

Episode 7 dissects the masquerade and forwarding rules Flannel manages, why br_netfilter became mandatory since kubeadm 1.30, and the choice between the iptables and nftables traffic manager modes. After this episode, you will be able to read the rules installed in your cluster and know what they mean.

#Masquerade and Forwarding

#Why IP Masquerade Is Needed

Pod IP addresses, like 10.244.1.5, are not routable outside the host network. Without special handling, packets from a Pod heading to the internet get dropped because return traffic doesn't know how to get back. Masquerade solves this by replacing the packet's source IP with the host IP as the packet leaves.

Flannel installs masquerade rules on the NAT table when enabled via the --ip-masq flag. This ensures all traffic leaving the Pod subnet uses the node IP as its source.

iptables -t nat -L -n | grep FLANNEL

The output of iptables -t nat -L on the FLANNEL chain shows the MASQUERADE rules, which are only active for source IPs in 10.244.0.0/16 with destinations outside that network.

#Forwarding Between Namespaces

Besides NAT, Flannel also makes sure forwarding is allowed. The Linux kernel blocks forwarding between interfaces by default. Flannel enables it through sysctl, because without forwarding, Pod packets would never move from the bridge to the VXLAN interface or eth0.

sysctl net.ipv4.ip_forward

A value of 1 from sysctl net.ipv4.ip_forward means the kernel forwards packets between interfaces. This is an absolute prerequisite for every routing-based CNI.

#br_netfilter and Kubeadm 1.30

#Why This Setting Is Critical

Since kubeadm 1.30, the sysctl requirements around bridges have become stricter. The br_netfilter module makes packets passing through a bridge also go through the netfilter filters, including iptables. Without it, packets between Pods on the same node can bypass kube-proxy rules, causing connections to drop mysteriously.

sysctl net.bridge.bridge-nf-call-iptables

The sysctl net.bridge.bridge-nf-call-iptables command must return a value of 1. If not, load the module and set the sysctl as you did in episode 0.

#Verify on All Nodes

Because kubelet and CNI run on every node, make sure this setting is consistent across all nodes. The best way is through a sysctl configuration file or files in /etc/sysctl.d so it persists across reboots.

echo 'net.bridge.bridge-nf-call-iptables = 1' | sudo tee /etc/sysctl.d/99-flannel.conf
sudo sysctl --system

#Traffic Manager: iptables vs nftables

#Two Engines, One Purpose

Flannel offers two implementations for managing traffic rules: iptables, which has existed since the beginning, and nftables, iptables' modern successor with better syntax and performance. Both produce the same behavior; the difference is in the netfilter engine used.

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

The TrafficManager field with the value nftables makes Flannel install its rules via nft. The alternative value is iptables, which has also been the default for most previous releases.

#Choosing the Right Mode

The main considerations are team policy and tooling compatibility. If your team uses nftables to manage host firewalls, nftables mode keeps everything consistent. If you still rely on iptables and legacy tooling, staying on iptables is fine. What matters is that you know which mode is in use so you're not confused during debugging.

nft list ruleset | grep -i flannel

The output of nft list ruleset shows objects whose names contain flannel if the traffic manager uses nftables.

#Seeing the Rules in the Field

#A Thorough Inspection

To understand traffic management fully, inspect the NAT and filter tables together:

iptables -t nat -L -n -v
iptables -t mangle -L -n -v

The pkts and bytes columns in the output show how often each rule is used. This data is useful for proving that masquerade is actually processing outbound traffic.

#Why You Should Care

Traffic management is the part that causes the most confusion in the field. Pods fail to reach the internet even though routes and the backend are healthy — the cause is usually here: masquerade not active, forwarding disabled, or br_netfilter not loaded. With the understanding from this episode, you already have a map to investigate.

#Conclusion

Episode 7 completed the picture of Flannel traffic: masquerade for outbound traffic, forwarding between namespaces, the mandatory br_netfilter since kubeadm 1.30, and the iptables or nftables traffic manager choice.

Key takeaways:

• Masquerade changes a Pod's source IP to the host IP for traffic leaving the cluster.
• Kernel forwarding must be enabled so packets can move between interfaces.
• br_netfilter with bridge-nf-call-iptables must be active since kubeadm 1.30.
• TrafficManager can be set to iptables or nftables in net-conf.json.
• The chosen mode determines which commands you use to inspect the rules.
• Connectivity problems to the outside world usually have their root in this layer.

In the next episode, episode 8, we will test Flannel's integration with Kubernetes Service — the division of labor between Flannel for pod networking and kube-proxy for Service, how the iptables or ipvs modes work, and the practice of testing ClusterIP and NodePort on top of Flannel.