RE: Bridging firewall?

RE: Bridging firewall?

[Ian Pratt]

 > In order to feel secure i've activated the antispoof options, 
> but as it was
> broken for me i tweak a little the rules ... if someone is 
> intrested i can post
> my script and give some explanations.

That would be useful.

Thanks,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Matthieu PATOU]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Sun, 23 Jan 2005 23:15:29 -0000
"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:

>  > In order to feel secure i've activated the antispoof options, 
> > but as it was
> > broken for me i tweak a little the rules ... if someone is 
> > intrested i can post
> > my script and give some explanations.
> 
> That would be useful.
> 
See the attached files, in order to work i put some rules :
vifx.0 must be bridged to xen-br0 (it correspond to the output of the firewall)
in order to be really accessible (some iptables rules are juste added line 79
and 80 for vifx.0 and not for other vif).
 

[-- Attachment #2: network --]
[-- Type: application/octet-stream, Size: 5568 bytes --]

#!/bin/sh
#============================================================================
# Default Xen network start/stop script.
# Xend calls a network script when it starts.
# The script name to use is defined in /etc/xen/xend-config.sxp
# in the network-script field.
#
# This script creates a bridge (default xen-br0), adds a device
# (default eth0) to it, copies the IP addresses from the device
# to the bridge and adjusts the routes accordingly.
#
# If all goes well, this should ensure that networking stays up.
# However, some configurations are upset by this, especially
# NFS roots. If the bridged setup does not meet your needs,
# configure a different script, for example using routing instead.
#
# Usage:
#
# network (start|stop|status) {VAR=VAL}*
#
# Vars:
#
# bridge     The bridge to use (default xen-br0).
# netdev     The interface to add to the bridge (default eth0).
# antispoof  Whether to use iptables to prevent spoofing (default yes).
#
# start:
# Creates the bridge and enslaves netdev to it.
# Copies the IP addresses from netdev to the bridge.
# Deletes the routes to netdev and adds them on bridge.
#
# stop:
# Removes netdev from the bridge.
# Deletes the routes to bridge and adds them to netdev.
#
# status:
# Print ifconfig for netdev and bridge.
# Print routes.
#
#============================================================================

# Exit if anything goes wrong.
set -e 

# First arg is the operation.
OP=$1
shift

# Pull variables in args in to environment.
for arg ; do export "${arg}" ; done

bridge=${bridge:-xen-br0}
netdev=${netdev:-eth0}
antispoof=${antispoof:-yes}
bridge1=${bridge1:-xen-br1}
netdev1=${netdev1:-eth1}
antispoof1=${antispoof1:-yes}

echo "network $OP bridge=$bridge netdev=$netdev antispoof=$antispoof"

# Usage: transfer_addrs src dst
# Copy all IP addresses (including aliases) from device $src to device $dst.
transfer_addrs () {
    local src=$1
    local dst=$2
    # Don't bother if $dst already has IP addresses.
    if ip addr show dev ${dst} | egrep -q '^ *inet' ; then
        return
    fi
    # Address lines start with 'inet' and have the device in them.
    # Replace 'inet' with 'ip addr add' and change the device name $src
    # to 'dev $src'. Remove netmask as we'll add routes later.
    ip addr show dev ${src} | egrep '^ *inet' | sed -e "
s/inet/ip addr add/
s@\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\)/[0-9]\+@\1@
s/${src}/dev ${dst}/
" | sh -e
}

# Usage: transfer_routes src dst
# Get all IP routes to device $src, delete them, and
# add the same routes to device $dst.
# The original routes have to be deleted, otherwise adding them
# for $dst fails (duplicate routes).
transfer_routes () {
    local src=$1
    local dst=$2
    # List all routes and grep the ones with $src in.
    # Stick 'ip route del' on the front to delete.
    # Change $src to $dst and use 'ip route add' to add.
    ip route list | grep ${src} | sed -e "
h
s/^/ip route del /
P
g
s/${src}/${dst}/
s/^/ip route add /
P
d
" | sh -e
}

# Usage: create_bridge dev bridge
# Create bridge $bridge and add device $dev to it.
create_bridge () {
    local dev=$1
    local bridge=$2

    # Don't create the bridge if it already exists.
    if ! brctl show | grep -q ${bridge} ; then
        brctl addbr ${bridge}
        brctl stp ${bridge} off
        brctl setfd ${bridge} 0
    fi
    ifconfig ${bridge} up
}

# Usage: antispoofing dev bridge
# Set the default forwarding policy for $dev to drop.
# Allow forwarding to the bridge.
antispoofing () {
    local dev=$1
    local bridge=$2

    iptables -P FORWARD DROP
    iptables -A FORWARD -m physdev --physdev-in ${dev} -j ACCEPT
    iptables -A FORWARD -m physdev --physdev-out ${dev} -j ACCEPT
}

# Usage: show_status dev bridge
# Print ifconfig and routes.
show_status () {
    local dev=$1
    local bridge=$2
    
    echo '============================================================'
    ifconfig ${dev}
    ifconfig ${bridge}
    echo ' '
    ip route list
    echo ' '
    route -n
    echo '============================================================'
}

case ${OP} in
    start)
        # Create the bridge and give it the interface IP addresses.
        # Move the interface routes onto the bridge.
        create_bridge ${netdev} ${bridge}
        transfer_addrs ${netdev} ${bridge}
        transfer_routes ${netdev} ${bridge}
        create_bridge ${netdev1} ${bridge1}
        transfer_addrs ${netdev1} ${bridge1}
        transfer_routes ${netdev1} ${bridge1}
	# Don't add $dev to $bridge if it's already on a bridge.
	if ! brctl show | grep -q ${netdev} ; then
	    brctl addif ${bridge} ${netdev}
	fi
	if ! brctl show | grep -q ${netdev1} ; then
	    brctl addif ${bridge1} ${netdev1}
	fi
        
        if [ ${antispoof} == 'yes' ] ; then
            antispoofing ${netdev} ${bridge}
        fi
        if [ ${antispoof1} == 'yes' ] ; then
            antispoofing ${netdev1} ${bridge1}
        fi
       	ifconfig eth1 up 
        ;;
    
    stop)
    	ifconfig eth1 down
        # Remove the interface from the bridge.
        # Move the routes back to the interface.
        brctl delif ${bridge} ${netdev}
        transfer_routes ${bridge} ${netdev}
        brctl delif ${bridge1} ${netdev1}
        transfer_routes ${bridge1} ${netdev1}

        # It's not our place to be enabling forwarding...
        ;;

    status)
        show_status ${netdev} ${bridge}
        show_status ${netdev1} ${bridge1}
       ;;

    *)
       echo 'Unknown command: ' ${OP}
       echo 'Valid commands are: start, stop, status'
       exit 1
esac

[-- Attachment #3: vif-bridge --]
[-- Type: application/octet-stream, Size: 2352 bytes --]

#!/bin/sh
#============================================================================
# /etc/xen/vif-bridge
#
# Script for configuring a vif in bridged mode.
# Xend calls a vif script when bringing a vif up or down.
# This script is the default - but it can be configured for each vif.
#
# Example invocation:
#
# vif-bridge up domain=VM1 vif=vif1.0 bridge=xen-br0 ip="128.232.38.45/28 10.10.10.55/24"
#
#
# Usage:
# vif-bridge (up|down) {VAR=VAL}*
#
# Vars:
#
# domain  name of the domain the interface is on (required).
# vif     vif interface name (required).
# mac     vif MAC address (required).
# bridge  bridge to add the vif to (required).
# ip      list of IP networks for the vif, space-separated (optional).
#
# up:
# Enslaves the vif interface to the bridge and adds iptables rules
# for its ip addresses (if any).
#
# down:
# Removes the vif interface from the bridge and removes the iptables
# rules for its ip addresses (if any).
#============================================================================

# Exit if anything goes wrong
set -e 

echo "vif-bridge $*"

# Operation name.
OP=$1
shift

# Pull variables in args into environment
for arg ; do export "${arg}" ; done

# Required parameters. Fail if not set.
domain=${domain:?}
vif=${vif:?}
mac=${mac:?}
bridge=${bridge:?}

# Optional parameters. Set defaults.
ip=${ip:-''}   # default to null (do nothing)

# Are we going up or down?
case $OP in
    up)
        brcmd='addif'
        iptcmd='-A'
        ;;
    down)
        brcmd='delif'
        iptcmd='-D'
        ;;
    *)
        echo 'Invalid command: ' $OP
        echo 'Valid commands are: up, down'
        exit 1
        ;;
esac

# Don't do anything if the bridge is "null".
if [ "${bridge}" == "null" ] ; then
    exit
fi

# Add/remove vif to/from bridge.
brctl ${brcmd} ${bridge} ${vif}
[ ${vif#vif*.} == "0" ]&&iptables $iptcmd FORWARD -i $vif -j ACCEPT
[ ${vif#vif*.} == "0" ]&&iptables $iptcmd FORWARD -o $vif -j ACCEPT
if [ ${ip} ] ; then

    # If we've been given a list of IP networks, allow pkts with these src addrs.
    for addr in ${ip} ; do
        iptables ${iptcmd} FORWARD -m physdev --physdev-in ${vif} -s ${addr} -j ACCEPT
    done 

    # Always allow us to talk to a DHCP server anyhow.
    iptables ${iptcmd} FORWARD -m physdev --physdev-in ${vif} -p udp --sport 68 --dport 67 -j ACCEPT
fi

Re: Bridging firewall?

[Matthieu PATOU]

> 
> Are you sure your new scripts actually still implement the antispoof
> feature of ensuring that the guest can only send packets using its
> allocated IP? It looks to me like they're too lax.
The modification into /etc/xen/scripts/network and /etc/xen/script/vif-bridge
are just to have a functionnal antispoof when you have two bridge
but all the firewalling is done into xenU-firewall a domain connected with
vif1.0 connected to xen-br0 (the secure network) and vif1.1 connected to xen-br1
(the outside )

Is it more clear ?
i don't think that my modification the scripts are that clever ... my 2 cent
files !
> 
> Ian
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: Bridging firewall?

[Ian Pratt]

Are you sure your new scripts actually still implement the antispoof
feature of ensuring that the guest can only send packets using its
allocated IP? It looks to me like they're too lax.

Ian

> -----Original Message-----
> From: Matthieu PATOU [mailto:matxen@matws.net] 
> Sent: 26 January 2005 21:12
> To: Ian Pratt
> Cc: xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Bridging firewall?
> 
> On Sun, 23 Jan 2005 23:15:29 -0000
> "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> >  > In order to feel secure i've activated the antispoof options, 
> > > but as it was
> > > broken for me i tweak a little the rules ... if someone is 
> > > intrested i can post
> > > my script and give some explanations.
> > 
> > That would be useful.
> > 
> See the attached files, in order to work i put some rules :
> vifx.0 must be bridged to xen-br0 (it correspond to the 
> output of the firewall)
> in order to be really accessible (some iptables rules are 
> juste added line 79
> and 80 for vifx.0 and not for other vif).
>  
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Nicholas Lee]

On Tue, Jan 25, 2005 at 06:27:09PM +0100, Matthieu wrote:
> > So in a sense you've put your virtual servers on the same network as
> > some of your internal machines.
> >
> Yes, that's right but is it a problem ? 

No, only if you don't have a physical internal network. Like a machine
in a colo.


> Quite complicated ? it seems that you 're relying on the fact your inbound
> traffic will go to the eth0 trought you're firewall (trough dom1 in fact).
> I'm quite afraid about the fact that some packet cleverly forged can go
> trough dom0 without going trough dom1.

Relying on the way briding works. The internal hosts are on a seperate
bridge from the the external dom0. The domU1 bridge will need to be
tranversed for traffice to go from the external bridge to the internal
bridge.

If it doesn't work like that, then bridging is broken. Think of each
bridge as a switch, with domU1 being a smart switch. Connecting a host
to each switch by adding one of its interfaces to the bridge is like
joining two switch by a crossover cable. If there is no direct cable
between the external and internal bridges, but they have to instead
tranverse the bridging firewall switch then everything is as it should
be.


Nicholas


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Matthieu]

>
> For the comments below I assume you are using Linux as your firewall OS.
>
That's right ...
> >  Not sure see my setup:
> >  i've two cards in dom0 :eth0 and eth1, eth1 is linked to my xdsl
> >  modem, eth0 to a switch for other physical machines, eth0 is also
> >  shared with other xenU domains (thoses who are consciderated to be
> >  after the firewall). br0 encapsulate eth0, one of the virtual network
> >  card of my firewall (the one consciderated filtred) and other xenU
> >  virtual network card br1 encapsulate eth1 and the other virtual
> network card
> So in a sense you've put your virtual servers on the same network as
> some of your internal machines.
>
Yes, that's right but is it a problem ? 
>From a simple user point of view the virtual server which are after the
firewall should  another server.


> >  My basic idea was not to configure eth1 at all, i thought that if the
> >  interface is not activated there is no chance of attacking xen0.
> >  It tunrns that in order to have the packet directed to
> >  xenFirewall-input, i must do if config eth1 up.
>
> I've been thinking that the following similar method is possible, without
> resorting to giving physical device access to a domU.
>
> Basically the same as above, except I'll just have a virtual eth1.
>
> Put dom0 and a virtual NIC for the firewall (domU1-eth0 say) on br0/eth0.
> Put domU1-veth1, and all the other domUs on br, and all the other domUs
> on br1. Then setup domU1 as a bridging firewall. Admin domU1, either via
> the console from dom0 or setup a third private internal accessible from
> dom0 or a management VPN.
>
>
Quite complicated ? it seems that you 're relying on the fact your inbound
traffic will go to the eth0 trought you're firewall (trough dom1 in fact).

I'm quite afraid about the fact that some packet cleverly forged can go
trough dom0 without going trough dom1.


>
> So there are three bridges. Not sure how well it would perform, or
> whether the net/freebsd virtual NIC drives can hande this scenario. It
> seems workable though.
> Pf+altq, are by far much nicer than iptables.
Not an expert in freebsd, better be sure than experimenting when talking
about security.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Nicholas Lee]

On Mon, Jan 24, 2005 at 12:12:00AM +0100, Matthieu PATOU wrote:
> On Fri, 21 Jan 2005 13:55:35 +0000
> Grzegorz Milos <gm281@hermes.cam.ac.uk> wrote:
> 
> > > Is it possible with Xen to construct something like the following scenario.
> > >
> > > Free/NetBSD (*) domU server running pf or Linux/iptables, acting as a
> > > routing or bridging firewall for all the other domU guests? Further more
> > > create virtual DMZ and internal services.
> I've done it and it's running since two or three month at home and it seems to
> work ...

For the comments below I assume you are using Linux as your firewall OS.

> Not sure see my setup:
> i've two cards in dom0 :eth0 and eth1, eth1 is linked to my xdsl modem, eth0 to
> a switch for other physical machines, eth0 is also shared with other xenU
> domains (thoses who are consciderated to be after the firewall).
> br0 encapsulate eth0, one of the virtual network card of my firewall (the one
> consciderated filtred) and other xenU virtual network card
> br1 encapsulate eth1 and the other virtual network card 

So in a sense you've put your virtual servers on the same network as
some of your internal machines.


> My basic idea was not to configure eth1 at all, i thought that if the interface
> is not activated there is no chance of attacking xen0.
> It tunrns that in order to have the packet directed to xenFirewall-input, i must
> do if config eth1 up.

I've been thinking that the following similar method is possible, without
resorting to giving physical device access to a domU.

Basically the same as above, except I'll just have a virtual eth1.

Put dom0 and a virtual NIC for the firewall (domU1-eth0 say) on br0/eth0.
Put domU1-veth1, and all the other domUs on br, and all the other domUs
on br1. Then setup domU1 as a bridging firewall. Admin domU1, either via
the console from dom0 or setup a third private internal accessible from
dom0 or a management VPN.



So there are three bridges. Not sure how well it would perform, or
whether the net/freebsd virtual NIC drives can hande this scenario. It
seems workable though.


Pf+altq, are by far much nicer than iptables.


Nicholas


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Matthieu PATOU]

On Fri, 21 Jan 2005 13:55:35 +0000
Grzegorz Milos <gm281@hermes.cam.ac.uk> wrote:

> > Is it possible with Xen to construct something like the following scenario.
> >
> > Free/NetBSD (*) domU server running pf or Linux/iptables, acting as a
> > routing or bridging firewall for all the other domU guests? Further more
> > create virtual DMZ and internal services.
I've done it and it's running since two or three month at home and it seems to
work ...
> >
> > You'd probably keep the dom0 instance otherside this setup, with its own
> > filtering arrangement.
> >
> 
> If you give direct network device access to first domU you can set-up your 
> scheme fairly easily. Otherwise (in the standard setup) dom0 will be handling 
> all the incomming/outgoing traffic with no involvment from first domU (so no 
> firewall possible there). 
Not sure see my setup:
i've two cards in dom0 :eth0 and eth1, eth1 is linked to my xdsl modem, eth0 to
a switch for other physical machines, eth0 is also shared with other xenU
domains (thoses who are consciderated to be after the firewall).
br0 encapsulate eth0, one of the virtual network card of my firewall (the one
consciderated filtred) and other xenU virtual network card
br1 encapsulate eth1 and the other virtual network card 

My basic idea was not to configure eth1 at all, i thought that if the interface
is not activated there is no chance of attacking xen0.
It tunrns that in order to have the packet directed to xenFirewall-input, i must
do if config eth1 up.
By doing this way, i must say that i feel less confortable but i still have
faith (and some iptables rules in dom0).
In order to feel secure i've activated the antispoof options, but as it was
broken for me i tweak a little the rules ... if someone is intrested i can post
my script and give some explanations.

I must say that i'm planning to switch to a solution where my eth1 is directly
exported in xenFirewall.

> 
> Cheers
> Gregor
> 
> > For instance, you have a subnet 192.168.1.0/24.  Put the dom0 on
> > 192.168.1.254. Have the firewall router domU running on 192.168.1.1 and
> > acting as the gateway for all the other machines on the subnet.
> >
> >
> > (*) This is my dream, using pf for security and debian for serving the
> > applications. ;)

HTH


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Georgios Portokalidis]

You might also want to checkout ebtables (http://ebtables.sourceorge.net)


On Fri, 21 Jan 2005 16:08:00 +0100, Jan Kundrát <jan.kundrat@fzu.cz> wrote:
> Jan Kundrát wrote:
> > phisical
> 
> oops :-), forgive me, but it's friday afternoon :-)
> 
> -jkt
> 
> --
> cd /local/pub && more beer > /dev/mouth
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Jan Kundrát]

Jan Kundrát wrote:
> phisical

oops :-), forgive me, but it's friday afternoon :-)

-jkt


-- 
cd /local/pub && more beer > /dev/mouth



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Jan Kundrát]

Felipe Alfaro Solana wrote:
> How? I thought all network traffic must pass through domain0 in first 
> instance. How do you give a domainU instance direct access to a network 
> interface, like eth1? I'm currently using a bridge, xen-br0, attached to 
> eth1, and domainU attached to xen-br0. How can I configure domainU to 
> attach to eth1 directly?

You have to give domU permission to access your phisical NIC device. 
It's described somewhere in the manual, iirc.

-jkt

-- 
cd /local/pub && more beer > /dev/mouth



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Felipe Alfaro Solana]

On 21 Jan 2005, at 14:55, Grzegorz Milos wrote:

>> Is it possible with Xen to construct something like the following 
>> scenario.
>>
>> Free/NetBSD (*) domU server running pf or Linux/iptables, acting as a
>> routing or bridging firewall for all the other domU guests? Further 
>> more
>> create virtual DMZ and internal services.
>>
>> You'd probably keep the dom0 instance otherside this setup, with its 
>> own
>> filtering arrangement.
>>
>
> If you give direct network device access to first domU you can set-up 
> your
> scheme fairly easily. Otherwise (in the standard setup) dom0 will be 
> handling
> all the incomming/outgoing traffic with no involvment from first domU 
> (so no
> firewall possible there).

How? I thought all network traffic must pass through domain0 in first 
instance. How do you give a domainU instance direct access to a network 
interface, like eth1? I'm currently using a bridge, xen-br0, attached 
to eth1, and domainU attached to xen-br0. How can I configure domainU 
to attach to eth1 directly?



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Bridging firewall?

[Grzegorz Milos]

> Is it possible with Xen to construct something like the following scenario.
>
> Free/NetBSD (*) domU server running pf or Linux/iptables, acting as a
> routing or bridging firewall for all the other domU guests? Further more
> create virtual DMZ and internal services.
>
> You'd probably keep the dom0 instance otherside this setup, with its own
> filtering arrangement.
>

If you give direct network device access to first domU you can set-up your 
scheme fairly easily. Otherwise (in the standard setup) dom0 will be handling 
all the incomming/outgoing traffic with no involvment from first domU (so no 
firewall possible there). 

Cheers
Gregor

> For instance, you have a subnet 192.168.1.0/24.  Put the dom0 on
> 192.168.1.254. Have the firewall router domU running on 192.168.1.1 and
> acting as the gateway for all the other machines on the subnet.
>
>
> (*) This is my dream, using pf for security and debian for serving the
> applications. ;)
>
> Nicholas
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-- 
Quidquid latine dictum sit, altum viditur --- Anon


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Bridging firewall?

[Nicholas Lee]

Is it possible with Xen to construct something like the following scenario.

Free/NetBSD (*) domU server running pf or Linux/iptables, acting as a
routing or bridging firewall for all the other domU guests? Further more
create virtual DMZ and internal services.

You'd probably keep the dom0 instance otherside this setup, with its own
filtering arrangement.


For instance, you have a subnet 192.168.1.0/24.  Put the dom0 on 192.168.1.254.
Have the firewall router domU running on 192.168.1.1 and acting as the
gateway for all the other machines on the subnet.


(*) This is my dream, using pf for security and debian for serving the
applications. ;)

Nicholas


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl