VLAN's, Tigers, and Bears. Oh my

[mystereman]

I have a client that's been using esx for about a year. They offer virtual machines to their clients running a custom configured software package. Up until now, they've had all the machines running in one subnet on a Windows 2003 domain. They've been having a number of problems with interactions of the software and security between clients, so we've come up with a possible solution that i'd like to run past some of the experts here.

Essentially, what we want to do is isolate each of the clients onto their own subnet. This involves each client having it's own VM that they remote desktop into, as well as their own database server. We don't want the clients to be able to communicate with each other directly, but we want them all to share the same Active Directory Domain, so that we don't have to make create AD domains in each subnet. Further, each of the clients need to both allow external (firewalled) access into the machines, as well as potential outbound traffic (load balanced on 2 WAN connections). In addition to all that, the maintenance staff have to get to those subnets from their desktops within the organization.

So here's my thought. I create a virtual switch without any physical adapters connected. I then partition that up into multiple portgroups for each subnet. Then, I create a vm running Linux that acts as a router/firewall. I attach the router to all those portgroups somehow and route data to the appropriate places (internet, ActiveDirectory subnet, internal to subnets, etc..) I create various firewall rules to prevent the subnets from talking to each other, but allow the various other rules i've defined above.

This sounds good, except for the fact that you can only add 4 virtual nic's to any given virtual machine. The router would need a minimum of about 10 with a maximum of about 30 possible NIC's in this approach.

So my thought is that I can have the Linux router use VLAN trunking to allow it handle all the VLAN's with only one virtual NIC. But, the individual portgroups for the subnets would have to use filter the VLAN tagging so that the machines in the portroup don't have to deal with that (VST?), thus we have a trunk between the portgroups in the virtual switch and router. The router then has two non-vlan'd physical nic's that go out to the WAN's, and an additional 2 other physical NIC's for internal use (one is a trusted LAN, the other a DMZ for external (non-vm) servers, including the Domain Controllers and DNS) that also shouldn't have any VLAN tagging. Essentially, all VLAN management occurs within the ESX server, so I don't need any managed switches either.

So my question is, am I making this too complicated? Does this seem right? Is this going to be impossible to do? Thoughts, comments, criticisms?

Thanks.

[Texiwill]

Hello,

So your network would look something like this:

AD<->vSwitch<->VGT Router<->vSwitch<->PG1   <-> Client 1 VMs
                                                                PG2
                                                                 ...
                                                                PGx

Each vSwitch would then have a pNIC so you can still vMotion. Is this a correct depiction?

A couple of issues, VGT going into the router via the pNIC is doable, that works, VGT going out the router to the other vSwitch... THat may not be doable.... I have yet to see anything like that work. And since one you start using portgroups you have to continue using portgroups, the second vSwitch would have issues. Why is AD even needed? Is it for DHCP, Users, DNS, etc? There are some better ways to get this that would allow for security and keeping everyone's VMs private.... If it was me, I would use the following pretty much ignoring VLANs entirely and make use of virtual firewalls.

pNIC <-> vSwitch <-> AD
                          <-> vFW1 <-> Company1 vSwitch <-> Company 1 VMs
                          <-> vFW2 <-> Company2 vSwitch <-> Company 2 VMs
                          ...
                          <-> vFWx <-> Company X vSwitch <-> Comapany X VMs

This has several very nice features. Each vFW is a packet filtering firewall perhaps using SmoothWall Express 3.0. Which is a DHCP server, as well as a forwarding DNS server...

• You direct the DNS to AD, leave DHCP alone.

• You also redirect all user authentication AD traffic back to the AD server and no where else.

• You only need 1 real IP address per company, the DHCP network behind the scenes is a non-routable network.

• NAT is also in use + the strong firewall

• no need for a VGT Router

• AD traffic never leaves the first vSwitch

• Each Company can control their own firewall or you could control it. In this setup the default Smoothwall express is controllable from inside the Companies VMs.

Drawbacks:

• no vMotion without a pNIC attached to each Companies vSwitch.... However, instead you could setup load balancing across multiple hosts or even clusters....

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, (c) 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[mystereman]

Thank for the response, Ed. You're close, I think. but not quite. Let me make sure we're clear on your terms. When you say pNIC you mean physical NIC? and by vFW you mean a virtual machine running something like Linux with Smoothwall? The network would look something like this:

WAN <-> pNIC0 <- Untagged Traffic -> vSwitch0 <-> vRouter/FW

WAN <-> pNIC1 <- Untagged Traffic -> vSwitch0 <-> vR/FW

vR/FW <-VGT-> vSwitch1 <-VST-> PG0 <-UT-> pNIC2 <-> AD & other physical servers

vR/FW <-VGT-> vSwitch1 <-VST-> PG1 <-UT-> pNIC3 <-> Trusted LAN (physical workstations)

vR/FW <-VGT-> vSwitch1 <-VST-> PG2 <-UT-> Client 1 VM

vR/FW <-VGT-> vSwitch1 <-VST-> PG3 <-UT-> Client 2 VM

...

vR/FW <-VGT-> vSwitch1 <-VST-> PGx <-UT-> Client x VM

I'm a little cloudy about the areas with pNIC2 and 3. Basically, these 2 NIC's go otu to unmanaged switches, pNIC2 goes to the servers and pNIC3 goes to the internal LAN, however they connect to the vR/FW because that traffic has to be routed to the VM's and the WAN's. Also, i'm not sure if I have the VGT part right. You can create a Portgroup for VGT in addition to VST's on the same swtich, right? I have a total of 6 pNIC's in the VMWare server, 2 Integrated Broadcom's and a Quad port Intel.

Regarding your solution, I don't like having to have a seperate vFW for each client VM, that's a useless waste of resources in my opinion.

I require Active Directory because the client applications require AD. They use COM+ and communicate with a SQL Server database (not pictured in the diagram for simplicity, but each subnet has 2 VM's, 1 web server/Terminal Server and 1 SQL Server) using AD credentials. The clients don't want to manage a seperate domain for each client. I'd prefer to use DHCP/DNS/AD all one domain controller (plus a backup controller) just because in my opinion AD and DHCP are easier to manage together than trying ot make BIND work correctly in an AD environment. In fact, we probably won't even be using DHCP in the virtual machines since they're small enough and there won't be many new devices added. DHCP will be required for the trusted LAN though, and we may add a wireless VLAN and VPN VLAN later.

There is no need for the client to manage their own firewall. I don't need vMotion (at least not now, their current plan is to just throw bigger hardware at it as their needs grow, but there may come a time when they need more than one esx server, we'll cross that bridge when we get to it).

I hope this helps clarify. So what do you think?

[Texiwill]

Hello,

I see what you are trying to do, I assumed you also had more than 1 or so VM per client. But that does not appear to be the case. There used to be a problem where once you started using portgroups, you could not talk to the vSwitch anymore, I believe that has changed.... Your VGT vNIC (virtual NIC) will need to talk to the 'vSwitch' and not a port on the vSwitch. Then everything should work.... I would definitely test this out. Never tried it, I tend not to let VMs talk VGT for any reason.

I will run some tests on my own as well, this could have interesting security overtones..... I am not sure what a UT is in your diagram.... In essence you will have... I am just not sure that a VM can feed the trunk to the vSwitch, that is the one possible gotcha.

pSwitch<->pNIC<->vSwitch(VGT)<->vRouter/vFW<->vSwitch(VST)<->VMs

Where pNIC is pNIC0 and pNIC1, I assume you have separate pNICs for the SC, perhaps storage.... To enable vMotion, which for a hosted solution I would think is a must for the future attach a pNIC to the VST vSwitch that goes to a VLAN on the pSwitch that is only for that port.... All it needs is a link light I believe. I think this is a pretty complex setup... You will want to test fully.

I am writing a blog on various network setups, may I include this one in them?

When we host clients VMs we like to firewall each separately so that there is definitely no overlap and we using a Smoothwall Express appliance to ensure this and tie into our existing DNS. Each private network gets their own DHCP/Static IPs/Authentication methods.

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, (c) 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[mystereman]

Thanks Ed,

Sure, go ahead and use this configuration. If you'd like to communicate offline, we can do that and keep each other informed about the progress. I'd like the address of the blog as well

The only reason I plan on using VGT is because of the limitation on NIC's in virtual machines. Of course there are always security implications, and if the Router/FW get's compromised, it would have full access to all the subnets. I don't think there is any security issue from the client VM's side (other than normal issues), though a shared AD could potentially be a DoS.

UT means "Untagged Traffic" like above. I don't want the client VM's to have to deal with VLAN tagging for obvious security reasons.

One thing that concerns me with regards to VGT is whether VGT within the vSwitch works this way. I kind of got the impression that VGT allows the VM to talk directly to an unmanaged switch via trunking, and am uncertain if the vSwitch will map to the proper port groups without a managed physical switch. The documentation is pretty vague on this.

I understand where you're coming from about the firewalls, however this isn't a traditional Web hsoting situation. We control everything on the client machines, they just use them. The clients don't even have administrator access.

[Texiwill]

Hello,

THank you, I will use this as it is a different type of setup.

My main concern is the same as yours, I am not sure you can feed VGT into a vSwitch from a VM.... If you can not you will have to work out some other arrangement. Perhaps using something like this:

pSwitch<->pNIC<->vSwitch<->VGT VM<->vSwitch<->pNIC<->pSwitch<->pNIC<->vSwitch (VST)

Or use something like:

pSwitch<->AD
            <->FW/Router VGT<->pSwitch<->pNIC<->vSwitch ...

This particular setup will get very confusing very quickly if it does not work from within a VM.

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, (c) 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[mystereman]

Ed,

I've got great news. It works! I haven't configured the full setup yet, but I have created a Linux VM running Ubuntu Server 7.10, I assigned it to portgroup 4095 on a vSwitch with no pNIC attached. I then created two new port groups with VLAN ID's 100 and 110. I created 2 Windows 2000 VM's and configured each to use one of the two portgroups. I assigned each a static IP 10.0.0.50 and 10.0.1.50 respectively.

I then configured the Linux VM using vconfig and added two VLAN ID's of 100 and 110, then assigned 10.0.0.1 to eth0.100 and 10.0.1.1 to eth0.110. I brought up both interfaces, and i could ping the machines on their appropriate subnets. Then, from a seciruty standpoint, i tried to change the ip of 10.0.1.50 on VLAN 110 to 10.0.0.40 and ping 10.0.0.50 on VLAN 100 and as I hoped, I was not able to communicate across VLAN's. I also tried to configure the Linux VM to swap IP address on VLAN's and again, was not able to cross VLAN boundaries.

I did this on 3.0.2 without any updates applied. This is excellent news as it looks like my configuration will work just as i'd hoped.

I haven't tried to bridge vSwitches or do anything fancy, but I'm really happy this is going to work out. Thanks for all your help, and i'll keep in touch as to my ultimate success.

[Texiwill]

Hello,

THat is wonderful news.... Can you try feeding the VGT into the VM from outside and will that route properly?

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, (c) 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[mystereman]

Unfortunately, I don't have any managed switches here to test that with. I could setup a linux VM on my desktop to do VLAN trunking but right now that's not really a priority for me.