DNAT routing problem

DNAT routing problem

[Andrea Ranieri]

Greetings,

I'm trying to use DNAT in order to NAT from 10.0.5.x/24 to 192.168.1.y/24.
It seems an easy job... Well it isn't. At least for me :)

This is the command I issue.

iptables -v -t nat -I PREROUTING -i eth5 -j DNAT --to 192.168.1.0-192.168.1.254

Playing a bit with iptables, I observed a strange behavior. For
example, if my router is forwarding
even a few packets per second (ipv4 only payload), the rule is
accepted, but not applied.

------------------------------
magnolia:~> iptables -v -t nat --list
Chain PREROUTING (policy ACCEPT 18 packets, 3261 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DNAT       0    --  eth5   any     anywhere
anywhere            to:192.168.1.0-192.168.1.254

Chain POSTROUTING (policy ACCEPT 2 packets, 290 bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 1 packets, 244 bytes)
 pkts bytes target     prot opt in     out     source
destination
------------------------------
magnolia:~> ifconfig eth5 ; ifconfig eth6
eth5      Link encap:Ethernet  HWaddr 00:30:48:32:6B:68
          inet addr:10.0.5.1  Bcast:10.0.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:71 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:4544 (4.4 KiB)  TX bytes:0 (0.0 b)
          Base address:0x3000 Memory:c8300000-c8320000

eth6      Link encap:Ethernet  HWaddr 00:30:48:32:6B:69
          inet addr:10.0.6.1  Bcast:10.0.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:256 (256.0 b)  TX bytes:4800 (4.6 KiB)
          Base address:0x3020 Memory:c8320000-c8340000
------------------------------
magnolia:~> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.5.0        *               255.255.255.0   U     0      0        0 eth5
10.0.6.0        *               255.255.255.0   U     0      0        0 eth6
130.251.17.0    *               255.255.255.0   U     0      0        0 eth0
default         router.reti.dis 0.0.0.0         UG    0      0        0 eth0
------------------------------

As you can see, packets get routed correctly to the proper (eth6)
interfaces, so no natting
is in progress (also verified capturing packets).

Conversely, if no traffic is being forwarded, the rule is accepted and
correctly applied.

------------------------------
magnolia:~> iptables -v -t nat --list
Chain PREROUTING (policy ACCEPT 6 packets, 643 bytes)
 pkts bytes target     prot opt in     out     source
destination
    1    46 DNAT       0    --  eth5   any     anywhere
anywhere            to:192.168.1.0-192.168.1.254

Chain POSTROUTING (policy ACCEPT 2 packets, 226 bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 1 packets, 180 bytes)
 pkts bytes target     prot opt in     out     source
destination
------------------------------
magnolia:~> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.5.0        *               255.255.255.0   U     0      0        0 eth5
10.0.6.0        *               255.255.255.0   U     0      0        0 eth6
192.168.1.0     10.0.6.2        255.255.255.0   UG    0      0        0 eth6
130.251.17.0    *               255.255.255.0   U     0      0        0 eth0
default         router.reti.dis 0.0.0.0         UG    0      0        0 eth0
------------------------------
magnolia:~> ifconfig eth5 ; ifconfig eth6
eth5      Link encap:Ethernet  HWaddr 00:30:48:32:6B:68
          inet addr:10.0.5.1  Bcast:10.0.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:4352 (4.2 KiB)  TX bytes:0 (0.0 b)
          Base address:0x3000 Memory:c8300000-c8320000

eth6      Link encap:Ethernet  HWaddr 00:30:48:32:6B:69
          inet addr:10.0.6.1  Bcast:10.0.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:128 (128.0 b)  TX bytes:2880 (2.8 KiB)
          Base address:0x3020 Memory:c8320000-c8340000
------------------------------

But when I try to flush the NAT table, the rule is apparently removed
from the table, but the kernel
continues to apply it. So, if I remove the 192.168 route, packets get dropped.

------------------------------
magnolia:~> iptables -v -t nat --list
Chain PREROUTING (policy ACCEPT 52 packets, 8291 bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain POSTROUTING (policy ACCEPT 6 packets, 487 bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 5 packets, 441 bytes)
 pkts bytes target     prot opt in     out     source
destination
------------------------------
magnolia:~> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.5.0        *               255.255.255.0   U     0      0        0 eth5
10.0.6.0        *               255.255.255.0   U     0      0        0 eth6
130.251.17.0    *               255.255.255.0   U     0      0        0 eth0
default         router.reti.dis 0.0.0.0         UG    0      0        0 eth0
------------------------------
magnolia:~> ifconfig eth5 ; ifconfig eth6
eth5      Link encap:Ethernet  HWaddr 00:30:48:32:6B:68
          inet addr:10.0.5.1  Bcast:10.0.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:228 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:14592 (14.2 KiB)  TX bytes:0 (0.0 b)
          Base address:0x3000 Memory:c8300000-c8320000

eth6      Link encap:Ethernet  HWaddr 00:30:48:32:6B:69
          inet addr:10.0.6.1  Bcast:10.0.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:256 (256.0 b)  TX bytes:4352 (4.2 KiB)
          Base address:0x3020 Memory:c8320000-c8340000
------------------------------

I really don't understand this behavior, I hope I'm missing something obivious.
I'd like to point out that I'm running a standard (debian
2.6.22-14-server) kernel,
and each of this two tests, comes from a fresh boot.

Thanks in advance, and sorry for the jumbo mail :)
Andrea

Re: DNAT routing problem

[Grant Taylor]

On 05/08/08 13:17, Andrea Ranieri wrote:
> Playing a bit with iptables, I observed a strange behavior. For 
> example, if my router is forwarding even a few packets per second 
> (ipv4 only payload), the rule is accepted, but not applied.

<snip>

> Conversely, if no traffic is being forwarded, the rule is accepted 
> and correctly applied.

<snip>

> I really don't understand this behavior, I hope I'm missing something 
> obivious. I'd like to point out that I'm running a standard (debian 
> 2.6.22-14-server) kernel, and each of this two tests, comes from a 
> fresh boot.

(Time to open my mouth and insert my foot.)

NAT rules are applied to the first packet in a connection and then the 
same action is auto-magically applied to all other packets in the 
connection with out passing them through the NAT table.

So what you are seeing is probably very likely based on existing verses 
new connections.

> Thanks in advance, and sorry for the jumbo mail :) Andrea

