[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-users] Managed Firewall
- To: "Simon Hobson" <simon@xxxxxxxxxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
- From: "Jonathan Tripathy" <jonnyt@xxxxxxxxxxx>
- Date: Wed, 16 Jun 2010 15:15:21 +0100
- Cc:
- Delivery-date: Wed, 16 Jun 2010 07:32:55 -0700
- List-id: Xen user discussion <xen-users.lists.xensource.com>
- Thread-index: AcsNXjU4BfZ8JsOWSX2XyKd+20w12wAACX3J
- Thread-topic: [Xen-users] Managed Firewall
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx on
behalf of Simon Hobson Sent: Tue 15/06/2010 17:14 To:
xen-users@xxxxxxxxxxxxxxxxxxx Subject: RE: [Xen-users] Managed
Firewall
Dustin Henning wrote:
>> >I also have
another idea, so maybe you could tell me if it would >> >work
or not (Using physical firewall box): >> >Let's say I have
just one bridge per Xen host. Could I use >>
>iptabled/ebtables to deny all inter-VM traffic? So only allow
access >> >from the VM to the physical NIC of the box? Then on
the physical >> >switch, I could put each port on a separate
VLAN, but put the port >> >that the firewall is connected to
on all the VLANs. Then, I assume, >> >the switch would send
all traffic from the host ports to the >> >firewall port,
where the firewall could do filtering? I'm not sure >> >if the
firewall would even need to be VM aware.. >> >>Well the
firewall will not have to be VM aware anyway - it just sees >>traffic
on VLAN ports. >> >>As to having one bridge and VLANs, if you
connect multiple VLANs to >>one switch then that's the equivalent of
trunking (bonding) multiple >>links together and won't help. The
only other way round it I can see >>is to use some fudging with /32
subnets for the clients so that they >>have no concept of there being
'neighbours' on the local subnet (and >>then enforce it with
iptable/ebtables rules to prevent direct >>host-host traffic) - but
that's beyond my experience and I don't know >>how well it works or
what pitfalls there may be.
>Simon, >Primarily out of curiosity,
are you assuming that the switch is not using >VLAN tagging along with
trunking? Is that even possible? Assuming tagged >VLANs, I
don't see what makes you think the switch is going to break that >boundary
and send the data back. Even if it did, the destination domU >should
ignore it unless the tag was stripped by the switch. Seems to
me >like the switch would keep the VLANs separate and e firewall would
have to >function as a sort of "VLAN Router," which may or may not be
possible. >Dustin
Well actually I'm not sure I fully understand the
setup proposed - but I think it involved building a bridge per guest, a VLAN
per bridge, and trunking the lot back to the firewall via a switch.
At
some point, all these VLAns are going to have to be switched together -
unless you futz about with /32 subnets on the clients. Once you do that, the
switches will switch the packets back in the shortest manner available - and
that is unlikely to be via the firewall unless that is doing all the
switching.
It could work if the firewall supports that many interfaces,
and you trunk all the VLANs back to it. Then you could setup intra-zone
rules to control traffic between the VLANs, and hence between the
guests.
I see no reason why a switch shouldn't support tagged packets
over a bonded trunk. It's just a case of whether you can actually
get anything useful from doing so.
-- Simon
Hobson ----------------------------------------------------------------------------------
Hi Simon,
You are correct in what you have said, and that is the same
conclusion I came to.
This is why I've chosen to do a simplier solution: Just use
iptables in each Dom0 to firewall customer VMs. All I have to do is write my own
vif scripts to make it easy to configure, which shoudn't be too hard. So if a
customer wants a port blocked/opened, all I have to do is change vif script,
then restart VM.
What you think?
Thanks
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|