Learn Flannel - host-gw Backend & Alternatives

#Introduction

VXLAN is a reliable default backend, but not the only one. Depending on your host network and needs, other backends can provide higher performance, built-in encryption, or special integrations.

Episode 5 explores the host-gw backend, the performance favorite, then looks at wireguard and ipsec for encryption, ipip and udp for special cases, and extension, which requires extra caution due to a recent security advisory.

#The host-gw Backend

#How It Works: Direct Routing Without Encapsulation

Host gateway, or host-gw, works on the simplest principle: instead of wrapping packets, flanneld just adds routes to the kernel routing table. Packets from a Pod destined for a Pod on another node are forwarded directly to the destination node's host IP as native packets.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "host-gw"
    }
  }

With Type: host-gw, the flannel.1 interface is no longer created. All that exists are extra routes, so latency and throughput improve because there is no encapsulation overhead.

#Speed and Limitations

host-gw's advantage is clear: performance close to native because packets are not wrapped. But its requirements are strict: all nodes must be mutually reachable at the host networking layer. If nodes are on different VLANs or subnets with no route between them, host-gw cannot work. This is the main limit you must check before choosing this backend.

ip route | grep flannel

The output of ip route | grep flannel on the host-gw backend shows direct routes like 10.244.1.0/24 via 192.168.1.11 dev eth0, without a tunnel in between.

#The WireGuard and IPsec Backends

#Encrypting Traffic Between Nodes

When traffic between nodes must be encrypted, Flannel provides the wireguard and ipsec backends. WireGuard uses a modern protocol with high performance and an efficient kernel implementation. IPsec, through strongSwan, is a classic option widely used in enterprise environments.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "wireguard",
      "Port": 51820
    }
  }

WireGuard listens on UDP port 51820 by default. This port must be opened in the firewall as we will discuss in episode 15.

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

The IPsec backend uses IKEv2 and requires the strongSwan modules and tools available on the node. Both backends add security but reduce throughput compared to host-gw because of the encryption process.

#The ipip and udp Backends

#Special Use Cases

The ipip backend wraps packets with an IP-in-IP header, IP protocol number 4, without a UDP header. It is lighter than VXLAN but only runs on IPv4 networks and not on every cloud provider. The udp backend is a historical mode that uses user-space tunneling, is very slow, and is only relevant for networks that do not support VXLAN — best avoided unless forced.

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

Choose ipip only if you know exactly that your infrastructure allows IP protocol 4 across every hop.

#The extension Backend and Security Notes

#Connecting to External Networks

The extension backend lets flanneld call an external program for network setup, providing flexibility for vendor integrations. This flexibility comes with risk: because flanneld runs the external program with arguments derived from the configuration, a security hole is highly possible.

#CVE-2026-32241

In 2026, CVE-2026-32241 was identified as a command injection flaw in the extension backend. Unvalidated arguments can trigger arbitrary command execution. The right response is not to avoid extension forever, but three things: make sure your Flannel version is patched, restrict who can edit the kube-flannel-cfg ConfigMap, and avoid extension unless it is truly needed.

#Choosing the Right Backend

#Decision Criteria

The most important criteria in choosing a backend: your host network, your security requirements, and your performance priorities. If nodes are mutually reachable and security is not a hard requirement, host-gw is the fastest choice. If the host network is diverse, VXLAN is the most flexible choice. If traffic must be encrypted, wireguard is the best balance between security and speed.

kubectl -n kube-flannel get cm kube-flannel-cfg -o yaml | grep -A5 Backend

The kubectl -n kube-flannel get cm kube-flannel-cfg command confirms which backend the cluster is currently using. Note your choice because this decision will affect the production architecture in episode 21.

#Conclusion

Episode 5 expanded Flannel's backend options: host-gw for speed without encapsulation, wireguard and ipsec for encryption, ipip and udp for special cases, and extension, which requires caution because of CVE-2026-32241.

Key takeaways:

• host-gw forwards packets directly without encapsulation, provided nodes are mutually reachable.
• WireGuard uses UDP port 51820 and provides high-performance encryption.
• IPsec uses IKEv2 via strongSwan for enterprise environments.
• ipip uses IP protocol 4; udp is a very slow historical mode.
• The extension backend is vulnerable to CVE-2026-32241 and needs access restrictions.
• The backend choice depends on the host network, security requirements, and performance priorities.

In the next episode, episode 6, we will move into subnet management — how Flannel allocates a subnet per node from a large pool, the difference between the Kubernetes API and etcd datastores, and troubleshooting lease conflicts and inter-node synchronization. This is the foundation for understanding why every node has a unique address.