Symmetric NAT for udp

Symmetric NAT for udp

[Dmitry]

Hi all - i have a trouble with making netfilter nat act like symmetric 
for udp . Normally for udp  it acts like port restricted cone nat ( the 
main feature is that it doesnt mangle src port if several udp packets 
come from same src ip/port - to different dest. In case of tcp it acts 
like symmetric nat - ie each syn packet even from same src ip/port cause 
src port  mangling. What i need is to make it act like symmetric for udp 
too. So i just looked throught udp/tcp specific files 
(conntrack_proto_udp, nat_proto_udp and relative tcp ) and didnt find 
anything that makes it work different for tcp and udp. Tests revealed 
that at first time (and after timeout) each udp packets  (even from same 
src port/ip but to diff dest ) cause  new conntrack creation. But when 
it checkes before postrouting is tuple taken  - for same src/port 
somehow it says that no - so mangling doesnt occur. Can somebody give me 
a hint where to dig?


-- 

dev789@gmail.com  

Symmetric NAT for udp

[Dmitry]

Hi all - i have a trouble with making netfilter nat act like symmetric 
for udp . Normally for udp  it acts like port restricted cone nat ( the 
main feature is that it doesnt mangle src port if several udp packets 
come from same src ip/port - to different dest. In case of tcp it acts 
like symmetric nat - ie each syn packet even from same src ip/port cause 
src port  mangling. What i need is to make it act like symmetric for udp 
too. So i just looked throught udp/tcp specific files 
(conntrack_proto_udp, nat_proto_udp and relative tcp ) and didnt find 
anything that makes it work different for tcp and udp. Tests revealed 
that at first time (and after timeout) each udp packets  (even from same 
src port/ip but to diff dest ) cause  new conntrack creation. But when 
it checkes before postrouting is tuple taken  - for same src/port 
somehow it says that no - so mangling doesnt occur. Can somebody give me 
a hint where to dig?

-- 

Sincerely,
Dmitry Gritsenko
DG@IPCB.net 

Re: Symmetric NAT for udp

[KOVACS Krisztian]

  Hi,

On Thursday 17 November 2005 13.00, Dmitry wrote:
> Hi all - i have a trouble with making netfilter nat act like symmetric
> for udp . Normally for udp  it acts like port restricted cone nat ( the
> main feature is that it doesnt mangle src port if several udp packets
> come from same src ip/port - to different dest. In case of tcp it acts
> like symmetric nat - ie each syn packet even from same src ip/port cause
> src port  mangling. What i need is to make it act like symmetric for udp
> too. So i just looked throught udp/tcp specific files
> (conntrack_proto_udp, nat_proto_udp and relative tcp ) and didnt find
> anything that makes it work different for tcp and udp. Tests revealed
> that at first time (and after timeout) each udp packets  (even from same
> src port/ip but to diff dest ) cause  new conntrack creation. But when
> it checkes before postrouting is tuple taken  - for same src/port
> somehow it says that no - so mangling doesnt occur. Can somebody give me
> a hint where to dig?

  Dmitry, you don't even mention the exact version number of the kernel 
you're testing. Could you tell us that precious information?

  By the way, it would help a _lot_ if you could write nfsim testcases 
demonstrating the problem (the difference between TCP and UDP) you're 
seeing. Would that be possible?

-- 
 Regards,
  Krisztian Kovacs

Symmetric NAT for udp

[Dmitry]

kernel 2.4.31

here is the example -

there are 2 subnets - 192.168.100.* and 192.168.101.*

there are 3 hosts  - host A - has ips - 192.168.100.56,192.168.100.92
host B - 192.168.100.59, 192.168.101,59 - (NAT box)
host C - 192.168.101.146/147

host B - has ruleset for masquerading of host A

by nmap i send 3 packets from host A to C via B

nmap -P0 -sU 192.168.101.146 -p 1232 --max_rtt_timeout 6 -g 10000 -S 
192.168.100.56                                                                           

nmap -P0 -sU 192.168.101.147 -p 1231 --max_rtt_timeout 6 -g 10000 -S 
192.168.100.56                                                                           

nmap -P0 -sU 192.168.101.146 -p 1232 --max_rtt_timeout 6 -g 10000 -S 
192.168.100.92                                                                           



on host B on different interfeaces i see this picture


BEFORE NAT

[root@nist root]# tcpdump -n -i eth0  dst port 1232 or dst port 1231
tcpdump: listening on eth0                                         
                                                                   
18:11:12.951342 192.168.100.56.10000 > 192.168.101.146.1232: udp 0 
18:11:13.460999 192.168.100.56.10000 > 192.168.101.147.1231: udp 0 
18:11:13.970699 192.168.100.92.10000 > 192.168.101.146.1232: udp 0 


AFTER NAT

[root@nist NIST_TEST]# tcpdump -n -i eth1 dst port 1231 or dst port 1232
tcpdump: listening on eth1                                              
18:11:12.951461 192.168.101.59.10000 > 192.168.101.146.1232: udp 0      
18:11:13.461121 192.168.101.59.10000 > 192.168.101.147.1231: udp 0      
18:11:13.970777 192.168.101.59.1025 > 192.168.101.146.1232: udp 0       
                                                                        
source port was changed to 1025 only for packet - which src differed 
from first one.

ie in case for udp - it allows to bind on same PUBLIC src port 
connections with different hosts if src the same - this is so called 
"cone nat"


actually i mistaken  about tcp connection - they didnt show symmetric 
nat - but anyway they show different behaviour

instead UDP packets i sent tcp SYN

BEFORE NAT
18:29:26.276521 192.168.100.56.10000 > 192.168.101.146.1232: S 
3995259052:399525
9052(0) win 
4096                                                               
18:29:26.284750 192.168.100.56.10000 > 192.168.101.147.1231: S 
3044654256:304465
4256(0) win 
4096                                                               
18:29:26.292757 192.168.100.92.10000 > 192.168.101.146.1232: S 
705399252:7053992
52(0) win 
4096                                                                 

AFTER NAT

18:29:26.276582 192.168.101.59.10000 > 192.168.101.146.1232: S 
3995259052:399525
9052(0) win 
4096                                                               
18:29:26.284824 192.168.101.59.10000 > 192.168.101.147.1231: S 
3044654256:304465
4256(0) win 
4096                                                               
18:29:26.292811 192.168.101.59.10000 > 192.168.101.146.1232: S 
705399252:7053992
52(0) win 
4096                                                                 



in all cases src port  was preserved

///////////////////////////////////////////////////////////
Its not an issue but i need to test simmetric nat

so what i need from udp is to get this picture after nat


18:11:12.951461 192.168.101.59.10000 > 192.168.101.146.1232: udp 0      
18:11:13.461121 192.168.101.59.1025 > 192.168.101.147.1231: udp 0      
18:11:13.970777 192.168.101.59.1026 > 192.168.101.146.1232: udp 0  

////////////////////////////////////////////////////////

Actually - the question is - does somebody tried to make something 
similar or
 just have an idea on making it.
 Currently im stuck on __ip_conntrack_find function .
 Just cant understand why for second udp packet it says that tuple isnt 
taken - although its must be taken by first packet

       

-- 

Sincerely,
Dmitry Gritsenko
DG@IPCB.net