IPTables NAT: Strange behaviour: bug?

IPTables NAT: Strange behaviour: bug?

[Pedro Gonçalves]

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

Hi everyone

I'm using IPTables to provide me a Port Restricted Cone NAT.
According to STUN RFC, in a Port Restricted Cone NAT
"all requests from the same internal IP address and port are mapped to 
the same IP address and port"
(using all policies set to ACCEPT and the following rule:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)

My scenario is the following:
-Client behind NAT: IP = 175.16.0.1
-NAT public addr = 192.168.2.159

This client will talk with two different destination addresses:
-192.168.2.164 (Stun server)
-192.168.2.173 (Other NAT's public addr)

In attachment you can find an capture made at the machine with IPTables, 
in which you can see:
-packets 1 and 2: Packet going from the client behind NAT 
(175.16.0.1:10000) to Stun Server (192.168.2.164:3478) -> Client's 
public address is 192.168.2.159:10000
-packets 21 e 22: Packet going from the client behind NAT 
(175.16.0.1:10000) to the other NAT's public addr 
(192.168.2.173:20000)-> Client's public address is 192.168.2.159:1029

Why is the client getting different NAT mappings?
Why is the mapping changing from
175.16.0.1:10000 -> 192.168.2.159:10000
to
175.16.0.1:10000 -> 192.168.2.159:1029
?

Best Regards
Pedro

[-- Attachment #2: nat_strange_behaviour.pcap --]
[-- Type: application/octet-stream, Size: 36136 bytes --]

IPTables NAT: Strange behaviour: bug?

[Pedro Gonçalves]

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

Hi everyone

I'm using IPTables to provide me a Port Restricted Cone NAT.
According to STUN RFC, in a Port Restricted Cone NAT
"all requests from the same internal IP address and port are mapped to
the same IP address and port"
(using all policies set to ACCEPT and the following rule:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)

My scenario is the following:
-Client behind NAT: IP = 175.16.0.1
-NAT public addr = 192.168.2.159

This client will talk with two different destination addresses:
-192.168.2.164 (Stun server)
-192.168.2.173 (Other NAT's public addr)

In attachment you can find an capture made at the machine with IPTables,
in which you can see:
-packets 1 and 2: Packet going from the client behind NAT
(175.16.0.1:10000) to Stun Server (192.168.2.164:3478) -> Client's
public address is 192.168.2.159:10000
-packets 21 e 22: Packet going from the client behind NAT
(175.16.0.1:10000) to the other NAT's public addr
(192.168.2.173:20000)-> Client's public address is 192.168.2.159:1029

Why is the client getting different NAT mappings?
Why is the mapping changing from
175.16.0.1:10000 -> 192.168.2.159:10000
to
175.16.0.1:10000 -> 192.168.2.159:1029
?

Best Regards
Pedro


[-- Attachment #2: nat_strange_behaviour_.pcap --]
[-- Type: application/octet-stream, Size: 5252 bytes --]

Re: IPTables NAT: Strange behaviour: bug?

[Pascal Hambourg]

Hello,

Pedro Gonçalves a écrit :
> 
> In attachment you can find an capture made at the machine with IPTables,
> in which you can see:
> -packets 1 and 2: Packet going from the client behind NAT
> (175.16.0.1:10000) to Stun Server (192.168.2.164:3478) -> Client's
> public address is 192.168.2.159:10000
> -packets 21 e 22: Packet going from the client behind NAT
> (175.16.0.1:10000) to the other NAT's public addr
> (192.168.2.173:20000)-> Client's public address is 192.168.2.159:1029
> 
> Why is the client getting different NAT mappings?

The NAT mechanism may change the source port in order to avoid a clash - 
or at least what it considers a clash - with an existing mapping (same 
external source and destination addresses and ports). I guess that this 
existing mapping was created by packet #17 received from the other NAT 
device : 192.168.2.173.20000 -> 192.168.2.159.10000.

A possible workaround may be to DROP or REJECT this incoming packet in 
the INPUT table, so the associated connection tracking and NAT mapping 
are deleted.