Re: [Vserver] HOWTO deal with NAT'ing firewalls and source-based routing with vservers
On Sun, Feb 12, 2006 at 01:16:34AM +0100, Valdemar Lemche wrote: Hi all I've had a quite a headache with NAT and vservers on my home server/firewall. And as far as I can read on vserver mailling list, a lot of other people have had the same problem. So now when I cracked the nut, I decided to make this little howto. HOWTO deal with NAT'ing firewalls and source-based routing with vservers Some *challenges* with source-based routing, MASQUERADE and SNAT: SNAT and MASQUERADE are supposingly doing NAT the same way, except that MASQUERADE purges any connection, when the link of the '-o' interface goes down. However its *NOT* the case. Consider the following setup: +--+ | Some gateway at my ISP: | +-++ | | +-++ | Homeserver and firewall: | +--+ | eth0: dhcp (public ip) | +--+ vserver1 | | dummy0: 192.168.2.1/24 | | +--+ | dummy0:vserver1 192.168.2.2/24 -+--+ | dummy0:vserver2 192.168.2.3/24 -+--+ | eth1: 192.168.1.1/24 | | +--+ | default gateway is the dhcp addr | +--+ vserver2 | +-++ +--+ | | +-++ | Workstation: | | eth0:192.168.1.20/24 | | default gateway: 192.168.1.1 | +--+ ( I love ASCII drawings; Visio eat your heart out! ;) ) I'm doing source-based routing with iproute2: # echo 100 vserver /etc/iproute2/rt_tables # ip rule add from 192.168.2.0/24 table vserver # ip route add default dev eth0 table vserver # ip route add 192.168.1.0/24 dev eth1 table vserver I'm using MASQUERADE with iptables: # iptables -A POSTROUTING -o eth0 -j MASQUERADE From vserver1 vserver2: * I can ping 192.168.2.1 * I can ping the other vserver * I can ping 192.168.1.1 * I can ping 192.168.1.20 * I can ping the dhcp address of eth0 on my homeserver. But I can *NOT* ping any addresse outside eth0 Packets originating from vservers *should* exit through eth0 and thus get masqueraded as the public dhcp address? But in fact they aren't; they still have their original ip address when hitting any address outside eth0. this is already somewhat fuzzy, as threre are no addresses 'inside' eth0, the ips are 'related' or 'assigned' to an interface, but they are not limited to this interface at all ... but the main reason why this fails is that masquerading is a technique which allows a host to 'remap' certain ports/addresses in a conenction aware way when _forwarding_ them. now, first, the forwarding is not required in this case, as the packet is originating from the host, and second there is no need to map to a free port (because of the same reason). now some of you might ask: if that is so, why doesn't it work out of the box?, and the answer is simple. usually (as I said, the ips are not bound to the interfaces) the appropriate ip is chosen according to the routing decisions (i.e. if a packet leaves eth0, it will just get an ip from the eth0 pool, if it is leaving eth1, the stack _usually_ chooses one from there ... now with a restriction on the set of available ips, this leads to a sometimes wrong IP being used on the right interface, which has to be corrected But if I use SNAT instead of MASQUERADE: # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source dhcp given address Then the source address of the packets are translated as it should! So forget about MASQUERADE. But now I hear you cry: But then I have to change the SNAT rule every time eth0 changes address!. No I fixed that: * Install ISC DHCP Client 3.x (on debian do: # apt-get install dhcp3-client). * Download the tarball, http://wheezy.homelinux.net/cgi-bin/viewcvs.cgi/dhclient-scripts.tar.gz?view=tar, and install it (instructions are in the scripts). Basically this packages provides a small perl script, which is called by the DHCP client, and it is setting a SNAT rule according to the IP address that the DHCP client got. It also removes the rule, if the interface is shutdown, and it updates the rule, if the interface changes address. If you don't want to use ISC DHCP Client 3.x but for instance ISC DHCP Client 2.x, then you have to find a way to have the dhcp client call snatman.pl with the correct parameters. Configuring the source-based routing automatically on debian. Add the entry to /etc/network/interfaces: auto dummy0 iface dummy0 inet static address 192.168.2.1 netmask 255.255.255.255 Make a script /etc/network/if-up.d/vserver containing: #!/bin/sh if [ $IFACE = dummy0 ]; then if ! egrep --quiet \ --word-regexp \
Re: [Vserver] HOWTO deal with NAT'ing firewalls and source-based routing with vservers
whats about jabberd servers into vserver? any one try to work with that? i nated the main server por 5222 to the virtual 5222 port... and nothing.. ;(On 2/12/06,
Herbert Poetzl [EMAIL PROTECTED] wrote:
On Sun, Feb 12, 2006 at 01:16:34AM +0100, Valdemar Lemche wrote: Hi all I've had a quite a headache with NAT and vservers on my home server/firewall. And as far as I can read on vserver mailling list, a
lot of other people have had the same problem. So now when I cracked the nut, I decided to make this little howto. HOWTO deal with NAT'ing firewalls and source-based routing with vservers
Some *challenges* with source-based routing, MASQUERADE and SNAT: SNAT and MASQUERADE are supposingly doing NAT the same way, except that MASQUERADE purges any connection, when the link of the '-o' interface
goes down. However its *NOT* the case. Consider the following setup: +--+ | Some gateway at my ISP:| +-++
| | +-++ | Homeserver and firewall: | +--+ | eth0: dhcp (public ip) |+--+ vserver1 |
| dummy0: 192.168.2.1/24 ||+--+ | dummy0:vserver1 192.168.2.2/24-+--+ | dummy0:vserver2
192.168.2.3/24-+--+ | eth1: 192.168.1.1/24 ||+--+ | default gateway is the dhcp addr |+--+ vserver2 | +-++ +--+
| | +-++ | Workstation: | | eth0:192.168.1.20/24
| | default gateway: 192.168.1.1 | +--+ ( I love ASCII drawings; Visio eat your heart out! ;) ) I'm doing source-based routing with iproute2:
# echo 100 vserver /etc/iproute2/rt_tables # ip rule add from 192.168.2.0/24 table vserver # ip route add default dev eth0 table vserver
# ip route add 192.168.1.0/24 dev eth1 table vserver I'm using MASQUERADE with iptables: # iptables -A POSTROUTING -o eth0 -j MASQUERADE
From vserver1 vserver2:* I can ping 192.168.2.1* I can ping the other vserver* I can ping 192.168.1.1* I can ping
192.168.1.20* I can ping the dhcp address of eth0 on my homeserver. But I can *NOT* ping any addresse outside eth0 Packets originating from vservers *should* exit through eth0 and thus
get masqueraded as the public dhcp address? But in fact they aren't; they still have their original ip address when hitting any address outside eth0.this is already somewhat fuzzy, as threre are no addresses
'inside' eth0, the ips are 'related' or 'assigned' to aninterface, but they are not limited to this interface at all ...but the main reason why this fails is that masqueradingis a technique which allows a host to 'remap' certain
ports/addresses in a conenction aware way when _forwarding_them. now, first, the forwarding is not required in thiscase, as the packet is originating from the host, and secondthere is no need to map to a free port (because of the same
reason).now some of you might ask: if that is so, why doesn't itwork out of the box?, and the answer is simple. usually(as I said, the ips are not bound to the interfaces) theappropriate ip is chosen according to the routing decisions
(i.e. if a packet leaves eth0, it will just get an ip fromthe eth0 pool, if it is leaving eth1, the stack _usually_chooses one from there ... now with a restriction on theset of available ips, this leads to a sometimes wrong IP
being used on the right interface, which has to be corrected But if I use SNAT instead of MASQUERADE:# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source dhcp given address
Then the source address of the packets are translated as it should! So forget about MASQUERADE. But now I hear you cry: But then I have to change the SNAT rule every time eth0 changes address!. No I fixed that:
* Install ISC DHCP Client 3.x (on debian do: # apt-get install dhcp3-client).* Download the tarball,
http://wheezy.homelinux.net/cgi-bin/viewcvs.cgi/dhclient-scripts.tar.gz?view=tar, and install it (instructions are in the scripts). Basically this packages provides a small perl script, which is called by
the DHCP client, and it is setting a SNAT rule according to the IP address that the DHCP client got. It also removes the rule, if the interface is shutdown, and it updates the rule, if the interface changes
address. If you don't want to use ISC DHCP Client 3.x but for instance ISC DHCP Client 2.x, then you have to find a way to have the dhcp client call snatman.pl with the correct parameters.
Configuring the source-based routing automatically on debian. Add the entry to /etc/network/interfaces: auto dummy0 iface dummy0 inet static address
192.168.2.1 netmask 255.255.255.255 Make a script /etc/network/if-up.d/vserver containing: #!/bin/sh if [ $IFACE = dummy0 ]; then
if ! egrep --quiet \--word-regexp \vserver /etc/iproute2/rt_tables; then echo You haven't created a vserver table \ in /etc/iproute2/rt_tables
echo Try adding a line like '100 vserver' \ to /etc/iproute2/rt_tables exit 1 fi if [ ${MODE} = start ]; then ip rule add from
192.168.2.0/24
Re: [Vserver] HOWTO deal with NAT'ing firewalls and source-based routing with vservers
On Sun, Feb 12, 2006 at 09:23:44PM -0500, Jairo Enrique Serrano Castañeda wrote: whats about jabberd servers into vserver? any one try to work with that? i nated the main server por 5222 to the virtual 5222 port... and nothing.. ;( well, no idea about jabberd, but the ports it uses will be the same as for other services I hope, so I'd suspect a wrong or incomplete config/setup on your nat. a tcpdump of some test communication and the relevant iptables entries would help :) best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Managing the VServer patch with Git and stgit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Some people have requested an IRC Git tutorial. I will be running this on Thursday from 2-4pm NZDT (UTC+13). That's Thursday 1-3am in London, Wednesday 5-7pm in California, Wednesday 8-11pm in New York and Thursday 9-11am in Taiwan/PRC. Details: ~ server: irc.oftc.net ~ channel: #vserver Bring along: ~ - a working installation of git-core ~http://www.kernel.org/pub/software/scm/git-core/git-1.2.0.tar.gz ~(debian/ubuntu: git-core) ~ - a working installation of stacked git ~http://www.procode.org/stgit/ ~ - a fresh directory created by: ~ git-clone \ ~ rsync://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ~(note: this will download 110MB of git pack file) ~ - (recommended) a working installation of gitk ~http://www.kernel.org/pub/software/scm/git-core/git-1.1.6.tar.gz During the tutorial we will: ~ - track some changes from Linus' development tree, without downloading ~the whole tree again ~ - track another couple of people's trees using the same repository ~ - use Stacked Git (stgit) to import an arbitrary set of split ~patches from Herbert against a non-current kernel version into a ~branch ~ - Re-base a series of patches against a new upstream release ~ - Move some changes between the patches in our patchset ~ - export the patches we're working on to a set of .diffs If requested I can draw reference to other VCS systems you may be familiar with, such as Subversion, CVS, SVK or darcs. - -- Sam Vilain, Catalyst IT (NZ) Ltd. phone: +64 4 499 2267PGP ID: 0x66B25843 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8Av0/AZAiGayWEMRApXZAKCIWUusaTdHQLaq2y4c0yGuYUXyNQCfUs8N V+lC/wed3XXTPTRsQCI/AOU= =rPl7 -END PGP SIGNATURE- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] HOWTO deal with NAT'ing firewalls and source-based routing with vservers
I always like to recommend fwbuilder for building firewalls for vserver hosts. It takes some of the headaches out of building firewall chains, plus you know that you can manage non-Linux firewalls with it too (having varied network stack implementations through your firewall is a common security best practice). Have a look at the screenshots on this page for many hints on how this is approached. Feel free to ask questions. http://utsl.gen.nz/talks/vserver/slide23a.html Sam. Jairo Enrique Serrano Castañeda wrote: whats about jabberd servers into vserver? any one try to work with that? i nated the main server por 5222 to the virtual 5222 port... and nothing.. ;( On 2/12/06, * Herbert Poetzl* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sun, Feb 12, 2006 at 01:16:34AM +0100, Valdemar Lemche wrote: Hi all I've had a quite a headache with NAT and vservers on my home server/firewall. And as far as I can read on vserver mailling list, a lot of other people have had the same problem. So now when I cracked the nut, I decided to make this little howto. HOWTO deal with NAT'ing firewalls and source-based routing with vservers Some *challenges* with source-based routing, MASQUERADE and SNAT: SNAT and MASQUERADE are supposingly doing NAT the same way, except that MASQUERADE purges any connection, when the link of the '-o' interface goes down. However its *NOT* the case. Consider the following setup: +--+ | Some gateway at my ISP: | +-++ | | +-++ | Homeserver and firewall: | +--+ | eth0: dhcp (public ip) | +--+ vserver1 | | dummy0: 192.168.2.1/24 http://192.168.2.1/24 | | +--+ | dummy0:vserver1 192.168.2.2/24 http://192.168.2.2/24 -+--+ | dummy0:vserver2 192.168.2.3/24 http://192.168.2.3/24 -+--+ | eth1: 192.168.1.1/24 http://192.168.1.1/24 | | +--+ | default gateway is the dhcp addr | +--+ vserver2 | +-++ +--+ | | +-++ | Workstation: | | eth0:192.168.1.20/24 http://192.168.1.20/24 | | default gateway: 192.168.1.1 http://192.168.1.1 | +--+ ( I love ASCII drawings; Visio eat your heart out! ;) ) I'm doing source-based routing with iproute2: # echo 100 vserver /etc/iproute2/rt_tables # ip rule add from 192.168.2.0/24 http://192.168.2.0/24 table vserver # ip route add default dev eth0 table vserver # ip route add 192.168.1.0/24 http://192.168.1.0/24 dev eth1 table vserver I'm using MASQUERADE with iptables: # iptables -A POSTROUTING -o eth0 -j MASQUERADE From vserver1 vserver2: * I can ping 192.168.2.1 http://192.168.2.1 * I can ping the other vserver * I can ping 192.168.1.1 http://192.168.1.1 * I can ping 192.168.1.20 http://192.168.1.20 * I can ping the dhcp address of eth0 on my homeserver. But I can *NOT* ping any addresse outside eth0 Packets originating from vservers *should* exit through eth0 and thus get masqueraded as the public dhcp address? But in fact they aren't; they still have their original ip address when hitting any address outside eth0. this is already somewhat fuzzy, as threre are no addresses 'inside' eth0, the ips are 'related' or 'assigned' to an interface, but they are not limited to this interface at all ... but the main reason why this fails is that masquerading is a technique which allows a host to 'remap' certain ports/addresses in a conenction aware way when _forwarding_ them. now, first, the forwarding is not required in this case, as the packet is originating from the host, and second there is no need to map to a free port (because of the same reason). now some of you might ask: if that is so, why doesn't it work out of the box?, and the answer is simple. usually (as I said, the ips are not bound to the interfaces) the appropriate ip is chosen according to the routing decisions (i.e. if a packet leaves eth0, it will just get an ip from the eth0 pool, if it is leaving eth1, the stack _usually_ chooses one from there ... now with a restriction on the set of available ips, this leads to a sometimes wrong IP being used on the right interface, which has to be corrected But if I use SNAT
Re: [Vserver] HOWTO deal with NAT'ing firewalls and source-based routing with vservers
'lo, On Sun, 2006-02-12 at 21:23 -0500, Jairo Enrique Serrano Castañeda wrote: whats about jabberd servers into vserver? any one try to work with that? i nated the main server por 5222 to the virtual 5222 port... and nothing.. ;( I'm running jabberd in a vserver without any trouble. (no natting required on my part however, all my vservers have public IP's) Tom On 2/12/06, Herbert Poetzl [EMAIL PROTECTED] wrote: On Sun, Feb 12, 2006 at 01:16:34AM +0100, Valdemar Lemche wrote: Hi all I've had a quite a headache with NAT and vservers on my home server/firewall. And as far as I can read on vserver mailling list, a lot of other people have had the same problem. So now when I cracked the nut, I decided to make this little howto. HOWTO deal with NAT'ing firewalls and source-based routing with vservers Some *challenges* with source-based routing, MASQUERADE and SNAT: SNAT and MASQUERADE are supposingly doing NAT the same way, except that MASQUERADE purges any connection, when the link of the '-o' interface goes down. However its *NOT* the case. Consider the following setup: +--+ | Some gateway at my ISP: | +-++ | | +-++ | Homeserver and firewall: | +--+ | eth0: dhcp (public ip) | +--+ vserver1 | | dummy0: 192.168.2.1/24 | | +--+ | dummy0:vserver1 192.168.2.2/24 -+--+ | dummy0:vserver2 192.168.2.3/24 -+--+ | eth1: 192.168.1.1/24 | | +--+ | default gateway is the dhcp addr | +--+ vserver2 | +-++ +--+ | | +-++ | Workstation: | | eth0:192.168.1.20/24 | | default gateway: 192.168.1.1 | +--+ ( I love ASCII drawings; Visio eat your heart out! ;) ) I'm doing source-based routing with iproute2: # echo 100 vserver /etc/iproute2/rt_tables # ip rule add from 192.168.2.0/24 table vserver # ip route add default dev eth0 table vserver # ip route add 192.168.1.0/24 dev eth1 table vserver I'm using MASQUERADE with iptables: # iptables -A POSTROUTING -o eth0 -j MASQUERADE From vserver1 vserver2: * I can ping 192.168.2.1 * I can ping the other vserver * I can ping 192.168.1.1 * I can ping 192.168.1.20 * I can ping the dhcp address of eth0 on my homeserver. But I can *NOT* ping any addresse outside eth0 Packets originating from vservers *should* exit through eth0 and thus get masqueraded as the public dhcp address? But in fact they aren't; they still have their original ip address when hitting any address outside eth0. this is already somewhat fuzzy, as threre are no addresses 'inside' eth0, the ips are 'related' or 'assigned' to an interface, but they are not limited to this interface at all ... but the main reason why this fails is that masquerading is a technique which allows a host to 'remap' certain ports/addresses in a conenction aware way when _forwarding_ them. now, first, the forwarding is not required in this case, as the packet is originating from the host, and second there is no need to map to a free port (because of the same reason). now some of you might ask: if that is so, why doesn't it work out of the box?, and the answer is simple. usually (as I said, the ips are not bound to the interfaces) the appropriate ip is chosen according to the routing decisions (i.e. if a packet leaves eth0, it will just get an ip from the eth0 pool, if it is leaving eth1, the stack _usually_ chooses one from there ... now with a restriction on the set of available ips, this leads to a sometimes wrong IP being used on the right interface, which has to be corrected But if I use SNAT instead of MASQUERADE: # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source dhcp
