Brandon Cazander <brandon.cazan...@multapplied.net> wrote: > Hopefully that's enough detail to replicate this issue. I have the full > environment set up for both working and non-working kernel versions, so > please let me know if there's anything else I can provide.
No need, this reproduces easily with this two-line ruleset: -t nat -A PREROUTING -d 192.168.7.20/32 -i eth0 -j DNAT --to-destination 192.168.8.1 -t mangle -A PREROUTING -p tcp -m tcp --dport 8080 -j TPROXY --on-port 9876 --on-ip 0.0.0.0 --tproxy-mark 0x1/0x1 AFAIU the problem is this: SYN: 1. -j TPROXY finds listen sk, redirects to it 2. DNAT takes place (iphdr(skb)->daddr is mangled). 3. tcp stack puts request sk into ehash table. Note that the ehash entry uses the updated/dnatted address. ACK: 1. -j TPROXY finds no established or request socket since it uses iph->daddr but ehash contains dnatted-to address ... so we redirect to the listener socket. Before the ehash change, for skb to listen sk the kernel used to search both the listener socket request queue and the ehash table, using the iphdr daddr (which at this point is the DNAT'ed address). So this used to work because this returns the request sk. After the ehash change we only check syn cookie and will then emit a reset. Eric, AFAICS the only solution for this is to extend TPROXY and obtain the lookup saddr/daddr info from the conntrack entry instead of the ip headers, which should make this work again. Do you agree? Any other suggestions? Thanks!
