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
bpf: host: also handle from-egress proxy traffic #30095
bpf: host: also handle from-egress proxy traffic #30095
Conversation
Once forward traffic for an egress proxy connection has traversed through cilium_host / cilium_net, we expect IPsec-marked packets to get handled by xfrm. But this currently conflicts with an iptables rule for the proxy's transparent socket, which then over-writes the mark: -A CILIUM_PRE_mangle -m socket --transparent -m comment --comment "cilium: any->pod redirect proxied traffic to host proxy" -j MARK --set-xmark 0x200/0xffffffff We can avoid this by adding an extra filter to this rule, so that it doesn't match IPsec-marked packets. Signed-off-by: Zhichuan Liang<gray.liang@isovalent.com>
After forward traffic for an egress proxy onnection has traversed through cilium_host / cilium_net, we expect IPsec-marked packets to get handled by xfrm. This currently conflicts with early demux, which matches the connection's transparent socket and assigns it to the packet: ``` // https://elixir.bootlin.com/linux/v6.2/source/net/ipv4/tcp_ipv4.c#L1770 int tcp_v4_early_demux(struct sk_buff *skb) { ... sk = __inet_lookup_established(net, net->ipv4.tcp_death_row.hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif, inet_sdif(skb)); if (sk) { skb->sk = sk; ... } ``` It then gets dropped in ip_forward(), before reaching xfrm: ``` // https://elixir.bootlin.com/linux/v6.2/source/net/ipv4/ip_forward.c#L100 int ip_forward(struct sk_buff *skb) { ... if (unlikely(skb->sk)) goto drop; ... } ``` To avoid this we disable early-demux in a L7 + IPsec config. Note that the L7 proxy feature needs to deal with similar troubles, as the comment for inboundProxyRedirectRule() describes. Ideally we would build a similar solution for IPsec, diverting traffic with policy routing so that it doesn't get intercepted by early-demux. Signed-off-by: Zhichuan Liang<gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
The from-host path already knows how to handle traffic that comes from the ingress proxy. Extend this logic to also cover traffic that originates from the egress proxy. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
/test |
@jschwinger233 I wonder if the socket mark condition here could be changed that it only applies to the forward path, and not to the return packet path? This change has caused issues with proxy return packets not getting to the proxy, likely due to the encryption mark being left on the packet after the return packets have been decrypted. This has caused issues like this: #27762 (comment). Currently fixing these by making sure the CT entry exists and has the So in summary I see two possible ways to remedy this:
|
@jrajahalme Sorry but I'm not sure how this PR causes #27762 which doesn't enable IPsec. Most changes this PR made is under the guard of Do you think it's possible that #32367 has something to do with it? |
See commit messages for details.