I have not considered bridge and ebtables yet. I assume I'd have to implement this in the "routing" box A. Is ebtables CPU-intensive? The goal of setting up this forwarding is to reduce the load on the router box A. Also, is it very surprising that there is no way to build a transparent proxy/router with standard iproute2 and iptables tools ONLY? It would seem that transparent forwarding of TCP connections to another machine is a very common task. From: Robb Bossley [mailto:robb.bossley@xxxxxxxxx] Sent: Thursday, March 08, 2007 9:13 AM To: Alec Matusis Subject: Re: routing TCP to another box preserving ORIGINAL client IPs Have you considered putting a bridge in and using ebtables? That might be what you are looking for. On 3/7/07, Alec Matusis < alecm at chatango.com> wrote: Hello Martin, 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. 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). 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. 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 in this case, the clients can connect, however the server on B sees only IP of BOX_A_ETH1, not the original client IPs. Regarding tproxy: I am currently running the TCP server on box A. I would like to move it to box B to reduce the load on A. Other services on A are bound to the same IP address as the server that I need to move, so simply moving that IP address to BOX_B_ETH0 is impossible. Box A has 2.6.11 kernel. Does tproxy install over netfilter? I am sort of scared to tamper with netfilter installation on A, since it is currently running live services. It it possible to implement this scenario: * the client thinks it's connected to Box A * Box A knows its connected to the client * Box A uses client's source address to initiate traffic to Box B * Box B thinks it's connected to client with advanced routing and iptables only? Thanks Alec. -----Original Message----- From: Martin A. Brown [mailto:martin@xxxxxxxxxxxx] Sent: Wednesday, March 07, 2007 8:24 PM To: Alec Matusis Cc: lartc@xxxxxxxxxxxxxxx Subject: Re: routing TCP to another box preserving ORIGINAL client IPs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings Alec, : My TCP clients connect to box A. I need to forward those : connections to a server on box B, such that the original client : IPs are visible to the server on B. : : Each box has two Ethernet ports. One port on each box is : connected to WAN, and they are cross-connected in a LAN via : remaining ports: : : ------------------- ------------------- : WAN -- |eth0 Box A eth1|---LAN---|eth1 Box B eth0| -- WAN : ------------------- ------------------- : : : Is there a way to do this with iproute2 and iptables tools ONLY? : Can you provide an example? Nothing in Google after more than a : week of searching. An additional requirement is to reduce the : load on box A as much as possible (I guess the server on B would : still have to reply to the client via A, not using B's own WAN : interface however..) You need to provide us a bit more information to help you figure out the right way to solve this problem. Why is DNAT not sufficient? Given your description, you should simply be able to: iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 If it were that simple, though, you shouldn't have spent a week looking for the answer. Do you have a TCP service on Box A which is providing services to the client across the WAN? If so, then you are looking for something called transparent proxying in the Linux networking world. You will want to examine the tproxy patches to iptables [0]. If you go with the transparent proxying method, it's helpful to remember: * the client thinks it's connected to Box A * Box A knows its connected to the client * Box A uses client's source address to initiate traffic to Box B * Box B thinks it's connected to client In either case, you are correct about routing. Box B must send its traffic back to Box A to forward back across the LAN. Good luck, - -Martin [0] http://www.balabit.com/products/oss/tproxy/ http://www.balabit.com/downloads/tproxy/linux-2.4/ - -- 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/) iD8DBQFF74/JHEoZD1iZ+YcRAlRaAJ4wf2fIc3oBJnGstjUBdpKWn1wOsQCbB2Ee 5Q7zrssGkA02Pq+298i9tEA= =O3sf -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
