Tom Eastep 2009 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.

Open Virtuoso (OpenVZ) is an open source kernel-based virtualization solution from Parallels (formerly SWSoft). Virtual servers take the form of containers (the OpenVZ documentation calls these Virtual Environments or VEs) which are created via templates. Templates are available for a wide variety of distributions and architectures. OpenVZ requires a patched kernel. Beginning with Lenny, Debian supplies OpenVZ kernels through the standard stable repository.

As with any Shorewall installation involving other software, we suggest that you first install OpenVZ and get it working before attempting to add Shorewall. Alternatively, execute shorewall clear while installing and configuring OpenVZ.

The default OpenVZ networking configuration uses Proxy ARP. You assign containers IP addresses in the IP network from one of your interfaces and you are expected to set the proxy_arp flag on that interface (/proc/sys/net/ipv4/conf/interface/proxy_arp). OpenVZ creates a point-to-point virtual interface in the host with a rather odd configuration. Example (Single VE with IP address 206.124.146.178): gateway:~# ip addr ls dev venet0 10: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/void gateway:~# ip route ls dev venet0 206.124.146.178 scope link gateway:~# The interface has no IP configuration yet it has a route to 206.124.146.178! From within the VE with IP address 206.124.146.178, we have the following: server:~ # ip addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/void inet 127.0.0.1/32 scope host venet0 inet 206.124.146.178/32 scope global venet0:0 server:~ # ip route ls 192.0.2.0/24 dev venet0 scope link 127.0.0.0/8 dev lo scope link default via 192.0.2.1 dev venet0 server:~ # There are a couple of unique features of this configuration: 127.0.0.1/32 is configured on venet0 although the main routing table routes loopback traffic through the lo interface as normal. There is a route to 192.0.2.0/24 through venet0 even though the interface has no IP address in that network. Note: 192.0.2.0/24 is reserved for use in documentation and for testing. The default route is via 192.0.2.1 yet there is no interface on the host with that IP address. All of this doesn't really affect the Shorewall configuration but it is interesting none the less.

We recommend handlintg the strange OpenVZ configuration in Shorewall as follows: /etc/shorewall/zones: ############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS vz ipv4 /etc/shorewall/interfaces: ############################################################################### #ZONE INTERFACE BROADCAST OPTIONS vz venet0 - routeback,rp_filter=0 /etc/shorewall/proxyarp (assumes that external interface is eth0): ############################################################################### #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 206.124.146.178 venet0 eth0 Yes

If you run Shorewall Multi-ISP support on the host, you should arrange for traffic to your containers to use the main routing table. In the configuration shown here, this entry in /etc/shorewall/route_rules is appropriate: #SOURCE DEST PROVIDER PRIORITY - 206.124.146.178 main 1000

You can assign an RFC 1918 address to a VE and use masquerade/SNAT to provide Internet access to the container. This is just a normal simple Shorewall configuration as shown in the Two-interface Quick Start Guide. In this configuration the firewall's internal interface is venet0. Be sure to include the options shown above.

If you have obtained an OpenVZ VE from a service provider, you may find it difficult to configure any type of firewall within your VE. There are two VE parameters that control iptables behavior within the container: --iptables name Restrict access to iptables modules inside a container (The OpenVZ claims that by default all iptables modules that are loaded in the host system are accessible inside a container; I haven't tried that). You can use the following values for name: iptable_filter, iptable_mangle, ipt_limit, ipt_multiport, ipt_tos, ipt_TOS, ipt_REJECT, ipt_TCPMSS, ipt_tcpmss, ipt_ttl, ipt_LOG, ipt_length, ip_conntrack, ip_conntrack_ftp, ip_conntrack_irc, ipt_conntrack, ipt_state, ipt_helper, iptable_nat, ip_nat_ftp, ip_nat_irc, ipt_REDIRECT, xt_mac, ipt_owner. If your provider is using this option, you may be in deep trouble trying to use Shorewall in your container. Look at the output of shorewall show capabilities and weep. Then try to get your provider to remove this restriction on your container. --numiptent num This parameter limits the number of iptables rules that are allowed within the container. The default is 100 which is too small for a Shorewall configuration. We recommend setting this to at least 200. if you see annoying error messages as shown below during start/restart, remove the module-init-tools package. server:/etc/shorewall # shorewall restart Compiling... Compiling /etc/shorewall/zones... Compiling /etc/shorewall/interfaces... Determining Hosts in Zones... Preprocessing Action Files... Pre-processing /usr/share/shorewall/action.Drop... Pre-processing /usr/share/shorewall/action.Reject... Compiling /etc/shorewall/policy... Adding Anti-smurf Rules Adding rules for DHCP Compiling TCP Flags filtering... Compiling Kernel Route Filtering... Compiling Martian Logging... Compiling MAC Filtration -- Phase 1... Compiling /etc/shorewall/rules... Generating Transitive Closure of Used-action List... Processing /usr/share/shorewall/action.Reject for chain Reject... Processing /usr/share/shorewall/action.Drop for chain Drop... Compiling MAC Filtration -- Phase 2... Applying Policies... Generating Rule Matrix... Creating iptables-restore input... Compiling iptables-restore input for chain mangle:... Compiling /etc/shorewall/routestopped... Shorewall configuration compiled to /var/lib/shorewall/.restart Restarting Shorewall.... Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall/tcclear ... Setting up Route Filtering... Setting up Martian Logging... Setting up Proxy ARP... Setting up Traffic Control... Preparing iptables-restore input... Running /usr/sbin/iptables-restore... FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory IPv4 Forwarding Enabled Processing /etc/shorewall/start ... Processing /etc/shorewall/started ... done.