RE: UnNATing return packets

RE: UnNATing return packets

[Tim Saunders]

Your description describes exactly what is happening far better than
mine did. I am trying to do source routing so that all packets from
203.x.x.x go out on the same line as they came in on. Which is not via
the default route for outgoing packets. To give an example eth0 is
connected to routers A and B. The default route is to go out via router
A. Packets destined for 203.x.x.x will come in via router B so the
return packets need to go out via router B. When the routing decision is
made the return packets have a source address of: 192.168.0.1 so they
get routed via router A, then in post routing they get unNATed to a
203.x.x.x address. Thus DNAT of incoming connections cannot be used with
source routing.

Tim

> -----Original Message-----
> From: George Vieira [mailto:georgev@citadelcomputer.com.au] 
> Sent: 23 May 2003 10:19
> To: Tim Saunders; netfilter@lists.netfilter.org
> Subject: RE: UnNATing return packets
> 
> 
> Sorry, I can't understand your english explanation.
>  
> When the packets come in off the internet it hit the EXTernal 
> DEVice which the PREROUTING table converts the EXTernal 
> DESTination address to the INTernal DEVices DESTination 
> servers IP address..
>  
> EXTDEV=eth0
> DESTIP=203.x.x.x.x
> INTIP=192.168.0.1
>  
> iptables -A PREROUTING -t nat -i $EXTDEV -d $DESTIP -p tcp 
> --dport 80 -j DNAT --to $INTIP
>  
> it changes it at the PREROUTING because the routing table 
> won't know where 203.x.x.x is, but if it's changed before 
> routing then routing will know that 192.168.0.1 is inside on 
> eth1 and pass through the FORWARD chain and out via eth1.
>  
> Having said that, going out is the same thing except it's POSTROUTING.
>  
> So 192.168.0.1 responds to the packet and goes into eth1 
> which then passes through FORWARD and into POSTROUTING which 
> then says "hey 192.168.0.1 can't go out onto the net like 
> that" and translates it to the IP which matches the 
> ip_conntrack table that the original packets wanted to reach 
> ie. $DESTIP
>  
> this makes perfect sense..
>  
> If you can detail what your problem is a bit like about it'll 
> help me more to help you.. ;) I hope the above didn't bore 
> you either.. ;))
> 
> 	-----Original Message----- 
> 	From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk] 
> 	Sent: Fri 23-May-03 5:49 PM 
> 	To: netfilter@lists.netfilter.org 
> 	Cc: 
> 	Subject: RE: UnNATing return packets
> 	
> 	
> 	 
> 
> 

Re: UnNATing return packets

[Philip Craig]

Tim Saunders wrote:
> Your description describes exactly what is happening far better than
> mine did. I am trying to do source routing so that all packets from
> 203.x.x.x go out on the same line as they came in on. Which is not via
> the default route for outgoing packets. To give an example eth0 is
> connected to routers A and B. The default route is to go out via router
> A. Packets destined for 203.x.x.x will come in via router B so the
> return packets need to go out via router B. When the routing decision is
> made the return packets have a source address of: 192.168.0.1 so they
> get routed via router A, then in post routing they get unNATed to a
> 203.x.x.x address. Thus DNAT of incoming connections cannot be used with
> source routing.

A possible solution is to use the CONNMARK patch from p-o-m
in conjunction with mark based routing.  I haven't personally
used this method, but in theory it should work.  Set a mark
for the first packet of every connection based on the orignal
destination, and then restore the mark for subsequent packets
in the connection, and route based on that mark.  The following
untested rules are something like what you want:

iptables -t mangle -A PREROUTING -d 203.0.0.0/8 -m state --state NEW -j CONNMARK --set-mark 1
iptables -t mangle -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark

http://lartc.org/howto/lartc.netfilter.html has examples of
mark based routing.

-- 
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances

RE: UnNATing return packets

[George Vieira]

OK, well I haven't done source routing the way you'v done it as I've had the routers connected to the linux box via their own network cards.. ie ROUTER-A -> eth1   ROUTER-B -> eth2 etc.. but the theory should still be the same.

"When the routing decision is made the return packets have a source address of: 192.168.0.1 so they get routed via router A"
Are yoy saying this is what's happening or what you want to happen?? If this is what's happening and it should be going through Router B then isn't the problem iproute2 specific??

-----Original Message-----
From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk]
Sent: Friday, May 23, 2003 7:43 PM
To: George Vieira; netfilter@lists.netfilter.org
Subject: RE: UnNATing return packets


Your description describes exactly what is happening far better than
mine did. I am trying to do source routing so that all packets from
203.x.x.x go out on the same line as they came in on. Which is not via
the default route for outgoing packets. To give an example eth0 is
connected to routers A and B. The default route is to go out via router
A. Packets destined for 203.x.x.x will come in via router B so the
return packets need to go out via router B. When the routing decision is
made the return packets have a source address of: 192.168.0.1 so they
get routed via router A, then in post routing they get unNATed to a
203.x.x.x address. Thus DNAT of incoming connections cannot be used with
source routing.

Tim

> -----Original Message-----
> From: George Vieira [mailto:georgev@citadelcomputer.com.au] 
> Sent: 23 May 2003 10:19
> To: Tim Saunders; netfilter@lists.netfilter.org
> Subject: RE: UnNATing return packets
> 
> 
> Sorry, I can't understand your english explanation.
>  
> When the packets come in off the internet it hit the EXTernal 
> DEVice which the PREROUTING table converts the EXTernal 
> DESTination address to the INTernal DEVices DESTination 
> servers IP address..
>  
> EXTDEV=eth0
> DESTIP=203.x.x.x.x
> INTIP=192.168.0.1
>  
> iptables -A PREROUTING -t nat -i $EXTDEV -d $DESTIP -p tcp 
> --dport 80 -j DNAT --to $INTIP
>  
> it changes it at the PREROUTING because the routing table 
> won't know where 203.x.x.x is, but if it's changed before 
> routing then routing will know that 192.168.0.1 is inside on 
> eth1 and pass through the FORWARD chain and out via eth1.
>  
> Having said that, going out is the same thing except it's POSTROUTING.
>  
> So 192.168.0.1 responds to the packet and goes into eth1 
> which then passes through FORWARD and into POSTROUTING which 
> then says "hey 192.168.0.1 can't go out onto the net like 
> that" and translates it to the IP which matches the 
> ip_conntrack table that the original packets wanted to reach 
> ie. $DESTIP
>  
> this makes perfect sense..
>  
> If you can detail what your problem is a bit like about it'll 
> help me more to help you.. ;) I hope the above didn't bore 
> you either.. ;))
> 
> 	-----Original Message----- 
> 	From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk] 
> 	Sent: Fri 23-May-03 5:49 PM 
> 	To: netfilter@lists.netfilter.org 
> 	Cc: 
> 	Subject: RE: UnNATing return packets
> 	
> 	
> 	 
> 
> 

RE: UnNATing return packets

[George Vieira]

Sorry, I can't understand your english explanation.
 
When the packets come in off the internet it hit the EXTernal DEVice which the PREROUTING table converts the EXTernal DESTination address to the INTernal DEVices DESTination servers IP address..
 
EXTDEV=eth0
DESTIP=203.x.x.x.x
INTIP=192.168.0.1
 
iptables -A PREROUTING -t nat -i $EXTDEV -d $DESTIP -p tcp --dport 80 -j DNAT --to $INTIP
 
it changes it at the PREROUTING because the routing table won't know where 203.x.x.x is, but if it's changed before routing then routing will know that 192.168.0.1 is inside on eth1 and pass through the FORWARD chain and out via eth1.
 
Having said that, going out is the same thing except it's POSTROUTING.
 
So 192.168.0.1 responds to the packet and goes into eth1 which then passes through FORWARD and into POSTROUTING which then says "hey 192.168.0.1 can't go out onto the net like that" and translates it to the IP which matches the ip_conntrack table that the original packets wanted to reach ie. $DESTIP
 
this makes perfect sense..
 
If you can detail what your problem is a bit like about it'll help me more to help you.. ;) I hope the above didn't bore you either.. ;))

	-----Original Message----- 
	From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk] 
	Sent: Fri 23-May-03 5:49 PM 
	To: netfilter@lists.netfilter.org 
	Cc: 
	Subject: RE: UnNATing return packets
	
	
	 

RE: UnNATing return packets

[Tim Saunders]

The LOG rules I put in PREROUTING and POSTROUTING aren't logging
anything!?! But I also put one in FORWARD and its logging the packets as
coming from the address DNAT change the original packets to go to and
destined for the original source address. This must mean the SNAT has
been undone when the return packets hit the FORWARD chain but the DNAT
will not be undone until the packets reach the POSTROUTING chain. This
seems like a bug to me, I would expect all NAT to be undone before any
routing takes place ideally before the prerouting chain.

I guess I will have to think of another way to implement multiple
incoming lines. Any suggestions would be appreciated. My first idea is
to run a UML instance so incoming packets go through the main linux
instance and are routed to the UML instance that NATs them, thus on the
return they are unNATed by the UML and passed to the main instance for
source routing. It sounds really nasty...

Tim

> -----Original Message-----
> From: George Vieira [mailto:georgev@citadelcomputer.com.au] 
> Sent: 22 May 2003 22:49
> To: Tim Saunders; netfilter@lists.netfilter.org
> Subject: RE: UnNATing return packets
> 
> 
> In the prerouting stage I assume because that is the place 
> where DNAT takes place. Also take note they say "PREROUTING" 
> for a good reason though I haven't tested it with iproute2 
> and source routing but I assume they are in the same level. 
> Just remember that POSTROUTING is after the routing table.. 
> as it says in it's name (he he, gotta love those netfilter 
> developers)..
> 
> Add some LOG rules matching both sets of IPs your testing.
> 
> Thanks,
> ____________________________________________
> George Vieira
> Systems Manager
> georgev@citadelcomputer.com.au
> 
> Citadel Computer Systems Pty Ltd http://www.citadelcomputer.com.au
> 
> -----Original Message-----
> From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk]
> Sent: Friday, May 23, 2003 12:51 AM
> To: netfilter@lists.netfilter.org
> Subject: UnNATing return packets
> 
> 
> When a TCP connection goes through a netfilter firewall and 
> is SNATed and DNATed when do the return packets get unNATed? 
> i.e. a packet comes into the firewall from a client 
> requesting a tcp session, it is SNATed and DNATed and sent to 
> the server, the server sends and ack response, this gets to 
> the firewall. When do the original source and destination 
> addresses (from the session request packet) get put back? Is 
> it before or after routing?
> 
> I am trying to do source routing of return packets based on 
> the address the client originally thought it was targeting. 
> Packets come in destined for 80.5.94.150 and get DNATed to 
> 10.136.1.7 they also get SNATed to 10.136.1.254. I have a 
> rule to route packets from 80.5.94.150 via a different 
> routing table with a default route that goes out of a 
> differen't line to normal but the packets still get routed 
> out of the normal line. It is possible my source routing is 
> at fault. I am using the following commands:
> 
> I have added "15  sr1" to /etc/iproute2/rt_tables.
> 
> # ip rule add from 80.5.94.150 table sr1
> # ip route add default via 80.5.94.129 dev eth3 table sr1
> # ip route flush cache
> 
> One more thing that may be important eth3 has an IP in 
> 80.5.94.128/25 and an IP in 10.234.1.0/24 that goes to a 
> router for the other line.
> 
> Any help greatly appreciated.
> Tim Saunders
> 
> 

RE: UnNATing return packets

[George Vieira]

In the prerouting stage I assume because that is the place where DNAT takes place.
Also take note they say "PREROUTING" for a good reason though I haven't tested it with iproute2 and source routing but I assume they are in the same level. Just remember that POSTROUTING is after the routing table.. as it says in it's name (he he, gotta love those netfilter developers)..

Add some LOG rules matching both sets of IPs your testing.

Thanks,
____________________________________________
George Vieira
Systems Manager
georgev@citadelcomputer.com.au

Citadel Computer Systems Pty Ltd
http://www.citadelcomputer.com.au

-----Original Message-----
From: Tim Saunders [mailto:Tim.Saunders@aquilauk.co.uk]
Sent: Friday, May 23, 2003 12:51 AM
To: netfilter@lists.netfilter.org
Subject: UnNATing return packets


When a TCP connection goes through a netfilter firewall and is SNATed
and DNATed when do the return packets get unNATed? i.e. a packet comes
into the firewall from a client requesting a tcp session, it is SNATed
and DNATed and sent to the server, the server sends and ack response,
this gets to the firewall. When do the original source and destination
addresses (from the session request packet) get put back? Is it before
or after routing?

I am trying to do source routing of return packets based on the address
the client originally thought it was targeting. Packets come in destined
for 80.5.94.150 and get DNATed to 10.136.1.7 they also get SNATed to
10.136.1.254. I have a rule to route packets from 80.5.94.150 via a
different routing table with a default route that goes out of a
differen't line to normal but the packets still get routed out of the
normal line. It is possible my source routing is at fault. I am using
the following commands:

I have added "15  sr1" to /etc/iproute2/rt_tables.

# ip rule add from 80.5.94.150 table sr1
# ip route add default via 80.5.94.129 dev eth3 table sr1
# ip route flush cache

One more thing that may be important eth3 has an IP in 80.5.94.128/25
and an IP in 10.234.1.0/24 that goes to a router for the other line.

Any help greatly appreciated.
Tim Saunders

UnNATing return packets

[Tim Saunders]

When a TCP connection goes through a netfilter firewall and is SNATed
and DNATed when do the return packets get unNATed? i.e. a packet comes
into the firewall from a client requesting a tcp session, it is SNATed
and DNATed and sent to the server, the server sends and ack response,
this gets to the firewall. When do the original source and destination
addresses (from the session request packet) get put back? Is it before
or after routing?

I am trying to do source routing of return packets based on the address
the client originally thought it was targeting. Packets come in destined
for 80.5.94.150 and get DNATed to 10.136.1.7 they also get SNATed to
10.136.1.254. I have a rule to route packets from 80.5.94.150 via a
different routing table with a default route that goes out of a
differen't line to normal but the packets still get routed out of the
normal line. It is possible my source routing is at fault. I am using
the following commands:

I have added "15  sr1" to /etc/iproute2/rt_tables.

# ip rule add from 80.5.94.150 table sr1
# ip route add default via 80.5.94.129 dev eth3 table sr1
# ip route flush cache

One more thing that may be important eth3 has an IP in 80.5.94.128/25
and an IP in 10.234.1.0/24 that goes to a router for the other line.

Any help greatly appreciated.
Tim Saunders