From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alec Matusis" Date: Fri, 09 Mar 2007 03:13:12 +0000 Subject: RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs Message-Id: <017701c761f8$df6aa380$9e3fea80$@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 tried method 2 multiple times for 2 weeks, and it does not work. Perhaps someone can tell me what the problem is? Maybe I am missing some kernel option? How do I check that? Router box A (wan ip x.x.x.83 on eth0) : # iptables -t mangle -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination =20 MARK tcp -- 0.0.0.0/0 x.x.x.83 tcp dpt:5224 MARK set 0x3=20 Chain INPUT (policy ACCEPT) target prot opt source destination =20 Chain FORWARD (policy ACCEPT) target prot opt source destination =20 Chain OUTPUT (policy ACCEPT) target prot opt source destination =20 Chain POSTROUTING (policy ACCEPT) target prot opt source destination=20 #iptables -t filter -L -n Chain INPUT (policy ACCEPT) ... # ip ru l 0: from all lookup local=20 32765: from all fwmark 0x3 lookup 2=20 32766: from all lookup main=20 32767: from all lookup default # ip ro l t 2 default via 10.18.1.1 dev eth1 # cat /proc/sys/net/ipv4/ip_forward 1 checking a few things from A: # telnet 10.18.1.1 5224 Trying 10.18.1.1... Connected to 10.18.1.1 (10.18.1.1). Escape character is '^]'. --success. It means that box B is ready to accept connections on 5224 via LAN (it's INPUT chain's policy in filter is ACCEPT for simplicity). >From an outside client Outside client /> telnet x.x.x.83 5224 Trying x.x.x.83 ... telnet: connect to address x.x.x.83: Connection refused This suggests that the problem lies within box A. -----Original Message----- From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of ArcosCom Linux User Sent: Thursday, March 08, 2007 4:49 PM To: lartc@mailman.ds9a.nl Subject: RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs Are you sure? Take a look into: http://tldp.org/HOWTO/TransparentProxy-6.html Regards El Vie, 9 de Marzo de 2007, 1:05, Alec Matusis escribi=F3: > 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] > 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? 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@linux-ip.net] > Sent: Wednesday, March 07, 2007 8:24 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 > > 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> =3DO3sf > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 > _______________________________________________ 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