On Tue, Sep 23, 2008 at 2:33 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > On Tuesday 2008-09-23 06:13, Julius Volz wrote: >> >>Any ideas why the first packets never appear in the POSTROUTING chain >>but the ACK does? > > It is not the first packet of the TCP connection that will show up > in the nat table, it is the first packet of the *tracked* connection, > which may not match the boundary of the classical connection. > > Like... > -t raw -A PREROUTING -p tcp --tcp-flags SYN,ACK,RST,FIN SYN -j NOTRACK > -t raw -A PREROUTING -p tcp --tcp-flags SYN,ACK,RST,FIN SYN,ACK -j NOTRACK > > Will cause the exact behavior that the 3rd packet that would match > --tcp-flags SYN,ACK,RST,FIN ACK will be the one showing up in the nat table. Thanks, that makes sense! I have no other iptables rules, by the way. I just found out a minute ago why the SYN didn't enter the chain in my case. When you send packets through IPVS, you send them to the virtual IP that is configured on the load balancer so that IPVS can pick them up on LOCAL_IN. However, there is also a Netfilter NAT hook for LOCAL_IN (nf_nat_fn), which marks the packet as "already seen". This is mark is checked later in POSTROUTING and the chain is not traversed then... just disabling that LOCAL_IN hook in net/ipv4/nf_nat_standalone.c for testing leads to correct SNATing of the SYN, but the reply from the backend does not seem to get un-SNATed in PREROUTING for some reason. It gets picked up by IPVS from FORWARD, but still has the SNAT IP as its destination, so IPVS doesn't recognize it. > As such, it might be worth looking at the LOGMARK target in Xtables-addons > which will print out whether such a connection even exists/has been untracked. > Alternatively, if you don't mind typing lots, > > -t mangle -A PREROUTING -m conntrack --ctstate INVALID \ > -j LOG --log-prefix "this won't shop up in nat: " > -t mangle -A PREROUTING -m conntrack --ctstate UNTRACKED \ > -j LOG --log-prefix "neither will this: " Thanks, this is interesting and I'll use that for further debugging! Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
