-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eBPF dataplane support for host postrouting masquerade to external services #8701
Comments
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.
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 |
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: