NAT problem with iptables...

NAT problem with iptables...

[Marian Stepka]

Hi Guys;

I'm fighthing almost second day with NAT problem. I need to translate
local IP to 'normal' Inet IPs. I set up one box which have two NIC
cards. One side is connected to local LAN with IP 192.168.0.x and other
side is connected to 'copy' of firewall which is used in production. I
would like to simulate situation as on Inet. I don't want to change IP
of firewall which I would like to debug. I need to setup iptables on
linux translating box as follows:

192.168.0.230 <-> 64.124.175.104
192.168.0.231 <-> 64.124.175.105
192.168.0.232 <-> 208.184.248.9


--
*IN ROOT WE TRUST*
Marian Stepka <mailto:stepka@tris.sk>

Re: NAT problem with iptables...

[Antony Stone]

On Wednesday 11 September 2002 3:43 pm, Marian Stepka wrote:

> Hi Guys;
>
> I'm fighthing almost second day with NAT problem. I need to translate
> local IP to 'normal' Inet IPs. I set up one box which have two NIC
> cards. One side is connected to local LAN with IP 192.168.0.x and other
> side is connected to 'copy' of firewall which is used in production. I
> would like to simulate situation as on Inet. I don't want to change IP
> of firewall which I would like to debug. I need to setup iptables on
> linux translating box as follows:
>
> 192.168.0.230 <-> 64.124.175.104
> 192.168.0.231 <-> 64.124.175.105
> 192.168.0.232 <-> 208.184.248.9

iptables -A PREROUTING -t nat -d 192.168.0.230 -j DNAT --to 64.124.175.104
iptables -A PREROUTING -t nat -d 192.168.0.231 -j DNAT --to 64.124.175.105
iptables -A PREROUTING -t nat -d 192.168.0.232 -j DNAT --to 208.184.248.9
iptables -A POSTROUTING -t nat -s 64.124.175.104 -j SNAT --to 192.168.0.230
iptables -A POSTROUTING -t nat -s 64.124.175.105 -j SNAT --to 192.168.0.231
iptables -A POSTROUTING -t nat -s 208.184.248.9 -j SNAT --to 192.168.0.232

plus the appropriate FORWARDing rules for whatever protocols you want to 
allow to/from these addresses.

Antony.

-- 

You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.

 - Frank Skinner

Re: NAT problem with iptables...

[Antony Stone]

On Thursday 12 September 2002 1:31 am, Marian Stepka wrote:

> Hi Antony;
>
> > iptables -A PREROUTING -t nat -d 192.168.0.230 -j DNAT --to 64.124.175.104
> > iptables -A PREROUTING -t nat -d 192.168.0.231 -j DNAT --to 64.124.175.105
> > iptables -A PREROUTING -t nat -d 192.168.0.232 -j DNAT --to 208.184.248.9
> > iptables -A POSTROUTING -t nat -s 64.124.175.104 -j SNAT --to
> > 192.168.0.230
> > iptables -A POSTROUTING -t nat -s 64.124.175.105 -j SNAT --to
> > 192.168.0.231
> > iptables -A POSTROUTING -t nat -s 208.184.248.9 -j SNAT --to 192.168.0.232
>
> I'd try this solution but it working only partly. When I log what
> happening, only destination address is translated. When I try to ping
> f.g. 192.168.0.230 it is tranlated to 64.124.175.104 but id does not
> goes back. So ping is not successful. But I can ping card directly from
> translating box. So network seems to be set up properly.

Does the destination machine know how to route back to the source machine 
correctly ?   (See my sig below, which quite by chance came out with this one 
for this email !)

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

NAT problem with iptables

[Cliff Stanford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have just built a Linux (Fedora 7) box to act as an ADSL router and
NAT for two private (10.0.0.0) networks.

The problem I have is that I have a PBX running Asterisk behind the
router which must connect using iax2 to a box outside of the network.
Similarly, the remote switchboard must be able to connect using iax2 to
my nat'ed PBX.

My entire iptables setup at he moment looks like this:

[root@gw ~]# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    LOG        udp  --  anywhere             anywhere            udp
dpt:iax state NEW LOG level warning prefix `INPUT (NEW): '
2    REJECT     udp  --  anywhere             anywhere            udp
dpt:iax state NEW reject-with icmp-port-unreachable
3    LOG        udp  --  anywhere             anywhere            udp
dpt:iax LOG level warning prefix `INPUT: '

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
[root@gw ~]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    LOG        udp  --  anywhere             anywhere            udp
dpt:iax LOG level warning prefix `NAT: '
2    DNAT       udp  --  anywhere             anywhere            udp
dpt:iax to:10.20.30.14
3    DNAT       tcp  --  anywhere             anywhere            tcp
dpt:http to:10.20.30.33
4    DNAT       tcp  --  anywhere             anywhere            tcp
dpt:ms-wbt-server to:10.20.30.74
5    DNAT       tcp  --  anywhere             anywhere            tcp
dpt:printer to:10.20.30.63
6    DNAT       tcp  --  anywhere             anywhere            tcp
dpt:x11 to:10.20.30.74

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    SNAT       all  --  anywhere             anywhere
to:217.125.3.73

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
[root@gw ~]#

I would expect all NEW UDP packets coming in on port 4569 (iax) to be
redirected to 10.20.30.14 after being logged as NAT: and subsequent
packets to be redirected via conntrack but not to be logged.

In practice, I am getting a continual stream of the INPUT: log messages:

Oct  7 18:48:35 gw kernel: INPUT (NEW): IN=atm0 OUT=
MAC=aa:aa:03:00:00:00:08:00 SRC=194.70.36.201 DST=217.125.3.73 LEN=40
TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=4569 DPT=4569 LEN=20
Oct  7 18:49:15 gw last message repeated 4 times
Oct  7 18:50:16 gw last message repeated 7 times
Oct  7 18:51:35 gw last message repeated 7 times

The output from conntrack is:

[root@gw ~]# conntrack -L -s 194.70.36.201
udp      17 23 src=194.70.36.201 dst=217.125.3.73 sport=4569 dport=4569
packets=1332 bytes=53280 [UNREPLIED] src=217.125.3.73 dst=194.70.36.201
sport=4569 dport=4569 packets=0 bytes=0 mark=0 use=1
[root@gw ~]# conntrack -L -d 194.70.36.201 -s 10.20.30.14
udp      17 122 src=10.20.30.14 dst=194.70.36.201 sport=4569 dport=4569
packets=701 bytes=36932 src=194.70.36.201 dst=217.125.3.73 sport=4569
dport=1024 packets=491 bytes=28742 [ASSURED] mark=0 use=1

The second row is the outbound IAX which is working fine.  So it
definitely seems that this rule is not working:

iptables -A PREROUTING -p udp -m udp --dport 4569 -j DNAT
- --to-destination 10.20.30.14

I assume I'm missing something and hope someone on this list can see
what it is.  I'd be very grateful.

Apologies for the long lines and thanks in anticipation.

Cliff.
- --
Cliff Stanford
Might Limited                           +44 845 0045 666 (Office)
Suite 67, Dorset House                  +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCRU7fNTx9pWyKfwRAjCEAKCzJhGCBo6S0nihOnGXfHYOZm2qlgCdEE1m
5qSLGOpzFu8d/xBi0QaLDBE=
=mKh0
-----END PGP SIGNATURE-----

Re: NAT problem with iptables

[Pascal Hambourg]

Hello,

Cliff Stanford a écrit :
> 
> I have just built a Linux (Fedora 7) box to act as an ADSL router and
> NAT for two private (10.0.0.0) networks.
> 
> The problem I have is that I have a PBX running Asterisk behind the
> router which must connect using iax2 to a box outside of the network.
> Similarly, the remote switchboard must be able to connect using iax2 to
> my nat'ed PBX.
> 
> My entire iptables setup at he moment looks like this:
> 
> [root@gw ~]# iptables -L --line-numbers

Note : Input and output interfaces are not shown. Use the "-v" option or 
- better IMHO - use iptables-save which displays all the tables in a 
single command in a more readable format.

> I would expect all NEW UDP packets coming in on port 4569 (iax) to be
> redirected to 10.20.30.14 after being logged as NAT: and subsequent
> packets to be redirected via conntrack but not to be logged.

So would I.

> In practice, I am getting a continual stream of the INPUT: log messages:
> 
> Oct  7 18:48:35 gw kernel: INPUT (NEW): IN=atm0 OUT=
> MAC=aa:aa:03:00:00:00:08:00 SRC=194.70.36.201 DST=217.125.3.73 LEN=40
> TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=4569 DPT=4569 LEN=20
> Oct  7 18:49:15 gw last message repeated 4 times
> Oct  7 18:50:16 gw last message repeated 7 times
> Oct  7 18:51:35 gw last message repeated 7 times
> 
> The output from conntrack is:
> 
> [root@gw ~]# conntrack -L -s 194.70.36.201
> udp      17 23 src=194.70.36.201 dst=217.125.3.73 sport=4569 dport=4569
> packets=1332 bytes=53280 [UNREPLIED] src=217.125.3.73 dst=194.70.36.201
> sport=4569 dport=4569 packets=0 bytes=0 mark=0 use=1
> [root@gw ~]# conntrack -L -d 194.70.36.201 -s 10.20.30.14
> udp      17 122 src=10.20.30.14 dst=194.70.36.201 sport=4569 dport=4569
> packets=701 bytes=36932 src=194.70.36.201 dst=217.125.3.73 sport=4569
> dport=1024 packets=491 bytes=28742 [ASSURED] mark=0 use=1
> 
> The second row is the outbound IAX which is working fine.  So it
> definitely seems that this rule is not working:
> 
> iptables -A PREROUTING -p udp -m udp --dport 4569 -j DNAT
> - --to-destination 10.20.30.14

I think it is a bit more complicated. The incoming packets logged in the 
INPUT chain are dropped by REJECT, so they should not create a conntrack 
entry.

A possible explanation may be the following.
The remote box sends a continuous stream of UDP packets. The first 
packet was received before the ruleset was installed but after the 
conntrack was loaded, so a conntrack entry was created with no NAT, and 
does not expire because of the continuous stream.
Anyway this happened before your Asterisk sent the first packet, because 
you can see that the outgoing SNATed stream has an implicit source port 
NAT (original source port 4569 is replaced with 1024) in order to avoid 
a clash with an existing conntrack entry, actually the one related to 
the incoming stream.

Clear the conntrack table by any means and see what happens.

Re: NAT problem with iptables

[Cliff Stanford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Hambourg wrote:

> A possible explanation may be the following.
> The remote box sends a continuous stream of UDP packets. The first 
> packet was received before the ruleset was installed but after the 
> conntrack was loaded, so a conntrack entry was created with no NAT, and 
> does not expire because of the continuous stream.

Thank you!  You hit the nail right on the head!

> Clear the conntrack table by any means and see what happens.

I cleared it with conntrack -F and you were absolutely right.  It's now
working as expected.  I knew it had to be my naivety but I couldn't see
what I was doing wrong.

Out of interest, I can't seem to find a syntax that conntrack -D likes;
is there a tutorial for it anywhere or any docs better than the man page?

Thanks again, Pascal, for that speedy and helpful response.

Regards,
Cliff.
- --
Cliff Stanford
Might Limited                           +44 845 0045 666 (Office)
Suite 67, Dorset House                  +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCT0XfNTx9pWyKfwRAsvbAJ9701Tsw6S/KiXOFkXiDEjQPYetwwCgnsEO
tdtJvqrbnz9P/SYY3VeSFws=
=GwFc
-----END PGP SIGNATURE-----

Re: NAT problem with iptables

[Pascal Hambourg]

Cliff Stanford a écrit :
> 
> Pascal Hambourg wrote:
> 
>>A possible explanation may be the following.
>>The remote box sends a continuous stream of UDP packets. The first 
>>packet was received before the ruleset was installed but after the 
>>conntrack was loaded, so a conntrack entry was created with no NAT, and 
>>does not expire because of the continuous stream.
> 
> Thank you!  You hit the nail right on the head!
> 
>>Clear the conntrack table by any means and see what happens.
> 
> I cleared it with conntrack -F and you were absolutely right.  It's now
> working as expected.

In order to avoid this, the iptables ruleset must preferably be 
installed before the network interfaces are UP and some traffic is sent 
or received.

> I knew it had to be my naivety but I couldn't see
> what I was doing wrong.

It has nothing to do with naivety. Your ruleset was correct. I believe 
this kind of problem requires fair knowledge and understanding of how 
Netfilter performs connection tracking and its side effects. Fortunately 
you provided enough information, which not everyone does all the time.

> Out of interest, I can't seem to find a syntax that conntrack -D likes;
> is there a tutorial for it anywhere or any docs better than the man page?

I have never used conntrack and cannot help you on this, sorry.