About this list Date view Thread view Subject view Author view Attachment view

From: Christian Jaeger (christian.jaeger_at_ethlife.ethz.ch)
Date: Mon 16 Aug 2004 - 06:38:31 BST


Hello Herbert and Enrico

There is a problem with UDP port forwarding from a host doing NAT into
vservers which have multiple ip adresses. Depending on the order how
the ip addresses are fed to chbind, the forwarding will work or
not. TCP port forwarding is not affected.

Steps to reproduce:

You need two machines,
[H]= vserver- and NAT-enabled host (I'm using 2.4.27 and vs1.3.9) with
      netcat.
[R]= remote host; no vserver needed, with netcat.

Setup on [H]:
(no vservers running and no active iptables rules)
ifconfig eth0 1.2.3.4
ifconfig lo 127.0.0.1
ifconfig lo:1loc 10.0.0.1 up
ifconfig lo:1pub 192.168.0.1 up
iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.4 -p udp --dport 666
-j DNAT --to 192.168.0.1

Then:

Test 1: getting in touch with the problem:
on.. type this..
[H] netcat -n -l -u -v -p 666
[R] netcat -n -u 1.2.3.4 666
     bla1
     bla2
(type two lines of text; the first is getting through to [H], the
second not - netcat terminates, since a "port unreachable" packet is
sent back from H to R upon receiving the second packet.)

This test just shows that the kernel can behave somewhat strange if
the listener binds to * (0.0.0.0) when a NAT rule is forwarding to a
second address - looks like the kernel is getting confused
somehow. This happens also on a vanilla 2.4.27 kernel.

Test 2: making the problem disappear using -s flag:
[H] netcat -n -l -u -v -p 666 -s 192.168.0.1
[R] netcat -n -u 1.2.3.4 666
     bla1
     bla2
     bla3
     ...
You can type as many lines you want, it's all getting through, and any
typing on H is sent to R.
"Kernel is somehow not confused anymore", since netcat is listening
only on the target ip of the DNAT rule.

Test 3: making the problem disappear using chbind:
[H] chbind --ip 192.168.0.1 netcat -n -l -u -v -p 666
[R] (same as above)

The effect is the same as with test 2.

Test 4: making the problem appear again:
[H] chbind --ip 10.0.0.1 --ip 192.168.0.1 netcat -n -l -u -v -p 666
[R] netcat -n -u 1.2.3.4 666
     bla1
     bla2
(netcat stops again)

Test 5: and making it disappear again:
[H] chbind --ip 192.168.0.1 --ip 10.0.0.1 netcat -n -l -u -v -p 666
[R] (as always)
Note the reversed order of the ip's.
Connection works again correctly.

So, the net effect is: If you configure your vservers to use two ip's
(for example: one for "localhost" purposes, and a second for public
access), and use UDP port forwarding from the NAT'ing host, and be so
unlucky that the order how the two ip's are fed to chbind during the
vserver startup is that the first ip is *not* the target ip of the
forwarding, you're 'sol'. If the utils (I'm currently using alpha
utils 0.29.211) would provide a way to tell the order of the ip's,
one could at least work around the problem once being aware of it.

BTW it does not matter whether you additionally have SNAT rules for
outgoing traffic or not.

Cheers
Christian.
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 16 Aug 2004 - 06:42:31 BST by hypermail 2.1.3