RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs

["Alec Matusis" <alecm@chatango.com>]

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@linux-ip.net]
> Sent: Thursday, March 08, 2007 8:40 PM
> To: Alec Matusis
> Cc: lartc@mailman.ds9a.nl
> Subject: RE: [LARTC] 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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc