From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alec Matusis" Date: Fri, 09 Mar 2007 00:05:14 +0000 Subject: RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs Message-Id: <013b01c761de$9d8a9ed0$d89fdc70$@com> List-Id: References: <004301c76137$40fdaa10$c2f8fe30$@com> In-Reply-To: <004301c76137$40fdaa10$c2f8fe30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org 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@gmail.com]=20 Sent: Thursday, March 08, 2007 9:13 AM To: Alec Matusis Subject: Re: [LARTC] routing TCP to another box preserving ORIGINAL client IPs Have you considered putting a bridge in and using ebtables?=A0 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:=20 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=20 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=20 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:=20 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=20 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=20 scared to tamper with netfilter installation on A, since it is currently running live services. It it possible to implement this scenario: =A0=A0* the client thinks it's connected to Box A =A0=A0* Box A knows its connected to the client=20 =A0=A0* Box A uses client's source address to initiate traffic to Box B =A0=A0* Box B thinks it's connected to client with advanced routing and iptables only? Thanks Alec. -----Original Message-----=20 From: Martin A. Brown [mailto:martin@linux-ip.net] Sent: Wednesday, March 07, 2007 8:24 PM To: Alec Matusis Cc: lartc@mailman.ds9a.nl=20 Subject: Re: [LARTC] 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=20 : 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=20 : remaining ports: : :=A0=A0=A0=A0=A0=A0=A0=A0 -------------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= ------------------- : WAN -- |eth0=A0=A0 Box A=A0=A0 eth1|---LAN---|eth1=A0=A0 Box B=A0=A0 eth0= | -- WAN :=A0=A0=A0=A0=A0=A0=A0=A0 -------------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= -------------------=20 : : : 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=20 : 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=20 the right way to solve this problem.=A0=A0Why is DNAT not sufficient? Given your description, you should simply be able to: =A0=A0iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 If it were that simple, though, you shouldn't have spent a week=20 looking for the answer. Do you have a TCP service on Box A which is providing services to the client across the WAN?=A0=A0If so, then you are looking for something called transparent proxying in the Linux networking world.=20 You will want to examine the tproxy patches to iptables [0]. If you go with the transparent proxying method, it's helpful to remember: =A0=A0* the client thinks it's connected to Box A =A0=A0* Box A knows its connected to the client=20 =A0=A0* Box A uses client's source address to initiate traffic to Box B =A0=A0* Box B thinks it's connected to client In either case, you are correct about routing.=A0=A0Box B must send its traffic back to Box A to forward back across the LAN.=20 Good luck, - -Martin [0] http://www.balabit.com/products/oss/tproxy/ =A0=A0=A0=A0 http://www.balabit.com/downloads/tproxy/linux-2.4/=20 - -- 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=3DO3sf -----END PGP SIGNATURE----- _______________________________________________=20 LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc