[LARTC] transparent PAT

[LARTC] transparent PAT

[Nickola Kolev]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] transparent PAT

[Martin A. Brown]

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™3 --caddr=y.y.y.y --cport™3 --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/

Re: [LARTC] transparent PAT

[Nickola Kolev]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

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 --transproxy

No, it yells 

target: connect: Invalid argument


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] transparent PAT

[Martin A. Brown]

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™3 --caddr=y.y.y.y --cport™3 --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/

Re: [LARTC] transparent PAT

[Nickola Kolev]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] transparent PAT

[Julian Anastasov]

	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.

> Nickola

Regards

--
Julian Anastasov <ja@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/