|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Ideal(istic) Xen firewall design
Hi Andreas,
thanks for your reply.
Andreas Seuss wrote:
>Hi Marcus,
>
>Marcus Brown wrote:
>
>>Hi all,
>>
>>I've managed to setup a Xen firewall/server host.
>>I used a design similar to one posted previously,
>>except that my internal interfaces aren't bridged.
>>It looks something like this (in my head;)):
>>
>>-------------------------------------------------------------------------------------------
>>CURRENT SETUP
>>=============
>> ______________________________________
>> | dom0 |
>> | __________________ |
>> | | Firewall | |
>>Local eth0 =|========| (Shorewall) |==========|= eth1 Internet
>> | |________________| |
>> | vif2.0 | | vif3.0 |
>> | __________|___ __|____________ |
>> | | Web Server | | Mail Server | |
>> | | (Apache2) | | (Courier) | |
>> | |____________| |_____________| |
>> |____________________________________|
>>
>> DETAILS:
>> - Xen 2.0.7 stable
>> - dom0:
>> - 128MB RAM
>> - Debian sid (sid has ext2resize)
>> - boot and root on plain ext3 (no raid or lvm)
>> - striped swap on 2 drives (64MB + 64MB)
>> - all other filesystems on raid0+lvm
>> - eth0 and eth1 are hidden
>> - the domUs are autoloaded in order at boot time
>> using numbered links in /etc/xen/auto:
>> 01-Firewall --> ../Firewall
>> 02-WebServer --> ../WebServer
>> 03-MailServer ..> ../MailServer
>> - Firewall (!dom0)
>> - priviliged driver domain using eth0 and eth1
>> - exports backend network interfaces to domUs
>> - WebServer (domU)
>> - 80MB RAM, 64MB swap, Debian Sarge
>> - MailServer (domU)
>> - 64MB RAM, 64MB swap, Debian Sarge
>>
>> Before you get over excited about hardware, the host is a
>> P3/650 with 640MB RAM on an Asus P2B-VM with 2 x 3c905 nics,
>> 2 x 4.3GB IDE, 1 x 6.4GB IDE, 1 x CD/DVD, and 1 x USB2.0 PCI.
>>
>> PROBLEMS:
>> - As dom0 has no network access, so I'm unable to update the
>> system clock using ntpdate. With the clocks of the domUs
>> being tied to the dom0 clock it is not possible to have
>> the time automatically updated.
>>
>There was a discussion a few weeks ago about setting the time in domUs.
>Quoting Ian and Franck from the thread "[Xen-users] Setting the date
>not working in xen":
>
>"echo 1 > /proc/sys/xen/independent_wallclock
>
>>ntpdate ntp0.oleane.net
>>
>independent_wallclock=1 on the kernel command line should fix this too."
>
>As far as I understand, it is not what the xen architects had in mind,
>but it seems to work.
>
Yes, I read that thread, and as Andy Smith and Nicholas Lee
seem to think, I'd much prefer a single ntp client process in dom0...
I might get desperate, though! :)
>> - There are no hotplug events associated with the backend
>> network for the driver domain, so to bring the vif interfaces
>> up in the Firewall a 1 minute cron script checks vif2.0 & 3.0.
>> Crude.
>>
>No idea here. Doesn't iptables allow to insert rules for interfaces that
>aren't running yet?
>
Yes. I've effectively done that with shorewall.
The issue here is that the interfaces don't come up when they're
created. If there were hotplug events triggered by the vif appearing
I could probably either add the new vif to a bridge, or just assign
an IP to the vif.
>> - The domUs can not be restarted at will as the vifs created
>> in the Firewall are assigned new numbers.
>>
>Let me see if I understand you, "you mean, that after an xm shutdown +
>xm create your vif is no longer vif2.0 but for example vif4.0?". In this
>case, try to append another option in the vif line in your domains
>config file:
>
>vif = [ 'mac=aa:00:00:56:0e:c4, bridge=xen-br0, vifname=e.g.websv' ]
>
>This way your domU's vif will always have the same name. There are some
>mroe interesting options to be found in /usr/lib/python/xen/xm/create.py .
>
Thanks for the hint.
However this makes no difference at either end when using
a backend driver, eg:
vif = [ 'mac=aa:00:00:56:0e:c4, backend=Firewall' ]
I tried
vif = [ 'mac=aa:00:00:56:0e:c4, backend=Firewall, vifname=vif2.0' ]
and
vif = [ 'mac=aa:00:00:56:0e:c4, backend=Firewall, vifname=eth2' ]
to no effect.
Unfortunate, but nice idea!
What I mean is, after an xm shutdown + xm create the vif at the
'backend end' (*snigger*) (ie. at the Firewall) will go from vif2.0
to vif4.0. This means
a) my cron script won't work (unless I add vif1.0-100.0, etc!!)
b) all rules initially set for the interface no longer apply
>I liked your ASCII drawings ;-).
>
Thanks! I prefer crayons, but they leave nasty smudges on the screen ;)
> Hope I could help you a little.
>
Yes, you have, thanks :)
The workarounds suggested are steering me more towards Option C.
Option C
========
________________________________________
| ____________________ |
| | Firewall | |
Local eth0 =|========| (Shorewall) |==========|= eth1 Internet
| |__________________| |
| |eth2 |
| ______________ | _______________ |
| | Web Server | | | Mail Server | |
| | (Apache2) | | | (Courier) | |
| |____________| | |_____________| |
| eth0 \ | / eth0 |
| \ |br0/ |
| _______\__|__/_______ |
| | | |
| | dom0 | |
|________|___________________|_________|
DETAILS:
- dom0 exports a bridge to the Firewall (eth2) to which
the vifs for each domU are added as created
So with that in mind, my diagram now becomes:
Option C-v2
===========
Internet
|
eth1 |
___________________|____________________
| __________|__________ |
| | Firewall | |
Local eth0 =|========| (Shorewall) |=========|= eth2 DMZ (optional)
| |___________________| |
| eth3| |eth4 |
| ______________ | | _______________ |
| | Web Server | | | | iPaq Server | |
| | (Apache2) | | | | (Bluetooth) |=|= USB Host #1
| |____________| | | |_____________| | (for BT Dongle)
| eth0 \ | | / eth0 |
| _______________\| |/ |
| | Mail Server | | | |
| | (Courier) | | | |
| |_____________| | | |
| eth0 \| | |
| | | |
| br0 | | br1 |
| _________|_|_________ |
| | | |
| | dom0 | |
|________|___________________|_________|
Here, it is hoped that the bridges will tie the interface names in
the Firewall domain, and still allow the domUs to be restarted.
DETAILS:
- eth0, eth1 and eth2 are physical devices hidden from dom0
- USB Host #1 is also hidden from dom0
- eth2, eth3, and eth4 are essentially DMZ zones as far
far as the Firewall is concerned.
This sort of thing had been my original plan, however I've so far been
unable to create workable bridges ... I'll keep trying.
(ie. How do I create br0 and br1 in dom0 without physical interfaces?)
For tighter control it might be an idea to create another vif from
the dom0 to the Firewall _just_ for dom0 time updates, etc.
Thanks again,
Marcus.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |