From: Luís Miguel Silva (lms_at_ispgaya.pt)
Date: Sat 17 Sep 2005 - 22:38:58 BST
Dear Herbert,
Allthough i really thought your email was full of sarcasm (*really* sorry if i
missinterpreted it :o) ), please read along the email to find some comments
replying your comments...
> *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
There are 4 NICs on the root server called leonardo-root.
eth0 -> 192.168.3.2 [connecting to our internal network / outside world]
eth1 -> 10.69.69.1 [connecting to the outside world (ADSL connection)]
eth2 -> 172.28.10.254 [connecting to some IP cameras]
eth3 -> not used...[until i added support for the 3com card off course :o)]
Also, as you stated, after i added support to the 3com card, all the
other NICs
switched names...
Well, a little comment on this :o)
1º of all, im no idiot and i obviously know that and changed all the cables
2º why did you assume that?
3º ever thought i could be using modules in my kernel and alias''''ing
the NICs?
;o)
Either way...by default, the packets to unknown networks go throw eth1 [gw:
10.69.69.254].
There is also another static route declared so the machine sends packets to
192.168.0.0/16 via eth0 [gw 192.168.3.1].
The thing is, our REALLY DEFAULT gateway [for the entire organization
(192.168.3.1)] also connects to the outside world AND to some addresses on the
internet which belong to US (the addresses you pointed as belonging to
KPNQwest).
Since we can get there by static routing, why the HELL should you use our ADSL
connection to get to some external machines on the same building?
Tipically we would SNAT the vservers address to 10.69.69.1 so that the packets
would route TO the internet by our ADSL connection but we wanted that all the
vservers connections (which got 192.168.3.0/24 addresses) route the packets to
our "local external" network by our eth0 gateway:
> $IPTABLES -A POSTROUTING -t nat -s 192.168.3.0/24 -d
> 193.126.109.240/255.255.255.248 -j ACCEPT
Dont worry about KPNQwest getting packets from a "private network",
they all get
MASQUERADED on the next node :o)....
> $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?)
Thats just one of the things i was COMPLAINING about on the email i sent. Some
vservers CANT route packets unless i SNAT them onto the root-servers address.
> $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 ...
This is for the IP cameras network, same exact reason! :o|
> 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 ...
More or less... EXACTLY!
Now, do you have the FULL picture Herbert? :o)
As i mentioned above, i must say i got pretty sad reading your response to my
email. I just asked for help because you are allways so helpfull to all of us
and, instead, you "mocked me" and questioned my configurations...
Either way, i hope that was just a miss understanding! ;o)
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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver