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
- MailServer (domU)
- 64MB RAM, 64MB swap
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 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.
- The domUs can not be restarted at will as the vifs created
in the Firewall are assigned new numbers.
-------------------------------------------------------------------------------------------
POSSIBLE SOLUTIONS
=================To get around the problems above, would I be better off with
dom0
handling some/all bridging and networks (and ntpdate)? A few posts in the
list have suggested something like this, but I can''t see how
it''s done.
I can think of a few possibilities, but so far have been unable to
implement any of them (hence this verbose and messy post;)).
Option A
======= ________________________________________
| ____________________ |
| | Firewall | |
| | (Shorewall) | |
| |__________________| |
| | | | |
| ______________ | | | _______________ |
| | Web Server | | | | | Mail Server | |
| | (Apache2) | | | | | (Courier) | |
| |____________| | | | |_____________| |
| | | | | | |
| | | | | | |
| ___|____|_|_|____|___ |
| | | |
Local eth0 =|========| dom0 |=========|= eth1 Internet
|________|___________________|_________|
DETAILS:
- dom0
- eth0 and eth1 are associated with separate bridges which
are exported to the Firewall.
- backend network interfaces are exported to the domUs and
associated with an internal DMZ bridge (also exported to
the Firewall).
Option B
======= ________________________________________
| ____________________ |
| | Firewall | |
| | (Shorewall) |==========|= eth1 Internet
| |__________________| |
| | | |
| ______________ | | _______________ |
| | Web Server | | | | Mail Server | |
| | (Apache2) | | | | (Courier) | |
| |____________| | | |_____________| |
| | | | | |
| | | | | |
| ___|____|___|____|___ |
| | | |
Local eth0 =|========| dom0 | |
|________|___________________|_________|
DETAILS:
- dom0 exports a bridge with eth0 to Firewall, and
a bridge with network backends to the domUs
Option C
======= ________________________________________
| ____________________ |
| | Firewall | |
Local eth0 =|========| (Shorewall) |==========|= eth1 Internet
| |__________________| |
| | |
| ______________ | _______________ |
| | Web Server | | | Mail Server | |
| | (Apache2) | | | (Courier) | |
| |____________| | |_____________| |
| | | | |
| | | | |
| ___|______|______|___ |
| | | |
| | dom0 | |
|________|___________________|_________|
DETAILS:
- dom0 exports a network backend which is bridged
to domUs as they are brought up
-------------------------------------------------------------------------------------------
So far, Option C looks like a possibility ...
however, as with this email, I got stuck :)
Thanks for reading the preamble, now on to my question:
QUESTION:
I think I''ve explained what I want ... how do I do it?
Marcus.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
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 > - MailServer (domU) > - 64MB RAM, 64MB swap > > 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.netindependent_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.> - 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?> - 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 . I liked your ASCII drawings ;-). Hope I could help you a little. Regards, Andreas>------------------------------------------------------------------------------------------- >POSSIBLE SOLUTIONS >=================>To get around the problems above, would I be better off with dom0 >handling some/all bridging and networks (and ntpdate)? A few posts in the >list have suggested something like this, but I can''t see how it''s done. >I can think of a few possibilities, but so far have been unable to >implement any of them (hence this verbose and messy post;)). > >Option A >=======> ________________________________________ > | ____________________ | > | | Firewall | | > | | (Shorewall) | | > | |__________________| | > | | | | | > | ______________ | | | _______________ | > | | Web Server | | | | | Mail Server | | > | | (Apache2) | | | | | (Courier) | | > | |____________| | | | |_____________| | > | | | | | | | > | | | | | | | > | ___|____|_|_|____|___ | > | | | | >Local eth0 =|========| dom0 |=========|= eth1 Internet > |________|___________________|_________| > > > DETAILS: > - dom0 > - eth0 and eth1 are associated with separate bridges which > are exported to the Firewall. > - backend network interfaces are exported to the domUs and > associated with an internal DMZ bridge (also exported to > the Firewall). > >Option B >=======> ________________________________________ > | ____________________ | > | | Firewall | | > | | (Shorewall) |==========|= eth1 Internet > | |__________________| | > | | | | > | ______________ | | _______________ | > | | Web Server | | | | Mail Server | | > | | (Apache2) | | | | (Courier) | | > | |____________| | | |_____________| | > | | | | | | > | | | | | | > | ___|____|___|____|___ | > | | | | >Local eth0 =|========| dom0 | | > |________|___________________|_________| > > DETAILS: > - dom0 exports a bridge with eth0 to Firewall, and > a bridge with network backends to the domUs > >Option C >=======> ________________________________________ > | ____________________ | > | | Firewall | | >Local eth0 =|========| (Shorewall) |==========|= eth1 Internet > | |__________________| | > | | | > | ______________ | _______________ | > | | Web Server | | | Mail Server | | > | | (Apache2) | | | (Courier) | | > | |____________| | |_____________| | > | | | | | > | | | | | > | ___|______|______|___ | > | | | | > | | dom0 | | > |________|___________________|_________| > > > DETAILS: > - dom0 exports a network backend which is bridged > to domUs as they are brought up > >------------------------------------------------------------------------------------------- > >So far, Option C looks like a possibility ... >however, as with this email, I got stuck :) > >Thanks for reading the preamble, now on to my question: > >QUESTION: >I think I''ve explained what I want ... how do I do it? > >Marcus. > > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@lists.xensource.com http://lists.xensource.com/xen-users
Hi B. B.G. Bruce wrote:>>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. >> >> > >Sorry, haven''t had time to follow the thread completely, but I''ve done >something similar to your C-V2 (using the dummy driver (dummy0-3). Have >you thought of/tried this? >Thought _and_ tried it without much success. Mind you that was a week or so ago, and I''ve learnt more since. Problems/questions I had included: - how do I use multiple dummies! (*snicker*) ie. dummy0 and dummy1 EDIT: scrub that : modprobe dummy -o dummy0 modprobe dummy -o dummy1 - is there any advantage/reason to try vlan or tun/tap devices? I understand from various postings that I need to manually create the extra bridges before bringing up the Firewall domain. I guess I could do that in a number of ways, but is there a ''Xen approved'' method? For a bridge that I want dom0 to communicate on, I assign an IP to that bridge. However for bridges that dom0 has nothing to do with I should not assign IPs. Correct? If this is the case, why do I need a dummy at all? So the diagram ends up being like this, maybe???? Option C-v3 ========== Internet | eth1 ______________________|_______________________ | _____________|_______________ | | | Firewall | | Local eth0 =|========| (Shorewall) |=======|= eth2 DMZ (optional) | |___________________________| | | eth4 | eth5 | | ______________ | eth3 | _______________ | | | Web Server | | | | | iPaq Server | | | | (Apache2) | | | | | (Bluetooth) |=|= USB Host #1 | |____________| | | | |_____________| | (for BT Dongle) | eth0 \ | | | / eth0 | | _______________\| | |/ | | | Mail Server | | | | | | | (Courier) | | | | | | |_____________| | | | | | eth0 \| | | | | | | | | | br1 | br2 | | ! br0 ! | | _____________|_____________ | | | | | | | dom0 | | |________|_________________________|_________| Thanks for the hint, I was just compiling vlan support into dom0 when your message arrived, so you''ve probably saved me from wandering further into a pointless excercise! :) I''ll start playing with dummies instead! lol Better have a coffee first, in case I spit ... I''ll quit now :) Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcus Brown schrieb:> Option C-v3 > >==========> Internet > | > eth1 > ______________________|_______________________ > | _____________|_______________ | > | | Firewall | | >Local eth0 =|========| (Shorewall) |=======|= eth2 DMZ (optional) > | |___________________________| | > | eth4 | eth5 | > | ______________ | eth3 | _______________ | > | | Web Server | | | | | iPaq Server | | > | | (Apache2) | | | | | (Bluetooth) |=|= USB Host #1 > | |____________| | | | |_____________| | (for BT Dongle) > | eth0 \ | | | / eth0 | > | _______________\| | |/ | > | | Mail Server | | | | | > | | (Courier) | | | | | > | |_____________| | | | | > | eth0 \| | | | > | | | | | > | br1 | br2 | > | ! br0 ! | > | _____________|_____________ | > | | | | > | | dom0 | | > |________|_________________________|_________| > > >Thanks for the hint, I was just compiling vlan support into dom0 when >your message arrived, so you''ve probably saved me from wandering >further into a pointless excercise! :) >I''ll start playing with dummies instead! lol > >I will soon try something similar, so I try following the thread. :-) What exactly is a dummy interface (I have found some hints on its existence, but nothing detailed)? And can I configure it like a real interface in /etc/network/interfaces with "iface dummyX inet static ..."? Regarding your drawing: Is the Firewall a xen guest system? And if yes, how did you transfer the real interfaces to it? If no, how is the firewall separated from dom0? I am afraid to come up with unqualified questions, but I just started digging into complex networking schemes. Thanks for any hint or help. Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 8/12/05, Marcus Brown <marcusbrutus@internode.on.net> wrote:> > I understand from various postings that I need to manually create the > extra bridges before bringing up the Firewall domain. > I guess I could do that in a number of ways, > but is there a ''Xen approved'' method?I''m not doing the firewall with Xen thing yet, but this is what I''ve done for both Xen and UML for my ''virutal internal'' networks: /etc/network/interfaces auto internal-br iface internal-br inet static address 10.1.0.254 netmask 255.255.0.0 network 10.1.0.0 broadcast 10.1.255.255 bridge_ports eth1 bridge_fd 0 bridge_hello 1 bridge_stp off up route add -net 192.168.1.0/24 gw 10.1.0.1 down route del -net 192.168.1.0/24 gw 10.1.0.1 Note, in your setup you might use dummy0/1 instead of eth1 in the above. I leave the default xen-br to xen itself to configure. I used dummy interfaces succesfully with UML, I''m not sure how well they would work with Xen. Single processor Xen seems to have performance issues with networking between virtual domUs on the same host. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi folks, I would like to throw my bits and pieces into the discussion. Since I am not a network geek when it comes to complex scenarios I would be happy if you could comment on my way to do it. My goal: Have a base system (xen0) that works as a firewall and router. It has an external interface (eth0, ppp0) for dsl and several interfaces for internal networks. It should also be the firewall and router for at least 2 guest systems (domU). I set up firewalling and routing with shorewall since that comes in more handy than configuring netfilter directly (I think). Next I created a dummy interface and connected it to the bridge xen-br0. Concerning ifconfig and brctl, that works. Via Shorewall I configured the dummy interface as a zone of its own like a local zone, with netfiltering and routing according to a standard local zone. The idea was handling the network of the guest systems like an internal hardware network segment that is connected to the firewall. Any ideas so far? Any comments, cries or wrought hands? I cannot test network connections of the guest system since it does not start due to an error I have not found documented anywhere – I hope that has nothing to do with the networking part – but I am impatient and would like to know what the geeks think of this concept. Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Dirk, Dirk H. Schulz wrote:> Marcus Brown schrieb: > >> Option C-v3 >> ==========>> Internet >> | >> eth1 >> ______________________|_______________________ >> | _____________|_______________ | >> | | Firewall | | >> Local eth0 =|========| (Shorewall) |=======|= eth2 DMZ (optional) >> | |___________________________| | >> | eth4 | eth5 | >> | ______________ | eth3 | _______________ | >> | | Web Server | | | | | iPaq Server | | >> | | (Apache2) | | | | | (Bluetooth) |=|= USB Host #1 >> | |____________| | | | |_____________| | (for BT Dongle) >> | eth0 \ | | | / eth0 | >> | _______________\| | |/ | >> | | Mail Server | | | | | >> | | (Courier) | | | | | >> | |_____________| | | | | >> | eth0 \| | | | >> | | | | | >> | br1 | br2 | >> | ! br0 ! | >> | _____________|_____________ | >> | | | | >> | | dom0 | | >> |________|_________________________|_________| >> >> >> Thanks for the hint, I was just compiling vlan support into dom0 when >> your message arrived, so you've probably saved me from wandering >> further into a pointless excercise! :) >> I'll start playing with dummies instead! lol >> >> > I will soon try something similar, so I try following the thread. :-) > > What exactly is a dummy interface (I have found some hints on its > existence, but nothing detailed)? And can I configure it like a real > interface in /etc/network/interfaces with "iface dummyX inet static ..."?Linux Kernel v2.6.11.12-xen0 Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌─────────────────────────────────── Dummy net driver support ────────────────────────────────────┐ │ CONFIG_DUMMY: │ │ │ │ This is essentially a bit-bucket device (i.e. traffic you send to │ │ this device is consigned into oblivion) with a configurable IP │ │ address. It is most commonly used in order to make your currently │ │ inactive SLIP address seem like a real address for local programs. │ │ If you use SLIP or PPP, you might want to say Y here. Since this │ │ thing often comes in handy, the default is Y. It won't enlarge your │ │ kernel either. What a deal. Read about it in the Network │ │ Administrator's Guide, available from │ │ <http://www.tldp.org/docs.html#guide>. │ │ │ │ To compile this driver as a module, choose M here: the module │ │ will be called dummy. If you want to use more than one dummy │ │ device at a time, you need to compile this driver as a module. │ │ Instead of 'dummy', the devices will then be called 'dummy0', │ │ 'dummy1' etc. │ │ │ │ Symbol: DUMMY [=m] │ │ Prompt: Dummy net driver support │ │ Defined at drivers/net/Kconfig:24 │ │ Depends on: NETDEVICES │ │ Location: │ │ -> Device Drivers │ │ -> Networking support │ │ -> Network device support (NETDEVICES [=y]) │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ modprobe dummy -o dummy0 if=dummy0 modprobe dummy -o dummy2 if=dummy1 modprobe dummy -o dummy1 if=dummy2 eg: /etc/modules dummy -o dummy0 dummy -o dummy1 dummy -o dummy2 ...etc /etc/network/interfaces auto dummy0 iface dummy0 inet static address 192.168.254.1 netmask 255.255.255.248 network 192.168.254.0 broadcast 192.168.254.7 gateway 192.168.254.6 auto dummy1 iface dummy1 inet static address 192.168.254.9 netmask 255.255.255.248 network 192.168.254.8 broadcast 192.168.254.15 post-up brctl addbr br1 || true post-up brctl addif br1 dummy1 || true # post-up ifconfig br1 192.168.254.33/28 post-down brctl delif br1 dummy1 auto dummy2 iface dummy2 inet static address 192.168.254.17 netmask 255.255.255.248 network 192.168.254.16 broadcast 192.168.254.23 post-up brctl addbr br2 || true post-up brctl addif br2 dummy2 || true # post-up ifconfig br2 192.168.254.33/28 post-down brctl delif br2 dummy2 ...etc my /etc/xen/Firewall now contains: nics=11 vif = [ 'mac=aa:00:00:00:22:01, bridge=br10', 'mac=aa:00:00:25:40:01, bridge=xen-br0', 'mac=aa:00:00:25:40:09, bridge=br1', 'mac=aa:00:00:25:40:17, bridge=br2', 'mac=aa:00:00:25:40:25, bridge=br3', 'mac=aa:00:00:25:40:33, bridge=br4', 'mac=aa:00:00:25:40:49, bridge=br5', 'mac=aa:00:00:25:40:45, bridge=br6', 'mac=aa:00:00:25:40:73, bridge=br7', 'mac=aa:00:00:25:40:81, bridge=br8', 'mac=aa:00:00:25:40:97, bridge=br9' ] (br10 is currently just a place holder, as I'm missing a 3rd network card atm)> > Regarding your drawing: Is the Firewall a xen guest system? And if > yes, how did you transfer the real interfaces to it? If no, how is the > firewall separated from dom0?The Firewall is a privileged domain (dom1 if you like:) ). The PCI network cards are hidden from dom0, and exported to the Firewall using it's config script. Linux Kernel v2.6.11.12-xen0 Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [*] Privileged Guest (domain 0) │ │ │ │ --- Physical device access │ │ │ │ [*] Block-device backend driver │ │ │ │ [*] Network-device backend driver │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ Linux Kernel v2.6.11.12-Firewall Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [*] Privileged Guest (domain 0) │ │ │ │ --- Physical device access │ │ │ │ [*] Block-device backend driver │ │ │ │ [*] Network-device backend driver │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ Linux Kernel v2.6.11.12-xenU Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [ ] Privileged Guest (domain 0) │ │ │ │ [ ] Physical device access │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ dom0 /boot/grub/menu.lst includes: title Debian Xen Stable no-initrd 2.0.7 2.6.11.12-xen0 root (hd0,0) kernel /xen-2.0.7.gz root=/dev/hda3 ro dom0_mem=131072 physdev_dom0_hide=(00:0a.0)(00:0b.0)(00:09.0)(00:09.1)(00:09.2)(00:09.3)(00:06.0) module /vmlinuz-2.6.11.12-xen0 root=/dev/hda3 ro console=tty0 savedefault boot /etc/xen/Firewall includes pci = ['00,0b,0', '00,0a,0' ] I've got a coloured version (hey it's therapy!) with more domUs, but here's an ASCII version of the current design: OPTION C-v3.1 ============Internet | eth1 ________________________________________|__________________________________________ | ________________________________|__________________________________ | | | | | | | Firewall | | Local eth0 =|=======| (dom1) |=======|= eth2 DMZ | |_________________________________________________________________| | (optional) | | | | | | eth3 eth4 eth5 | | | ________________ | ______________ | _______________ | | | | Proxy Server | | | Web Server | | | iPaq Server | | | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 | | |______________| | |____________| | |_____________| | (for BT Dongle) | | / | / | / | ( and cradle ) | | / | / _______________ | / | | |/ |/ | Mail Server | |/ | | | | | (domU3) | | | | | | |_____________| | | | | | / | | | | | / | | | | |/ | | | xen-br0 br1 br1 | | | ! ! | | ___|_______________________________________________________________ | | | | | | | dom0 | | |_______|_________________________________________________________________|_______| Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Marcus, thanks for so much info! Just a short question before I start digging into your configs: What do you gain by running the firewall inside a privileged guest system instead of inside dom0? Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Dirk, stuffed that last one up, still getting used to Thunderbird ;) 2nd attempt: Hi Dirk, OOPS, stuffed up the last msg, still getting used to Thunderbird. 2nd attempt :) Dirk H. Schulz wrote:> Marcus Brown schrieb: > >> Option C-v3 >> >> ==========>> Internet >> | >> eth1 >> ______________________|_______________________ >> | _____________|_______________ | >> | | Firewall | | >> Local eth0 =|========| (Shorewall) |=======|= eth2 DMZ (optional) >> | |___________________________| | >> | eth4 | eth5 | >> | ______________ | eth3 | _______________ | >> | | Web Server | | | | | iPaq Server | | >> | | (Apache2) | | | | | (Bluetooth) |=|= USB Host #1 >> | |____________| | | | |_____________| | (for BT Dongle) >> | eth0 \ | | | / eth0 | >> | _______________\| | |/ | >> | | Mail Server | | | | | >> | | (Courier) | | | | | >> | |_____________| | | | | >> | eth0 \| | | | >> | | | | | >> | br1 | br2 | >> | ! br0 ! | >> | _____________|_____________ | >> | | | | >> | | dom0 | | >> |________|_________________________|_________| >> >> >> Thanks for the hint, I was just compiling vlan support into dom0 when >> your message arrived, so you've probably saved me from wandering >> further into a pointless excercise! :) >> I'll start playing with dummies instead! lol >> >> > I will soon try something similar, so I try following the thread. :-) > > What exactly is a dummy interface (I have found some hints on its existence, but nothing detailed)? And can I configure it like a real interface in /etc/network/interfaces with "iface dummyX inet static ..."? >Linux Kernel v2.6.11.12-xen0 Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌─────────────────────────────────── Dummy net driver support ────────────────────────────────────┐ │ CONFIG_DUMMY: │ │ │ │ This is essentially a bit-bucket device (i.e. traffic you send to │ │ this device is consigned into oblivion) with a configurable IP │ │ address. It is most commonly used in order to make your currently │ │ inactive SLIP address seem like a real address for local programs. │ │ If you use SLIP or PPP, you might want to say Y here. Since this │ │ thing often comes in handy, the default is Y. It won't enlarge your │ │ kernel either. What a deal. Read about it in the Network │ │ Administrator's Guide, available from │ │ <http://www.tldp.org/docs.html#guide>. │ │ │ │ To compile this driver as a module, choose M here: the module │ │ will be called dummy. If you want to use more than one dummy │ │ device at a time, you need to compile this driver as a module. │ │ Instead of 'dummy', the devices will then be called 'dummy0', │ │ 'dummy1' etc. │ │ │ │ Symbol: DUMMY [=m] │ │ Prompt: Dummy net driver support │ │ Defined at drivers/net/Kconfig:24 │ │ Depends on: NETDEVICES │ │ Location: │ │ -> Device Drivers │ │ -> Networking support │ │ -> Network device support (NETDEVICES [=y]) │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ eg: /etc/modules dummy -o dummy0 dummy -o dummy1 dummy -o dummy2 ...etc /etc/network/interfaces auto dummy0 iface dummy0 inet static address 192.168.254.1 netmask 255.255.255.248 network 192.168.254.0 broadcast 192.168.254.7 gateway 192.168.254.6 auto dummy1 iface dummy1 inet static address 192.168.254.9 netmask 255.255.255.248 network 192.168.254.8 broadcast 192.168.254.15 post-up brctl addbr br1 || true post-up brctl addif br1 dummy1 || true # post-up ifconfig br1 192.168.254.33/28 post-down brctl delif br1 dummy1 auto dummy2 iface dummy2 inet static address 192.168.254.17 netmask 255.255.255.248 network 192.168.254.16 broadcast 192.168.254.23 post-up brctl addbr br2 || true post-up brctl addif br2 dummy2 || true # post-up ifconfig br2 192.168.254.33/28 post-down brctl delif br2 dummy2 ...etc my /etc/xen/Firewall now contains: nics=11 vif = [ 'mac=aa:00:00:00:22:01, bridge=br10', 'mac=aa:00:00:25:40:01, bridge=xen-br0', 'mac=aa:00:00:25:40:09, bridge=br1', 'mac=aa:00:00:25:40:17, bridge=br2', 'mac=aa:00:00:25:40:25, bridge=br3', 'mac=aa:00:00:25:40:33, bridge=br4', 'mac=aa:00:00:25:40:49, bridge=br5', 'mac=aa:00:00:25:40:45, bridge=br6', 'mac=aa:00:00:25:40:73, bridge=br7', 'mac=aa:00:00:25:40:81, bridge=br8', 'mac=aa:00:00:25:40:97, bridge=br9' ] (br10 is currently just a place holder, as I'm missing a 3rd network card atm)> Regarding your drawing: Is the Firewall a xen guest system? And if yes, how did you transfer the real interfaces to it? If no, how is the firewall separated from dom0? >The Firewall is a privileged domain (dom1 if you like:) ). The PCI network cards are hidden from dom0, and exported to the Firewall using it's config script. The configs look like this: Linux Kernel v2.6.11.12-xen0 Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [*] Privileged Guest (domain 0) │ │ │ │ --- Physical device access │ │ │ │ [*] Block-device backend driver │ │ │ │ [*] Network-device backend driver │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ Linux Kernel v2.6.11.12-Firewall Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [*] Privileged Guest (domain 0) │ │ │ │ --- Physical device access │ │ │ │ [*] Block-device backend driver │ │ │ │ [*] Network-device backend driver │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ Linux Kernel v2.6.11.12-xenU Configuration ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────── XEN ──────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [ ] Privileged Guest (domain 0) │ │ │ │ [ ] Physical device access │ │ │ │ [*] Block-device frontend driver │ │ │ │ [*] Network-device frontend driver │ │ │ │ [ ] Pipelined transmitter (DANGEROUS) │ │ │ │ [*] Scrub memory before freeing it to Xen │ │ │ │ Processor Type (X86) ---> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ dom0 /boot/grub/menu.lst includes: title Debian Xen Stable no-initrd 2.0.7 2.6.11.12-xen0 root (hd0,0) kernel /xen-2.0.7.gz root=/dev/hda3 ro dom0_mem=131072 physdev_dom0_hide=(00:0a.0)(00:0b.0)(00:09.0)(00:09.1)(00:09.2)(00:09.3)(00:06.0) module /vmlinuz-2.6.11.12-xen0 root=/dev/hda3 ro console=tty0 savedefault boot /etc/xen/Firewall includes pci = ['00,0b,0', '00,0a,0' ] So, in Firewall domain, lspci now shows: 0000:00:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 0000:00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64)> I am afraid to come up with unqualified questions, but I just started digging into complex networking schemes.I guess someone will tell you if your question isn't relevant to the list. I've got a coloured version (hey it's therapy!) with more domUs, but here's an ASCII version of the current design: OPTION C-v3.1 ============ Internet | eth1 ________________________________________|__________________________________________ | ________________________________|__________________________________ | | | | | | | Firewall | | Local eth0 =|=======| (dom1) |=======|= eth2 DMZ | |_________________________________________________________________| | (optional) | | | | | | eth3 eth4 eth5 | | | ________________ | ______________ | _______________ | | | | Proxy Server | | | Web Server | | | iPaq Server | | | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 | | |______________| | |____________| | |_____________| | (for BT Dongle) | | / | / | / | ( and cradle ) | | / | / _______________ | / | | |/ |/ | Mail Server | |/ | | | | | (domU3) | | | | | | |_____________| | | | | | / | | | | | / | | | | |/ | | | xen-br0 br1 br1 | | | ! ! | | ___|_______________________________________________________________ | | | | | | | dom0 | | |_______|_________________________________________________________________|_______| Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Dirk, Dirk H. Schulz wrote:> Hi Marcus, > > thanks for so much info! > > Just a short question before I start digging into your configs: What do > you gain by running the firewall inside a privileged guest system > instead of inside dom0? >It''s modular, restartable, replaceable, ... (ie. I can reboot the firewall without rebooting all the domUs) errr oh, and someone gaining root access to the firewall won''t be able to play with xend, or the filesystems of the domUs. I''m sure there are other good reasons :) I''ve got all my domains (except dom0) on lvm+raid so snapshotting is a great way of testing and making backups. This is just the start, though ... more ideas being worked on atm. Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Markus, Marcus Brown schrieb:>Hi Dirk, > >Dirk H. Schulz wrote: > > >>Hi Marcus, >> >>thanks for so much info! >> >>Just a short question before I start digging into your configs: What do >>you gain by running the firewall inside a privileged guest system >>instead of inside dom0? >> >> >> > >It''s modular, restartable, replaceable, ... >(ie. I can reboot the firewall without rebooting all the domUs) > >That is a very good reason. I did not think of that, I have to admit.>errr >oh, and someone gaining root access to the firewall won''t be able to >play with xend, or the filesystems of the domUs. > >Oh, err, shouldn''t it be more difficult to get root access to the firewall than to the other systems? That''s one thing firewalls are for, aren''t they? :-)>I''m sure there are other good reasons :) > >Yes, there are. This way one could have two firewalls to hide the domU network behind and a vpn server inbetween just for training (setting up vpn with dynamic routing, e.g.). Lots to play with on rainy weekends. :-) One could even setup complex OSPF scenarios just for testing. I start loving this concept ... Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Marcus Brown wrote: > Hi Dirk, > > Dirk H. Schulz wrote: > > Hi Marcus, > > > > thanks for so much info! > > > > Just a short question before I start digging into your > configs: What > > do you gain by running the firewall inside a privileged > guest system > > instead of inside dom0? > > > > It''s modular, restartable, replaceable, ... > (ie. I can reboot the firewall without rebooting all the > domUs) errr oh, and someone gaining root access to the > firewall won''t be able to play with xend, or the filesystems > of the domUs. > > I''m sure there are other good reasons :)Yep, like if you are consolidating an existing "bunch" of servers you can (probably) keep your current set of firewall rules that your current physical firewall uses. I''m currently looking at using Xen to consolidate our firewall, front end (mail, dns, proxy), application & file servers all into the one box (3 of those sit 98% idle.....). The complex firewall rules (5 diff zones) are built with fwbuilder (www.fwbuilder.org) and so I can probably just rename the ethernet devices and hit "compile" to generate the iptables rules for the new Xen firewall. Hopefully this thread has given me enough info to handle all the bridging! :) But it is still tempting to just do away with the seperate firewall vm and do all the firewalling in Dom0!> I''ve got all my domains (except dom0) on lvm+raid so > snapshotting is a great way of testing and making backups. > > This is just the start, though ... more ideas being worked on atm. > > Marcus. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Aug 15, 2005 at 09:34:10AM +1200, Mike Tierney wrote:> But it is still tempting to just do away with the seperate firewall vm and > do all the firewalling in Dom0!That seems perfectly reasonable to me for a filtering router sort of firewall with no exposed services. Unless you''re going to make dom0 itself console-only access (with good physical security on that access), I can''t see where it does much good to push the filtering into a domU. Of course if you''re shutting down and restarting the filtering firewall, you''d probably better be accessing dom0 from console anyway. :-/ Frankly, if you have *any* non-console access to dom0 (or poor physical security), I would expect that to be a bigger threat than a break-in through the kernel''s IP stack/netfilter. But there''s no one right answer - it really depends on your specific threat model and all the rest of that stuff that we all prefer not to quantify because it''s so much work to get results that you know have a lot of best guesses and estimates in ''em... But without that judging the tradeoff is *really* guesswork. -- In software as well as in modern art, the distinction between intentional and accidental omissions is often difficult to make. -- Andrew Hunt & David Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Mike, Mike Tierney schrieb:>But it is still tempting to just do away with the seperate firewall vm and >do all the firewalling in Dom0! > >There is one more reason to put the firewall into a guest system: The guests use the smaller kernels (without hardware support etc.), so there is less possibility of kernel bugs that can be used to crack the firewall. It is more of a statistic perspective but with firewalling everything should be used to avoid leaks, I think. I begin to like the idea of moving my firewall into a guest system. I will start first work on that today. Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Dirk and Mike, Dirk H. Schulz wrote:> Hi Mike, > > Mike Tierney schrieb: > >> But it is still tempting to just do away with the seperate firewall vm >> and >> do all the firewalling in Dom0! >> >>Having got my Firewall domain working reasonably well I''d have to say that I wouldn''t go back! :) Extremely handy being able to create a Firewall, restart it, swap in another version ... all without having to restart my other domains!> There is one more reason to put the firewall into a guest system: The > guests use the smaller kernels (without hardware support etc.), so there > is less possibility of kernel bugs that can be used to crack the > firewall. It is more of a statistic perspective but with firewalling > everything should be used to avoid leaks, I think. >The firewall domain _does_ have hardware support (ie. network cards), so I''m not sure if your logic applies. (ie. Firewall still has DMA) But, still, everything else is/can be virtualised, so it''s still a step up from a dom0 (IMHO). Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Aug 15, 2005 at 08:01:01AM +0200, Dirk H. Schulz wrote:> There is one more reason to put the firewall into a guest system: The > guests use the smaller kernels (without hardware support etc.), so there > is less possibility of kernel bugs that can be used to crack the > firewall. It is more of a statistic perspective but with firewalling > everything should be used to avoid leaks, I think.However, the parts of the kernel that an attacker has leverage on (the TCP/IP stack and netfilter) are the same whether dom0 or domU. I''ll grant you the NIC driver, but I refuse to worry greatly about it. :-) -- There is overwhelming evidence that the higher the level of self-esteem, the more likely one will be to treat others with respect, kindness, and generosity. -- Nathaniel Branden _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi all, Marcus Brown wrote:> I''ve got a coloured version (hey it''s therapy!) with more domUs, > but here''s an ASCII version of the current design: > > OPTION C-v3.1 > ============> Internet > | > eth1 > ________________________________________|__________________________________________ > | ________________________________|__________________________________ | > | | | | > | | Firewall | | > Local eth0 =|=======| (dom1) |=======|= eth2 DMZ > | |_________________________________________________________________| | (optional) > | | | | | > | eth3 eth4 eth5 | > | | ________________ | ______________ | _______________ | > | | | Proxy Server | | | Web Server | | | iPaq Server | | > | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 > | | |______________| | |____________| | |_____________| | (for BT Dongle) > | | / | / | / | ( and cradle ) > | | / | / _______________ | / | > | |/ |/ | Mail Server | |/ | > | | | | (domU3) | | | > | | | |_____________| | | > | | | / | | > | | | / | | > | | |/ | | > | xen-br0 br1 br1 | > | | ! ! | > | ___|_______________________________________________________________ | > | | | | > | | dom0 | | > |_______|_________________________________________________________________|_______| >This setup works extremely well for my purposes. I have, however, noticed network performance issues when scp''ing from dom0 to a client in the local ''Green Zone''. Rather than the 4MB/s I''d expect (PIIX4 ata33 IDE with software raid), I''m only getting 1.4MB/s :( (screen shots here: http://marcusbrutus.cust.internode.on.net/Computers/C3-1 ) I appreciate there''s a lot more calculation going on, but still ...>Mike Tierney schrieb: >> > >>>> But it is still tempting to just do away with the seperate firewall vm >>>> and >>>> do all the firewalling in Dom0! >>>> >>>>With this in mind, I might be prepared to change my setup to something like this: OPTION C-v3.2 ============ Internet | eth1 ________________________________________|__________________________________________ | ________________________________|__________________________________ | | | | | | | Firewall | | | | (dom1) |=======|= eth2 DMZ | |_________________________________________________________________| | (optional) | | | | | | eth3 eth4 eth5 | | | ________________ | ______________ | _______________ | | | | Proxy Server | | | Web Server | | | iPaq Server | | | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 | | |______________| | |____________| | |_____________| | (for BT Dongle) | | / | / | / | ( and cradle ) | | / | / _______________ | / | | |/ |/ | Mail Server | |/ | | | | | (domU3) | | | | | | |_____________| | | | | | / | | | | | / | | | | |/ | | | xen-br0 br1 br1 | | | ! ! | | | _____________________________________________________________ | | \ | | | Local eth0 =|============+| dom0 | | |_____________|___________________________________________________________|_______| However, as the bandwidth throughput issue would still remain for all the other domains, I''m not sure if there''s a real benefit. I have a burner in this machine, with the hopes of using it for domain filesystem backups in the future. Can I assume that this performance would be improved dramatically using a MP machine (or HT) ? Are there other ways of improving this performance? Appreciate your advice. Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi all, Marcus Brown wrote:> I''ve got a coloured version (hey it''s therapy!) with more domUs, > but here''s an ASCII version of the current design: > > OPTION C-v3.1 > ============> Internet > | > eth1 > ________________________________________|__________________________________________ > | ________________________________|__________________________________ | > | | | | > | | Firewall | | > Local eth0 =|=======| (dom1) |=======|= eth2 DMZ > | |_________________________________________________________________| | (optional) > | | | | | > | eth3 eth4 eth5 | > | | ________________ | ______________ | _______________ | > | | | Proxy Server | | | Web Server | | | iPaq Server | | > | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 > | | |______________| | |____________| | |_____________| | (for BT Dongle) > | | / | / | / | ( and cradle ) > | | / | / _______________ | / | > | |/ |/ | Mail Server | |/ | > | | | | (domU3) | | | > | | | |_____________| | | > | | | / | | > | | | / | | > | | |/ | | > | xen-br0 br1 br1 | > | | ! ! | > | ___|_______________________________________________________________ | > | | | | > | | dom0 | | > |_______|_________________________________________________________________|_______| >This setup works extremely well for my purposes. I have, however, noticed network performance issues when scp''ing from dom0 to a client in the local ''Green Zone''. Rather than the 4MB/s I''d expect (PIIX4 ata33 IDE with software raid), I''m only getting 1.4MB/s :( (screen shots here: http://marcusbrutus.cust.internode.on.net/Computers/C3-1 ) I appreciate there''s a lot more calculation going on, but still ...>Mike Tierney schrieb: >> > >>>> But it is still tempting to just do away with the seperate firewall vm >>>> and >>>> do all the firewalling in Dom0! >>>> >>>>With this in mind, I might be prepared to change my setup to something like this: OPTION C-v3.2 ============ Internet | eth1 ________________________________________|__________________________________________ | ________________________________|__________________________________ | | | | | | | Firewall | | | | (dom1) |=======|= eth2 DMZ | |_________________________________________________________________| | (optional) | | | | | | eth3 eth4 eth5 | | | ________________ | ______________ | _______________ | | | | Proxy Server | | | Web Server | | | iPaq Server | | | | | (domU1) | | | (domU2) | | | (dom2) |========|= USB Host #1 | | |______________| | |____________| | |_____________| | (for BT Dongle) | | / | / | / | ( and cradle ) | | / | / _______________ | / | | |/ |/ | Mail Server | |/ | | | | | (domU3) | | | | | | |_____________| | | | | | / | | | | | / | | | | |/ | | | xen-br0 br1 br1 | | | ! ! | | | _____________________________________________________________ | | \ | | | Local eth0 =|============+| dom0 | | |_____________|___________________________________________________________|_______| However, as the bandwidth throughput issue would still remain for all the other domains, I''m not sure if there''s a real benefit. I have a burner in this machine, with the hopes of using it for domain filesystem backups in the future. Can I assume that this performance would be improved dramatically using a MP machine (or HT) ? Are there other ways of improving this performance? Appreciate your advice. Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> This setup works extremely well for my purposes. > I have, however, noticed network performance issues when scp''ing from dom0 > to a client in the local ''Green Zone''. > Rather than the 4MB/s I''d expect (PIIX4 ata33 IDE with software raid), I''m > only getting 1.4MB/s :( (screen shots here: > http://marcusbrutus.cust.internode.on.net/Computers/C3-1 )Oh dear! What CPU setup do you have here?> I appreciate there''s a lot more calculation going on, but still ...Context switches are likely to be the killer when using driver domains. Tell me: do you have any numbers for a domU to "real world" setup with a "vanilla" Xen config? How did that perform? Cheers, Mark> >Mike Tierney schrieb: > >>>> But it is still tempting to just do away with the seperate firewall vm > >>>> and > >>>> do all the firewalling in Dom0! > > With this in mind, I might be prepared to change my setup to something like > this: > > OPTION C-v3.2 > ============> Internet > > eth1 > > ________________________________________|__________________________________ >________ > > | > | ________________________________|___________________________ > |_______ | > | > | | Firewall > | | | | (dom1) > | | |=======|= eth2 DMZ > | | ____________________________________________________ > | |_____________| | (optional) > | > | eth3 eth4 eth5 > | | > | > | | ________________ | ______________ | > | | _______________ | > | | > | | | Proxy Server | | | Web Server | | | > | | | iPaq Server | | (domU1) | | | > | | | (domU2) | | | (dom2) |========|> | | | USB Host #1 ______________| | > | | | |____________| | |_____________| | > | | | (for BT Dongle) > | | > | | / | / | / > | | | ( and cradle ) / > | | | / _______________ | / > | | | / |/ | Mail Server | > | | |/ | > | | > | | | | (domU3) | | > | | | | | > | | | | _____________| | > | | | | | > | | | > | | | / | > | | | | / > | | | | > | | | | / > | | | | > | | | | > | > | xen-br0 br1 br1 > | | > | > | | ! ! > | | | > | | _________________________________________________ > | |____________ | > | > | \ | > | | | > > Local eth0 =|============+| dom0 > | | > > |_____________|_______________________________________________ > |____________|_______| > > However, as the bandwidth throughput issue would still remain for all the > other domains, I''m not sure if there''s a real benefit. > I have a burner in this machine, with the hopes of using it for domain > filesystem backups in the future. > > Can I assume that this performance would be improved dramatically using a > MP machine (or HT) ? > > Are there other ways of improving this performance? > > Appreciate your advice. > > Marcus. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users