Hello, everyone! I would like to solve the following problem. Btw, I''m terribly sorry about the pseudo-asciiart, but that''s all I can paint as a tropology. I''m hoping it''ll be enough. ----Internet---- | | | eth0 machine A routing+ipchains eth1 | ------------------ machine B So, given I''m running kernel 2.4.19 and using ipchains (don''t ask me why, but I''m bounded to this config), I would like to reroute everything that''s passing thru eth1 on machine A from the internal lan and has dport XXXX to the same port on machine B. The hole thing has to be completely transparent. I tried some "advanced routing" stuff, like marking those packets with fwmark and building a separate routing table for them, but alas. Notice that the two machines are on the same LAN segment. I''ve already tried also some userspace solutions, which didn''t work, like redir, tircproxy, transproxy, etc. but they didn''t work either, complaining abount not able to bind to non-local port. And yes (mr. Brown), I know about the /proc/sys/net/ipv4/ip_nonlocal_bind switch, listed in plorf.net/linux-ip/. Any suggestions (or help) are very much welcome. 10q for your time, Nickola
Hi there Nickola, : I would like to reroute everything that''s passing thru eth1 on machine : A from the internal lan and has dport XXXX to the same port on machine : B. It seems to me like you really want NAT, not PAT--especially if you are using multiple ports. Am I missing something here? : The hole thing has to be completely transparent. I tried some "advanced : routing" stuff, like marking those packets with fwmark and building a : separate routing table for them, but alas. Notice that the two machines : are on the same LAN segment. Problem is that the packets are handled specially in the local routing table (highest priority in the RPDB). I have not tried to use a rule of higher priority than rule 0, so I do not know what side effects that might have. : I''ve already tried also some userspace solutions, which didn''t : work, like redir, tircproxy, transproxy, etc. but they didn''t : work either, complaining abount not able to bind to non-local : port. And yes (mr. Brown), I know about the : /proc/sys/net/ipv4/ip_nonlocal_bind switch, listed in : plorf.net/linux-ip/. After you have done: # echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind can you do something like this: # nc -nlvv -p 3001 -s 77.77.77.77 Where 77.77.77.77 is an IP not in use anywhere on your box? If you were using redir, why doesn''t the following work: # redir --laddr=x.x.x.x --lport=993 --caddr=y.y.y.y --cport=993 --transproxy Just curious, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wed, 27 Nov 2002 13:20:58 -0600 (CST) "Martin A. Brown" <mabrown-lartc@securepipe.com> wrote:> Hi there Nickola,Hi again, Martin,> : I would like to reroute everything that''s passing thru eth1 on machine > : A from the internal lan and has dport XXXX to the same port on machine > : B. > > It seems to me like you really want NAT, not PAT--especially if you are > using multiple ports. Am I missing something here?Well, in fact I tried a solution with doing DNAT (i.e. destination NAT) in both directions - from the client to the server and vice versa. With tcpdump I saw that packet are going both diorections, but the client application refused to accept them. I''m talking about irc. I mean there weren''t any errors, given by the client, just silence. :)> : The hole thing has to be completely transparent. I tried some "advanced > : routing" stuff, like marking those packets with fwmark and building a > : separate routing table for them, but alas. Notice that the two machines > : are on the same LAN segment. > > Problem is that the packets are handled specially in the local routing > table (highest priority in the RPDB). I have not tried to use a rule of > higher priority than rule 0, so I do not know what side effects that might > have.Ehm, yes, I tried with priorities 200 and the default ones, which ip rule puts at the end - i.e. around 32765 and below.> : I''ve already tried also some userspace solutions, which didn''t > : work, like redir, tircproxy, transproxy, etc. but they didn''t > : work either, complaining abount not able to bind to non-local > : port. And yes (mr. Brown), I know about the > : /proc/sys/net/ipv4/ip_nonlocal_bind switch, listed in > : plorf.net/linux-ip/. > > After you have done: > > # echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind > > can you do something like this: > > # nc -nlvv -p 3001 -s 77.77.77.77 > > Where 77.77.77.77 is an IP not in use anywhere on your box?Yes, I can, but do I have a way to check that someone is indeed listening on this port? Except locally, I mean. Beacuse netcat is binding to the port with no complaints.> If you were using redir, why doesn''t the following work: > > # redir --laddr=x.x.x.x --lport=993 --caddr=y.y.y.y --cport=993 --transproxyNo, it yells target: connect: Invalid argument
Nickola, : Well, in fact I tried a solution with doing DNAT (i.e. destination NAT) in : both directions - from the client to the server and vice versa. With tcpdump : I saw that packet are going both diorections, but the client application : refused to accept them. I''m talking about irc. I mean there weren''t any : errors, given by the client, just silence. :) OK! Now I''m confused. Why would you need to do DNAT in both directions? I thought you said you were using ipchains? If you have iptables, DNAT is really the answer.....you would DNAT anything inbound from machine A to machine B. Then let the connection tracking take care of the rest. If you are using DNAT both directions, I''m guessing I don''t quite understand your intended configuration or you don''t quite understand DNAT. Either way, if you can use DNAT, read up on how to use DNAT at http://iptables-tutorial.frozentux.net/ and try again. -- OR -- <snip> : Ehm, yes, I tried with priorities 200 and the default ones, which ip rule : puts at the end - i.e. around 32765 and below. So, we are agreed....policy based routing probably isn''t the answer in this case. : > After you have done: : > # echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind : > can you do something like this: : > # nc -nlvv -p 3001 -s 77.77.77.77 : > Where 77.77.77.77 is an IP not in use anywhere on your box? : Yes, I can, but do I have a way to check that someone is indeed : listening on this port? Except locally, I mean. Beacuse netcat is : binding to the port with no complaints. You should be able to use "netstat -ntl" to display the listening sockets on your system. : > If you were using redir, why doesn''t the following work: : > # redir --laddr=x.x.x.x --lport=993 --caddr=y.y.y.y --cport=993 --transproxy : No, it yells : target: connect: Invalid argument The poor thing is in pain--that''s why it''s yelping! I don''t have any problem with the above command line....are you certain that transproxy support was compiled into your redir? -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wed, 27 Nov 2002 14:40:01 -0600 (CST) "Martin A. Brown" <mabrown-lartc@securepipe.com> wrote:> OK! Now I''m confused. Why would you need to do DNAT in both directions?Nope, I do NOT want DNAT. That''s just a result of my helpless efforts to do the thing. :)> I thought you said you were using ipchains? If you have iptables, DNAT is > really the answer.....you would DNAT anything inbound from machine A to > machine B. Then let the connection tracking take care of the rest.Yes, correct, I''m using ipchains, and no, I can''t use iptables. If I could, which is not the case, I would probably just redirect the connections to the other host.> So, we are agreed....policy based routing probably isn''t the answer in > this case.Yes, indeed it seems so, at least to my poor understanding.> : Yes, I can, but do I have a way to check that someone is indeed > : listening on this port? Except locally, I mean. Beacuse netcat is > : binding to the port with no complaints. > > You should be able to use "netstat -ntl" to display the listening sockets > on your system.OK, I''ll try that.> : > If you were using redir, why doesn''t the following work: > : > # redir --laddr=x.x.x.x --lport=993 --caddr=y.y.y.y --cport=993 --transproxy > : No, it yells > : target: connect: Invalid argument > > The poor thing is in pain--that''s why it''s yelping! I don''t have any > problem with the above command line....are you certain that transproxy > support was compiled into your redir?Do I need to enable it explicitly? It didn''t seem to me that way, because there''s no switch to turn on any features. Just a plain makefile, in which I couldn''t find any transproxy clues. And anyway, it starts just fine, but begins to print those error messages when I''m connecting to the port it''s listening on. But this is another scenario - there I''m redirecting all TCP connections directed to port XXXX anywhere in the world to a local port, where sits redir.
Hello, On Wed, 27 Nov 2002, Nickola Kolev wrote:> So, given I''m running kernel 2.4.19 and using ipchains (don''t > ask me why, but I''m bounded to this config), I would like to > reroute everything that''s passing thru eth1 on machine A > from the internal lan and has dport XXXX to the same port > on machine B. The hole thing has to be completely transparent. > I tried some "advanced routing" stuff, like marking those packets > with fwmark and building a separate routing table for them, > but alas. Notice that the two machines are on the same LAN segment.Yes, marking the packets for routing purposes is a solution, sort of: # Mark XXX traffic ipchains -A input -p TCP -s CLIENT_NET/24 -d 0.0.0.0/0 PORT_XXX -m 1 -j ACCEPT # Check first for routes to directly attached networks ip rule add prio 50 table main # Port XXX to universe is rerouted to host B ip rule add prio 100 fwmark 1 table 100 ip route add default via HOST_B dev eth1 table 100 May be the problem is that host B can not accept this traffic? You need some measures: 1. In host A stop ICMP redirects generated for routes on shared meduims: echo 0 > /proc/sys/net/ipv4/conf/*/send_redirects Without such settings, host A will redirect clients directly to host B, for any traffic 2. Add Transparent Proxy support in box B to accept locally the client''s traffic. You can look how the Squid tproxy works: each packet is delivered to the configured local IP:PORT but this service can obtain the original DADDR:DPORT of the packet.> NickolaRegards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/