Thanks Martin. My rp_filter was disabled on server box B: # cat /proc/sys/net/ipv4/conf/all/rp_filter 0 I got it to work however, along the lines you were suggesting like this: On Box A: iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 on box B, I finally found ACK packets. I do not know why I could not see them before. It turns out that box B was trying to route ACKs via its WAN interface eth0 directly to the client, in some sort of asymmetric router fashion. This did not work. So on B, I routed ACKs back to A: #ip rule add from $BOX_B_ETH1 lookup 3 #ip route add default via $BOX_A_ETH1 table 3 Now it works, with DNAT on A and without anything else. I have 1 small follow-up question: 1) when I add custom rules like #ip rule add from $BOX_B_ETH1 lookup 3 it does not take effect for at least 1 minute, perhaps 2-3. Why is that? This is confusing, since it makes one think that the rule does not work, while in reality it just has not taken effect. Thanks a lot for your help, Alec. > -----Original Message----- > From: Martin A. Brown [mailto:martin@xxxxxxxxxxxx] > Sent: Thursday, March 08, 2007 8:40 PM > To: Alec Matusis > Cc: lartc@xxxxxxxxxxxxxxx > Subject: RE: routing TCP to another box preserving ORIGINAL > client IPs > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alec, > > : I tried implementing DNAT as you indicated: > : > : iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 > : > : After that, I can see SYN packets arriving on BOX_B_ETH1, having > : the original client's IP. > > OK, that means DNAT + routing on your BOX_A is working correctly. > > : Only half of the connection gets established after this: I cannot > : see ACK packets from box B anywhere (neither on BOX_B_ETH0, nor > : on BOX_A_ETH0). > > This is where your problem lies now. You need to find out why the > SYN (which you said was transmitted to BOX_B_ETH1) is not getting > accepted by this IP stack. > > * reverse path filtering (net.ipv4.conf.*.rp_filter) > * packet filtering rules on BOX_B? > > : I think the reason is that since box A never sends a SYN packet > : itself, it never classifies the connection as ESTABLISHED, so all > : further traffic gets rejected. It's still a mystery to me what > : happens to SYN packets from be in this scenario however. > > BOX_A will never have a socket in ESTABLISHED state. BOX_A will > have a state entry in the /proc/net/ip_conntrack table. Examine > /proc/net/ip_conntrack after sending a SYN to BOX_B. > > : It turns out that I have to supplement DNAT with SNAT for this to > work > : correctly. > : On box A: > : iptables -t nat -i eth0 -p tcp -m tcp --dport $SERVER_PORT -j DNAT > : --to-destination $BOX_B_ETH1 > : iptables -t nat -A POSTROUTING -d $BOX_B_ETH1 -p tcp -m tcp --dport > : $SERVER_PORT -j SNAT --to-source $BOX_A_ETH1 > > If this works, then I think you problem may be reverse path > filtering. > > : in this case, the clients can connect, however the server on B > : sees only IP of BOX_A_ETH1, not the original client IPs. > > [ tproxy recommendation snipped ] > > - -Martin > > - -- > Martin A. Brown > http://linux-ip.net/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) > > iD8DBQFF8OURHEoZD1iZ+YcRAoenAJ9XCZyMf4K7TVCTs28bzIGeu3EEewCg07Cw > Spk8a+T/th+ESyPN4hSTjYs= > =k+5E > -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
