Tom Eastep 2010 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

Formal support for Linux-vserver was added in Shorewall 4.4.11 Beta2. The centerpiece of that support is the vserver zone type. Vserver zones have the following characteristics: They are defined on the Linux-vserver host. The $FW zone is their implicit parent. Their contents must be defined using the shorewall-hosts (5) file. The ipsec option may not be specified. They may not appear in the ZONE column of the shorewall-interfaces (5) file. Note that you don't need to run Vservers to use vserver zones; they may also be used to create a firewall sub-zone for each aliased interface. If you use these zones, keep in mind that Linux-vserver implements a very weak form of network virtualization: From a networking point of view, vservers live on the host system. So if you don't use care, Vserver traffic to/from zone z will be controlled by the fw->z and z->fw rules and policies rather than by vserver->z and z->vserver rules and policies. Outgoing connections from a vserver will not use the Vserver's address as the SOURCE IP address unless you configure applications running in the Vserver properly. This is especially true for IPv6 applications. Such connections will appear to come from the $FW zone rather than the intended Vserver zone. While you can define the vservers to be associated with the network interface where their IP addresses are added at vserver startup time, Shorewall internally associates all vservers with the loopback interface (lo). Here's an example of how that association can show up: gateway:~# shorewall show zones Shorewall 4.4.11-Beta2 Zones at gateway - Fri Jul 2 12:26:30 PDT 2010 fw (firewall) drct (ipv4) eth4:+drct_eth4 loc (ipv4) eth4:0.0.0.0/0 net (ipv4) eth1:0.0.0.0/0 vpn (ipv4) tun+:0.0.0.0/0 dmz (vserver) lo:70.90.191.124/31 gateway:~#

This is a diagram of the network configuration here at Shorewall.net during the summer of 2010: I created a zone for the vservers as follows: /etc/shorewall/zones: #ZONE TYPE OPTIONS ... fw firewall loc ip #Local Zone drct:loc ipv4 #Direct internet access net ipv4 #Internet vpn ipv4 #OpenVPN clients dmz vserver #Vservers /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth1 detect dhcp,optional,routefilter=0,logmartians,proxyarp=0,nosmurfs,upnp ... /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS drct eth4:dynamic dmz eth1:70.90.191.124/31 While the IP addresses 70.90.191.124 and 70.90.191.125 are configured on eth1, the actual interface name is irrelevate so long as the interface is defined in shorewall-interfaces (5). Shorewall will consider all vserver zones to be associated with the loopback interface (lo). Once a vserver zone is defined, it can be used like any other zone type. Here is the corresponding IPv6 configuration. /etc/shorewall6/zones #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv6 loc ipv6 vpn ipv6 dmz vserver /etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net sit1 detect tcpflags,forward=1,nosmurfs,routeback ... /etc/shorewall6/hosts: #ZONE HOST(S) OPTIONS dmz sit1:[2001:470:e857:1::/64] Note that I choose to place the Vservers on sit1 (the IPv6 net interface) rather than on eth1. Again, it really doesn't matter much.