Adding a physical device in a virtual design?

[DAVIDsTEA_Inc]

Hi Guys,

I'm having an issue figuring out how to plug a physical device in a virtual design.  I'm trying to plug a webfilter inline between my switch and firewall so it can filter traffic transparently.  The problem is that my firewall is virtual running on a vmware infrastructure with multiple hosts so I can't simply put it in between.  Here is an example of my physical/virtual design:

http://i.imgur.com/4rFQj7E.jpg

I was thinking about creating an untagged port on my VLAN 666 and assigning the VLAN 666 IP to another port and plugging the webfilter in between but I don't think the traffic would actually flow though the cable.

Anyone have an idea?

Thanks.

[Francesco Molino]

Hi

Why do you want it to be plugged inline between switch and firewall and not between switch and your wan router for example?

I'm not a VMware expert, but based on your drawing, there are multiple links going up to your server infrastructure and I don't see the best way to do it. I will let people more expert than me on vmware answering that question.

Other question. Which webfilter do you want to add? Is it wccp capable? If yes, depending on your switch model, you can force some types of traffic to go through this webfilter 1st.

[DAVIDsTEA_Inc]

Between the switch and WAN isn't recommended by Barracuda.

I can't use WCCP as my switch doesn't support it or else that would have been the best option.

[Francesco Molino]

ok. How does the ports works in your appliance? Are they working like a switch?

In any case,If you trunk vlan 666 on your Barracuda and the 2 port is going to ESXi and represent the vlan 666 vswitch, you will have only 1 link where today you have 2 links. You are loosing the redundancy.

[DAVIDsTEA_Inc]

The ports can work like a switch or else as a transparent inline device.  We were thinking of assigning our core switch vlan 666 IP to the barracuda which would make it the router for traffic to the firewall but then we'll have a single point of failure.  The inline on the barracuda, even if the device fails, the traffic keeps flowing through it so that is our best option, plus it leaves the configuration very simple without having to do any routing.

[Francesco Molino]

Yes the routing stuff was what I was thinking. As you said you have a SPOF even in L3 and/or L2.

Th advantage of L2 is if the appliance goes down you'll just loose web filtering. In Layer3, you'll loose everything.

The only way I see is that I told you before by trunking vlan 666 but you have a SPOF and if you create an another link with vlan 666 straight forward the DC in parallel, you'll need to play with STP in order to make 1 primary and the other link secondary.

[DAVIDsTEA_Inc]

What about doing something like...

• Removing the VLAN 666 IP from my switch
• Create a switch port with untagged VLAN 666 and connect it to the Webfilter
• Create another routing switch port with the previous IP of VLAN 666 (192.168.253.2) and plug it to the Webfilter

Would that somehow pass all VLAN 666 traffic through the two connections I made?  Or would the switch just see that the IP on the port is local and go straight to it instead of through the connection?

User WAN request -> Hits the core switch -> sees the 0.0.0.0 route -> passes the traffic to 192.168.253.2 -> passes through the webfilter in getting to firewall

Not sure if that makes sense.

[Francesco Molino]

This is what I was talking about concerning L3 solution. You may need creating a new VLAN to route everything on the web filter and the other web filter port should be on the same vlan 666 in order to route everything back to the firewall. However in case of appliance break, all users can't go to the firewall and internet.

With Layer 2 solution, you should have an alternative with a redundant path.

Let me drop you a sketch in 2 minutes.

I think you can do redundant link for ESX vswitch.

[Paul Chapman]

Hi -

There's a very easy way to do this.  Attach the Barracuda to the switch on 2 different VLANs.  For argument's sake 665 & 666.  Then place the firewall on VLAN 665 (easy because VLAN tagging is offloaded to VMware and the firewall is unaware of it).  This will create an intentional VLAN bridge which forces traffic over the Barracuda.  Topology wise you look like this:

Switch SVI 666 (vlan 666) <-> [inside] Barracuda [outside] <-> [trunk] VMware <-> VLAN 665 vSwitch portgroup <-> Firewall

In this setup it won't matter how many interfaces VMware is using because it will accept the 665 VLAN tag from the upstream network and forward the data to the correct port group.

Switch config looks like:

vlan 666
 name FW-Inside
vlan 665
 name BC-Inside
int vlan 666
 desc To FW Inside via Barracuda
 ip address 192.168.253.2 255.255.255.0
int gi1/21
 desc Barracuda Inside
 switch mode access
 switch access vlan 666
 spanning bpdufilter enable
int gi1/22
 desc Barracuda Outside
 switch mode access
 switch access vlan 665
 spanning bpdufilter enable
int range gi1/3 - 4
 desc ESXi Host
 switch mode trunk
 spanning portfast trunk

HTH

PSC

[Francesco Molino]

Hi,

Sorry, just a question, because I'm not sure I get your point.

All users SVI are coming to the switch. The default route is passing traffic trough the firewall in vlan 666. In your config, you have a SVI in vl666 on the switch. How the traffic will passthrough the barracuda with vlan 665?

I maybe missed something.

[Paul Chapman]

Hi -

Let's consider ARP for a second.  If the SVI is looking for the FW's MAC address it will send a broadcast on VLAN 666.  The Barracuda (acting as a transparent device) never sees VLAN tags since it is connected to access ports, so it simply forwards the broadcast from its port on 666 to its port on 665.  The switch see's a broadcast coming in on the Barracuda port on 665 and floods the frame to all ports on the VLAN (except the port it came in on).  VMware being attached to the switch via a trunk forwards the broadcast to the appropriate vSwitch.  The same happens for the reverse traffic.

From a L2 point of view I can have the same MAC address in multiple VLANs with no issue since the devices aren't conflicting with each other.

We run into one minor problem with this configuration, and that's STP BPDUs.  The switch will detect mismatching VLANs, so we need to suppress BPDUs on these ports.

PSC

[Francesco Molino]

Sorry, on network side this is ok for me. What I don't understand is on VMware side. I've maybe not asked correctly the question.

The vmware server are connected to barracuda outside vlan (665). The vswitch on ESX is looking for the vlan 666 tag, isn't it? How it will communicate?

Maybe this a stupid question but as I said ESX is not part of my skills.

[Paul Chapman]

Sorry... I thought that was clear.  You do 1 of 2 things. 1) Change the VLAN tag on the VMware Port Group attached to the inside interface of the FW, or 2) (if the Port Group is used by other devices also) create a new Port Group that uses 665 as it's tag, then change the network that the VM is attached to.

PSC

[Francesco Molino]

Ok I got it. Then you have to change firewall ip to be on vlan 665 as the vswitch tag will be changed?

[Paul Chapman]

Not at all. FW IP never changes. There's no inter-vlan routing because we have merged VLANs 665 and 666 into a single broadcast domain over the Barracuda.

PSC