*nod*



Grant. . . .

Re: DNAT routing problem

[Andrea Ranieri]

On 5/8/08, Grant Taylor wrote:

> NAT rules are applied to the first packet in a connection and then the
> same action is auto-magically applied to all other packets in the
> connection with out passing them through the NAT table.
>
> So what you are seeing is probably very likely based on existing verses
> new connections.

Thanks for your reply, but it seems I didn't explain my problem clearly.
I have a connectionless flow of ipv4 packets. No TCP, UDP or any L4
payload at all.
So my question now is: does netfilter (with D/SNAT or NETMAP target)
provide basic natting features without having a L4 payload, or a
connection oriented flow is required for natting?

Thanks again
Andrea

Re: DNAT routing problem

[Cloves Pereira Costa Jr]

Hi Andrea,

Could you show us some example?

[]s

Cloves

Em Sex, 2008-05-09 às 12:48 +0200, Andrea Ranieri escreveu:
> On 5/8/08, Grant Taylor wrote:
> 
> > NAT rules are applied to the first packet in a connection and then the
> > same action is auto-magically applied to all other packets in the
> > connection with out passing them through the NAT table.
> >
> > So what you are seeing is probably very likely based on existing verses
> > new connections.
> 
> Thanks for your reply, but it seems I didn't explain my problem clearly.
> I have a connectionless flow of ipv4 packets. No TCP, UDP or any L4
> payload at all.
> So my question now is: does netfilter (with D/SNAT or NETMAP target)
> provide basic natting features without having a L4 payload, or a
> connection oriented flow is required for natting?
> 
> Thanks again
> Andrea
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-- 
Antes de imprimir, pense em sua responsabilidade com o Meio Ambiente!!!

Cloves Pereira Costa Jr
M2Sys Tecnologia e Serviços S/A

+55 41 3271-4461
+55 41 8413-6740
Skype: clovespcjr
cloves.costa@m2sys.com.br

Re: DNAT routing problem

[Andrea Ranieri]

On Fri, May 9, 2008 at 12:48 PM, Andrea Ranieri <andreran@uno.it> wrote:
> On 5/8/08, Grant Taylor wrote:
>
>> NAT rules are applied to the first packet in a connection and then the
>> same action is auto-magically applied to all other packets in the
>> connection with out passing them through the NAT table.
>>
>> So what you are seeing is probably very likely based on existing verses
>> new connections.
>
> Thanks for your reply, but it seems I didn't explain my problem clearly.
> I have a connectionless flow of ipv4 packets. No TCP, UDP or any L4
> payload at all.
> So my question now is: does netfilter (with D/SNAT or NETMAP target)
> provide basic natting features without having a L4 payload, or a
> connection oriented flow is required for natting?

After a couple of other tests, I have some relevant news.

My previous tests involved a ipv4 flow going always from 10.0.5.2 to
10.0.6.2, and the results remains those I wrote in my first mail.
Now I tried to change the source IP, and finally, the natting process
begins. But obiviously with a strange behavior...

In this test I always have the 10.0.5.2->10.0.6.2 flow running, and a
10.0.5.[2 to 5]->10.0.6.2 flow. Every IP except the .2 get natted. The
.2 remains unchanged. Moreover, when i flush the nat table, the rule
disappear but .3, .4 and .5 IPs continue to get natted. I think that's
a cache problem.

It's time to put feet in the mouth, isn't it? ^___^

Cheers
Andrea

Re: DNAT routing problem

[Grant Taylor]

On 05/09/08 08:30, Andrea Ranieri wrote:
> My previous tests involved a ipv4 flow going always from 10.0.5.2 to 
> 10.0.6.2, and the results remains those I wrote in my first mail. Now 
> I tried to change the source IP, and finally, the natting process 
> begins. But obiviously with a strange behavior...

(See below.)

> In this test I always have the 10.0.5.2->10.0.6.2 flow running, and a 
> 10.0.5.[2 to 5]->10.0.6.2 flow. Every IP except the .2 get natted. 
> The .2 remains unchanged. Moreover, when i flush the nat table, the 
> rule disappear but .3, .4 and .5 IPs continue to get natted. I think 
> that's a cache problem.

This really makes me believe that you are dealing with what connection 
tracking thinks is an on going existing established flow / connection. 
Remember that the NAT table only sees the first packet of a connection. 
  So if you are altering your NAT table after a connection is 
established it will name make any difference to the existing connection. 
  This is further exemplified by you testing .3-.5 and seeing them start 
to change and then continue doing what they were when you flush your NAT 
table.  I think you will find that if you stop your connections, wait a 
few minutes, and then start them back up they will behave as expected.

> It's time to put feet in the mouth, isn't it? ^___^

Na.  ;)



Grant. . . .

Re: DNAT routing problem

[Andrea Ranieri]

On 5/9/08, Grant Taylor wrote:

> This really makes me believe that you are dealing with what connection
> tracking thinks is an on going existing established flow / connection.
> Remember that the NAT table only sees the first packet of a connection.
>  So if you are altering your NAT table after a connection is
> established it will name make any difference to the existing connection.
>  This is further exemplified by you testing .3-.5 and seeing them start
> to change and then continue doing what they were when you flush your NAT
> table.  I think you will find that if you stop your connections, wait a
> few minutes, and then start them back up they will behave as expected.

Yes, that sounds as a good explanation of this phenomenon.
However this behavior is not what I want/expect from netfilter. I'm
looking for a simple, straight-forward, connectionless 1to1 IP NAT.
And, of course, i'm looking for something that can be enabled/disabled
without waiting minutes!

Ok then, if that's the normal behavior of netfilter's NAT module, I'll
have to find an alternative solution.

Thank you very much for your help.
Andrea

Re: DNAT routing problem

[Grant Taylor]

On 05/09/08 11:34, Andrea Ranieri wrote:
> Yes, that sounds as a good explanation of this phenomenon. However 
> this behavior is not what I want/expect from netfilter. I'm looking 
> for a simple, straight-forward, connectionless 1to1 IP NAT. And, of 
> course, i'm looking for something that can be enabled/disabled 
> without waiting minutes!

*nod*

> Ok then, if that's the normal behavior of netfilter's NAT module, 
> I'll have to find an alternative solution.

I don't know if it is still in place or not, but you might look in to IP 
Route 2's stateless NAT, it may be able to do what you are wanting.  I 
think your main problem with NetFilter's NAT *is* the connection tracking.

> Thank you very much for your help.

*nod*

You are welcome.



Grant. . . .

Re: DNAT routing problem

[Jan Engelhardt]

On Friday 2008-05-09 12:48, Andrea Ranieri wrote:
>On 5/8/08, Grant Taylor wrote:
>
>> NAT rules are applied to the first packet in a connection and then the
>> same action is auto-magically applied to all other packets in the
>> connection with out passing them through the NAT table.
>>
>> So what you are seeing is probably very likely based on existing verses
>> new connections.
>
>Thanks for your reply, but it seems I didn't explain my problem clearly.
>I have a connectionless flow of ipv4 packets. No TCP, UDP or any L4
>payload at all.
>So my question now is: does netfilter (with D/SNAT or NETMAP target)
>provide basic natting features without having a L4 payload, or a
>connection oriented flow is required for natting?

Yes, it can do generic NAT -- which is actually used for things like
IPsec-ESP, IP-in-IP.

Re: DNAT routing problem

[Jan Engelhardt]

On Friday 2008-05-09 18:34, Andrea Ranieri wrote:
>On 5/9/08, Grant Taylor wrote:
>
>> This really makes me believe that you are dealing with what connection
>> tracking thinks is an on going existing established flow / connection.
>> Remember that the NAT table only sees the first packet of a connection.
>>  So if you are altering your NAT table after a connection is
>> established it will name make any difference to the existing connection.
>>  This is further exemplified by you testing .3-.5 and seeing them start
>> to change and then continue doing what they were when you flush your NAT
>> table.  I think you will find that if you stop your connections, wait a
>> few minutes, and then start them back up they will behave as expected.
>
>Yes, that sounds as a good explanation of this phenomenon.
>However this behavior is not what I want/expect from netfilter. I'm
>looking for a simple, straight-forward, connectionless 1to1 IP NAT.
>And, of course, i'm looking for something that can be enabled/disabled
>without waiting minutes!

On a global scale you can set
/proc/sys/net/netfilter/nf_conntrack_generic_timeout .
There has been a module (or a group of them) called TIMEOUT or
actually CONNTRACK by Phil Oester and Pablo Neira Ayuso with which
you can set the ct timeout per connection. That's one way.
Another is to use the RAWNAT target.
But tc is an obscure thing.

Re: DNAT routing problem

[Andrea Ranieri]

On Sat, May 10, 2008 at 10:56 AM, Jan Engelhardt <jengelh@medozas.de> wrote:

>  On a global scale you can set
>  /proc/sys/net/netfilter/nf_conntrack_generic_timeout .
>  There has been a module (or a group of them) called TIMEOUT or
>  actually CONNTRACK by Phil Oester and Pablo Neira Ayuso with which
>  you can set the ct timeout per connection. That's one way.
>  Another is to use the RAWNAT target.
>  But tc is an obscure thing.

Again, thanks for the suggestion. Setting
"nf_conntrack_generic_timeout" seems to work fine.
For what concerns RAW table and NOTRACK target, i think that their
main purpose is to completely skip CONNTRACK and NAT hooks, so no luck
with them.
For the sake of completeness, in newer kernels (2.6.23+ I think), a
brand new stateless NAT has been added. The config option is
NET_ACT_NAT, and it can be configured via "ip route add nat". However
I think it's pointless to play with it now. Netfilter's NAT +
nf_conntrack_generic_timeout are doing a good job.

Cheers
Andrea