Hi, I already mentioned this on netdev and lvs-devel a while ago, but it's a pretty specifc Netfilter-internals question, so I might have better luck getting an answer here. Generally, I was trying to get IPVS to work together with netfilter SNAT. Currently, IPVS actively prevents the packets it manipulates from being processed by Netfilter NAT in POSTROUTING by returning NF_STOP from a POSTROUTING hook. So I just removed this IPVS hook function that stops the further POSTROUTING processing. I then added a normal SNAT rule to POSTROUTING like this: $ iptables –t nat –A POSTROUTING –o eth1 –j SNAT –-to <snat_ip> Without any IPVS, SNAT works without any problems. As expected, only the first (SYN) packet of a connection appears on the POSTROUTING chain. However, with packets passing first through IPVS, the behavior gets weird: The first SYN and the SYN/ACK of a TCP connection through IPVS do _not_ traverse the NAT chain in POSTROUTING at all (verified by LOG target, which produces no output), so their source is not rewritten (resulting just in normal IPVS DNAT). However, the client's ACK response to the SYN/ACK _does_ finally appear in this table and only this third packet is SNATed correctly. The backend server then replies with an RST, since it doesn't know a connection from the SNATed source. The packet trace on the director looks like this: CIP: client IP VIP: virtual service IP DIP: director (load balancer) IP RIP: real server (backend) IP Packet 1: ======= CIP => VIP SYN (eth0, before IPVS) CIP => RIP SYN (eth1, after IPVS) Packet 2: ======= RIP => CIP SYN/ACK (eth1, before IPVS) VIP => CIP SYN/ACK (eth0, after IPVS) Packet 3: ======= CIP => VIP ACK (eth0, before IPVS) DIP => RIP ACK (eth1, after IPVS) - this is the first successfully SNATed packet! Why? Packet 4: ======= RIP => DIP RST - real server doesn't know this connection from the DIP Any ideas why the first packets never appear in the POSTROUTING chain but the ACK does? I do not understand this, since IPVS injects all handled packets into the OUTPUT chain, whereafter they should traverse POSTROUTING... maybe someone with more understanding of Netfilter can shed some light on this? Thanks, 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
