[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.