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

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sat 17 Sep 2005 - 21:14:51 BST


On Sat, Sep 17, 2005 at 12:52:00PM +0100, Luís Miguel Silva wrote:
> Hello Gang,
>
> Ive been having some serious problems with vservers and iptables!
>
> Sometimes i need to had SNAT rules for my vservers to route outside
> the root server and, someother times, i cant access my vservers from
> the outside :o(
>
> Take this script for example:
> http://lms.ispgaya.pt/goodies/iptables

*sigh* well, let's interpret parts of it ...

$IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24 -d 192.168.2.0/24 -j ACCEPT
$IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24 -d 192.168.4.0/24 -j ACCEPT

accept network traffic from 192.168.3 to 192.168.2 and 192.168.4
(unmodified, unconditional)

$IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24
        -d 193.126.109.240/255.255.255.248 -j ACCEPT

same for traffic from 192.168.3 to 193.126.109.240-247
hmm, why would KQPT Network Operations want packets from
a private network?

$IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24
        -d 193.126.229.32/255.255.255.248 -j ACCEPT

hmm, seems they definitely want private traffic :)

$IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24
        -d ! 192.168.0.0/16 -j SNAT --to 192.168.3.2

everything not destinated at 192.168 will appear as
private IP 192.168.3.2 (strange, why would we want that?)

$IPTABLES -A POSTROUTING -t nat -s 172.28.10.0/24
        -d ! 172.28.10.0/24 -j SNAT --to-source 172.28.10.254

and similar for 172.28.10, which had no role yet,
but seem to be valid IPs for output, and we SNAT
them all to 172.28.10.254 ...

so this setup assumes that both 192.168.3.2 and
172.28.10.254 can reach the outside (whatever that
might mean) and that there are either two routes
or the router can handle both IPs ...

> On the server where i use it everything worked like a charm!
>
> Until.......i had to add support in the kernel for another NIC.
>
> root_at_leonardo-root ~# lspci
> 00:00.0 Host bridge: Intel Corp.: Unknown device 2570 (rev 02)
> 00:01.0 PCI bridge: Intel Corp.: Unknown device 2571 (rev 02)
> 00:1d.0 USB Controller: Intel Corp.: Unknown device 24d2 (rev 02)
> 00:1d.1 USB Controller: Intel Corp.: Unknown device 24d4 (rev 02)
> 00:1d.2 USB Controller: Intel Corp.: Unknown device 24d7 (rev 02)
> 00:1d.3 USB Controller: Intel Corp.: Unknown device 24de (rev 02)
> 00:1d.7 USB Controller: Intel Corp.: Unknown device 24dd (rev 02)
> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev c2)
> 00:1f.0 ISA bridge: Intel Corp.: Unknown device 24d0 (rev 02)
> 00:1f.1 IDE interface: Intel Corp.: Unknown device 24db (rev 02)
> 00:1f.3 SMBus: Intel Corp.: Unknown device 24d3 (rev 02)
> 00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24d5 (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation RIVA TNT2 Model 64 (rev
> 15)
> 02:05.0 Ethernet controller: 3Com Corporation: Unknown device 1700 (rev 12)
> 02:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)

hmm, four different network controllers easily confuse the
unpracticed eye and often also the admin attached to it :)

> root_at_leonardo-root ~#
>
> Since the 3com (gigabit builtin) ethernet device is unknown, i added
> support to it and recompiled the kernel.
>
> After rebooting the machine, i couldnt access any services on
> 192.168.3.81 (vserver called ciisp) from the outside).

hmm, let's see .. *turns on the seeing orb* ... ah, looks
like you 3com card got detected _before_ the other three
realtek ones, so it was named eth0, instead of eth4 ...

hmmm, ... and that probably messed up all other NICs, as
they are now eth1 instead of eth0, eth2 instead of eth1 ...

now, most likely some of your guests have the interface
coded (it's a little blurry now) and other just an ip

> I disabled support for that NIC again, recompiled and rebooted....and
> everything went back to normal again!
>
> Can anybody help me with this? Is this "normal" behaviour?

I guess yes, it is the typical linux networking behaviour
so nothing critical ...

> I also dont understand why some vservers need for me to -j SNAT --to
> root-server and others dont!

this also escapes my imagination (basically because of
lack of information) but I 'assume' that some have real
IPs and/or communicate on private IPs where others have
to use the host IP for outgoing traffic ...

best,
Herbert

> Thanks in advance,
> +----------------------------------------
> | Luís Miguel Ferreira da Silva
> | Network Administrator @ISPGaya
> | Instituto Superior Politécnico Gaya
> | Rua António Rodrigues da Rocha, 291/341
> | Sto. Ovídio • 4400-025 V. N. de Gaia
> | Tel: +351 223745730/3/5
> | GSM: +351 912671471 +351 936371253
> +----------------------------------------
>
> ----------------------------------------------------------------
> Este email foi enviado via o webmail do ISPGaya
> Instituto Superior Politécnico Gaya

Content-Description: Chave Pública PGP
> pub 1024D/DCCC577C 2005-02-22 Lu\xed\x73 Miguel Silva <lms_at_ispgaya.pt>
> sub 2048g/76F63BF1 2005-02-22

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

_______________________________________________
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 Sat 17 Sep 2005 - 21:15:17 BST by hypermail 2.1.3