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. > > [EMAIL PROTECTED] ~# 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 :) > [EMAIL PROTECTED] ~# > > 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 <[EMAIL PROTECTED]> > sub 2048g/76F63BF1 2005-02-22 > _______________________________________________ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver