Re: [Xen-users] Firewall in a guest domain?

[Czakó Krisztián <slapic@xxxxxxxxxxx>]

2005-07-19, k keltezéssel 19.37-kor sten ezt írta:
> Mike Hoesing wrote:
> > Anyone want to share a step-by-step howto for approach 4 below?
> 
> >>* Dedicate a physical device to a "firewall domain" and have it filter on 
> >>that 
> >>interface for all the other domains.
> 
> I've got this working, though not to my liking yet. To duplicate my setup:
> 
> Build or otherwise obtain a Xen0 kernel with the modules for your 
> NIC(s). Use 'lspci' to find the PCI addresses for the devices you want 
> to use in the DomU. Update the Xen entry for Xen0 in your GRUB config; 
> mine looks like:
> 
> kernel          /boot/xen-2.0.6.gz dom0_mem=131072 
> physdev_dom0_hide='(01:04.0)(00:04.0)(01:0a.0)'
> 
> Create a Xen guest definition file. **Use the _Xen0_ kernel as the 
> kernel for the guest**. Add the PCI devices you hid from the host kernel 
> to the file. My definition looks like:
> 
> pci = [ '01,04,0', '00,04,0', '01,0a,0' ]
> 
> Copy the /lib/modules data from your Xen0 kernel into the filesystem of 
> the guest. Reboot to put the GRUB changes into effect, then start your 
> guest. Install and configure your firewalling software, and go. I use my 
> guest kernel as my DHCP server/gateway/firewall/router for the rest of 
> my home network, including the host kernel; I just treat the eth0 within 
> the guest as an interface to be NATed.

I use a setup of a domU as firewall. A sample config:
- dom0 only manages the domains and the UPS (serial or usb, initiates
shutdown when UPS batteries are low). Absolutely no network connection.
Dom0 can be managed via a serial console from an other machine or not at
all from any remote location for paranoids like me :-)
For not-so-paranoids(tm), a good solution to connect dom0 to the
firewall domU via a vif interface.
- one dedicated domU as the firewall. All network interfaces are hidden
from dom0 and dedicated to this domU. In my sample setup, I have 2
phisical interfaces in this domU and one logical for other domUs. One
physical nic for internet and one for intranet. The other domUs are in
the DMZ.
- one or more domUs in DMZ, vif connected to the firewall domU.

Here's the topology:

.              +------------------------+
.              | physical machine, dom0 |
.              |   +---------------+    |
-- Internet -------+ Firewall domU +--------- Intranet
.              |   +------+--------+    |
.              |          |             |
.              |          |   DMZ       |
.              |    +-----+-+-------+   |
.              |    |       |       |   |
.              | +--+--+ +--+--+ +--+--+|
.              | |domU1| |domU2| |domU3||
.              | +-----+ +-----+ +-----+|
.              +------------------------+

As shown, the physical nics are directly used in the Firewall domU. The
virtual eth0 interfaces in domU[123] are connected to the Firewall domU
as network backend (vif*.* interfaces in the Firewall domU).
Dom0 has no network interfaces at all. Xen can be managed from the
console (vga/ps2 or serial). In this case, dom0 and the Xen management
interface can only ba accessed if a critical bug found in Xen itself.

The xen domU configs are simple, but there's one big problem. When one
uses dom0 as network backend, the xen scripts will config the new vif
interface as int the configs. However, when one uses a domU as network
backend, noone will do it. As I know, Xen stable/testing can't handle
the event of new nic creation in a domain (a normal nic hotplug event
would be perfect I think). This means that you have to poll for new
unconfigured vif interface (and yes, the vifname= is ignored also in
this case). My solution is the I create a bridge interface in the
Firewall domU at startup. I use Debian sarge so I
use /etc/network/interfaces for this:

auto dmz
iface dmz inet static
        address 192.168.1.254
        network 192.168.1.0
        netmask 255.255.255.0
        broadcast 192.168.1.255
        pre-up brctl addbr $IFACE
        post-down brctl delbr $IFACE
        bridge_fd 0
        bridge_hello 0
        bridge_stp off

This is a permanent interface (not like the vifs) in the domain, so that
daemons can bind to its address at startup.
I have a simple shell script that brings all unconfigured vifs up and
adds them to the dmz bridge:

#!/bin/sh
INTERFACES=`/bin/grep vif /proc/net/dev | /usr/bin/cut -d: -f1`
for IFACE in $INTERFACES ; do
        VIFSTAT=`/sbin/ifconfig | grep $IFACE`
        VSTAT=$?
        if [ $VSTAT != 0 ] ; then
                /sbin/ifconfig $IFACE up
                /usr/sbin/brctl addif dmz $IFACE
        fi
done

I run this script every minutes. Not a nice, but a working solution. The
main backward is that you can use only one dmz in this case, as you
won't know which domU owns a particular vif.

Here's a sample firewall domU xen config:
kernel = "/boot/xen-linux-2.4.29-xenfw-p4"
memory = 256
name = "firewall"
nics = 0
hostname = "firewall"
disk = [
        'phy:vg00/vm-firewall-root,sda1,w',
        'phy:vg00/vm-firewall-swap,sda2,w'
        ]
root = "/dev/sda1"
restart = "onreboot"
pci = [ '1,1,0', '1,3,0', '1,8,0' ]
netif = 1

Note that netif=1. This makes possible for other domUs to use this
domain as a network backend.

Here's a sample dmz domU xen config:
import time
time.sleep(3)

kernel = "/boot/xen-linux-2.6.11-xenu-p4"
memory = 512
name = "mail"
nics = 1
vif = [ 'mac=aa:00:02:08:01:12, backend=firewall]
hostname = "mail"
disk = [
        'phy:vg-bojta/vm-mail-root,sda1,w',
        'phy:vg-bojta/vm-mail-swap,sda2,w',
        ]
root = "/dev/sda1"
restart = "onreboot"

Two notes:
- I've made a dirty hack to delay the startup of this domain. When a
machine is fast and has tow cpus (or hyper-threading), the firewall and
mail domUs are started simultanously, so that mail is started before
firewall can serve it as a network backend. This would cause a
non-working eth0 interface in the mail domU. A nice solution is to wait
for the existance of the firewall domU in the config (as the config
interpreted as a python script, this should be possible, but I don't
know how to program this), but this 3 seconds delay also works for
me(tm). You have to name the configs like this: 01firewall 02mail
03etc.. so that firewall is created first at boot by xendomains start.
- Note the "backend=" in the vif line. This instructs Xen to us the
named running domain as a network backend instead of dom0.

You can use the physical nics in the firewall domU as in a stand-alone
computer firewall.

I hope this helps you.

> My issues so far are 1) extreme instability, which, for now, I'm 
> assuming are caused by the heat in my apartment

No problem here with Intel's e100 and 3Com's 3c59x driven cards.

>  and 2) the wireless NIC 
> I stuck in the guest is up and running according to iwconfig and 
> ifconfig, but I can't get see the signal from a client. There are known 
> issues using a WiFi card behind a bridge, but since it's on the other 
> side in my setup, I'm pretty puzzled. More as I figure stuff out...

Similar problem here with Netgear PCI 802.11b (Kernel 2.6.12,
orinoco/hermes driver). My card starts ok, connects to the AP, but after
a few hours of active operation it stops. The interface is up, iwconfig
works, but no real data transfer. The same card works without Xen.
The solution was an ethernet-wifi bridge and a 3com ethernet card in the
Xen machine.

Regards,
Slapic



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users