On Tue, Sep 23, 2008 at 2:45 PM, Julius Volz <juliusv@xxxxxxxxxx> wrote: > 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. Ok, the SYN/ACK from the backend is logged as --cstate INVALID in PREROUTING and INPUT. This means that Netfilter thinks it doesn't belong to any connection, although it just SNATed the SYN to the backend correctly? Hmm... how can this be? 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
