You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplified scenario involving multi-interface nodes, that works in iptables mode but doesn't in eBPF mode. There doesn't seem to be a way to allow SNAT / MASQ of traffic originating from subnet 192.168.6.0/24 to calico node with destinations to external services in the node's 10.0.0.0/24 subnet.
In iptables mode this can be accomplished with something like this:
iptables-nft -A FORWARD -i wg0 -j ACCEPT
iptables-nft -A FORWARD -o wg0 -j ACCEPT
iptables-nft -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Expected Behavior
When running the eBPF dataplane, there should be a mechanism to define postrouting masquerade rules for external destinations.
Current Behavior
ping 10.0.0.2 (k8s-lb) from 192.168.6.1 (tunnel gateway for internal clients)
ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_req=1 ttl=63 time=2.85 ms
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1002ms
rtt min/avg/max/mdev = 2.858/2.858/2.858/0.000 ms
tcpdump on 192.168.6.1
IP 192.168.6.1 > 10.0.0.2: ICMP echo request, id 20348, seq 1, length 64
IP 10.0.0.2 > 192.168.6.1: ICMP echo reply, id 20348, seq 1, length 64
IP 192.168.6.1 > 10.0.0.2: ICMP echo request, id 20348, seq 2, length 64
tcpdump on k8s-control-2 (10.0.0.5)
wg0 In IP 192.168.6.1 > k8s-lb: ICMP echo request, id 20348, seq 1, length 64
eth0 Out IP k8s-control-2 > k8s-lb: ICMP echo request, id 20348, seq 1, length 64
eth0 In IP k8s-lb > k8s-control-2: ICMP echo reply, id 20348, seq 1, length 64
wg0 Out IP k8s-lb > 192.168.6.1: ICMP echo reply, id 20348, seq 1, length 64
wg0 In IP 192.168.6.1 > k8s-lb: ICMP echo request, id 20348, seq 2, length 64
eth0 Out IP 192.168.6.1 > k8s-lb: ICMP echo request, id 20348, seq 2, length 64
tcpdump on k8s-lb (10.0.0.2)
eth0 In IP k8s-control-2 > k8s-lb: ICMP echo request, id 20348, seq 1, length 64
eth0 Out IP k8s-lb > k8s-control-2: ICMP echo reply, id 20348, seq 1, length 64
eth0 In IP 192.168.6.1 > k8s-lb: ICMP echo request, id 20348, seq 2, length 64
eth0 Out IP k8s-lb > 192.168.6.1: ICMP echo reply, id 20348, seq 2, length 64
Oddly enough, the first ping gets a response, but the second and subsequent are not SNAT'ed / MASQ'ed at the k8s-control-2 node for the k8s-lb (10.0.0.2) destination and thus are un-routable at k8s-lb back to the original source ip.
Only tried this in IPv4 while waiting for #8636, but presumably IPv6 deployments share the same issue.
Possible Solution
None identified in eBPF mode.
Steps to Reproduce (for bugs)
provision a multi-node k8s cluster or single node cluster with access to a separate host in the same subnet
enable wireguard tunnel / secondary interface on calico node
across the wireguard tunnel / secondary interface, attempt to ping another node / external host on the cluster subnet (outside of cluster service CIDR)
observe that SNAT / MASQ is not applied consistently to the traffic
Context
It doesn't seem like there is a way to enable postrouting rules at the host level for traffic with destinations != cluster services.
Your Environment
Calico Cluster Version: v3.27.2
Calico Cluster Type: k8s,bgp,kubeadm
Orchestrator version: Kubernetes v1.29.2
Operating System and version: Ubuntu 22.04.4 LTS
The text was updated successfully, but these errors were encountered:
Since you have listed wg0 as a device to be managed by calico ebpf, you essentially opted out from using iptables. The core principle of the ebpf dataplane is that packets mostly travel from device to device without going through the Linux net stack and thus bypassing iptables as well.
name: FELIX_BPFL3IFACEPATTERN
value: "wg0"
Atm moment, disappointingly, I do not think there is a simple solution to your problem. If you were to remove wg0 from the list of devices managed by calico, it would work for incoming traffic, but most likely not for returning echo replies. And you would not get policies on wg0.
Perhaps you could make the k8s-control-2 to be a gateway for 192.168.6.0/24 or make the 192.168.6.1 part of you 10.x.x.x network and do the MASQ?
Yeah @tomastigera that is kind of what I expected. Those are good suggestions outside of hosting the destination side of the tunnel on non-calico nodes.
How about with calico-node -bpf nat set - is there currently a mechanism for user-defined persistent bpf nat rules?
Excited to see how eBPF support evolves across the ecosystem. Thanks for all of the hard work / support for the community!
Simplified scenario involving multi-interface nodes, that works in iptables mode but doesn't in eBPF mode. There doesn't seem to be a way to allow SNAT / MASQ of traffic originating from subnet 192.168.6.0/24 to calico node with destinations to external services in the node's 10.0.0.0/24 subnet.
In iptables mode this can be accomplished with something like this:
Expected Behavior
When running the eBPF dataplane, there should be a mechanism to define postrouting masquerade rules for external destinations.
Current Behavior
ping 10.0.0.2 (k8s-lb) from 192.168.6.1 (tunnel gateway for internal clients)
tcpdump on 192.168.6.1
tcpdump on k8s-control-2 (10.0.0.5)
tcpdump on k8s-lb (10.0.0.2)
Oddly enough, the first ping gets a response, but the second and subsequent are not SNAT'ed / MASQ'ed at the k8s-control-2 node for the k8s-lb (10.0.0.2) destination and thus are un-routable at k8s-lb back to the original source ip.
Only tried this in IPv4 while waiting for #8636, but presumably IPv6 deployments share the same issue.
Possible Solution
None identified in eBPF mode.
Steps to Reproduce (for bugs)
calico-node DaemonSet:
calico IPPool:
Context
It doesn't seem like there is a way to enable postrouting rules at the host level for traffic with destinations != cluster services.
Your Environment
Calico Cluster Version: v3.27.2
Calico Cluster Type: k8s,bgp,kubeadm
Orchestrator version: Kubernetes v1.29.2
Operating System and version: Ubuntu 22.04.4 LTS
The text was updated successfully, but these errors were encountered: