On Mon, Aug 16, 2004 at 07:38:31AM +0200, Christian Jaeger wrote: > 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
local host 'purposes' is a bad idea anyway, because linux-vserver networking does some stuff to replace the local '127.0.0.1' by the primary address (which makes using lo completely obsolete) > 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. this is expected behaviour because: - the 'first' ip associated with a vserver is considered the 'primary' ip, used for outgoing traffic, if the source ip can no be determined - if you would have copied the output from the netcat -v option, everybody would see that the netcat without -s binds to 0.0.0.0 [any] - current networking (not ngn once finished) can not allow to bind to arbitrary IPs, so it _has_ to decide for one (the primary) in this case ... so it's not a bug, it's a feature ;) HTH, Herbert > Cheers > Christian. > _______________________________________________ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
