TheVMinator
Expert
Expert

vShield Zones vs. other solutions

Jump to solution

I'm looking to get a high level comparison of solutions (vshield zones, pvlans, VMsafe 3rd pary solutions, etc.) for isolating a network of virtual machines within a vSphere environment.

Here is the scenario:

The physical LAN is segmented into a few VLANS already but we don't want to rely on that alone to isolate groups of VMs from one another. We want to also isolate traffic from groups of VMs that belong to similar groups within the virtual environment as well and not have to create a separate vlan on the physical switches for every group of vm's that needs its traffic isolated from other vm's. (all vm's need internet connectivity)

I know this can be done with vShield zones, but I'd like to get a vision of other ways this can be done and how they compare and the pros and cons of each. Also, any other gotchas I need to watch out for such as incompatibility with HA, FT, etc.

If 10 new vm's need to be created and they will be spread out among various esx hosts and different clusters, we want to have all layer 2 frames from these vm's be invisible to all other vm's. Ease of managing the internal vLANs/vShield Zones and solutions that are free or come with enterprise/enterprise plus versions are preferred.

Any thoughts are appreciated.

0 Kudos
1 Solution

Accepted Solutions
Texiwill
Leadership
Leadership

Hello,

Thanks - that is a helpful article. In this scenario, one of the goals is to be able to have a group of esx hosts, clusters and vms, all on the same physical subnet, and all with IP's on that subnet - and then from this larger group of VMs, to separate groups of VM's and allow them to only talk to VM's in their group. For example, suppose there are 200 vm's on the 192.168.1.0/24 subnet. They are all going to keep their IP addresses. Suppose 20 of those vm's are in "group A" and 20 are in "group B". Group A vm's should be able to talk to other group a Vm's only. Group B vm's should be able to talk only to other Group B vm's.

Yes that is possible with many of the virtualization security solutions whether VMsafe or not. This is Zone to Zone protections available from vShield App, vShield Zones, Altor Networks, Reflex Systems, Trend Micro, IBM, Checkpoint, Catbird, etc... Very basic requirement.

However, there could be group A vm's spread out among different esx hosts and clusters. But whatever management tool is controlling the isolation still keeps track of where the Group A vm's are even if they are spread out among separate ESX hosts and ESX clusters. Amidst all of this it is happening without requiring the creation of a separate subnet and and keeping all IP's on the 192.168.1.0/24 subnet. The management piece that is administering the (vshield zones/vshield edge or whatever the solution is) for example, can from one place manage the vm's that are in these separate groups and keep their traffic separate.

Any of the solutions can also do this... Traffic is not necessary 'separate' as it might be on a VLAN but if you feel that is separate enough then that is fine as well.

Although the article discussed some of these topics from a high-level perspective, I'm not completely clear on the distinctions between products and what they can and can't do to understand which product if any will actually do just this. Can this be done with Vshield Zones? The next commenter talked about vshield Edge "separating layer 2 traffic" Is Vshield edge dealing with separating traffic between VM's on separate logical subnets as a router would or on the same subnet? (In this scenario all the vm's would be created on and stay on the 192.168.1.0/24 subnet)

vShield Edge is just that an Edge Firewall much like a PIX firewall, etc. Just a virtual version of such a firewall. It does have other capabilities not found in physical firewalls.

The idea that you have a fluid network that needs to be managed is why you need a virtualization security appliance within your network. All current Appliances require you to place at least one virtual appliance on each host that in turn talk to a management console for all the appliances. So if you have 200 hosts you have 200 appliances talking to a single management node which controls what each of those appliances can do and the policies to enforce on each host. So let's assume the following:

200 hosts. 20 VMs per Trust Zone, 20 trust zones, no two Trust Zones can talk to each other and 20 VMs can be spread over the 200 hosts and there is no known location of the VMs. All VMs on the same subnet.

Your Security Console would have the Policy description that says each trust zone is separate from each other, etc. The policy is sent to the appliances on each of the 200 hosts. and these appliances enforce the policy denying access between VMs of different trust zones.

Any of the mentioned tools can do this. Some do this via VMsafe such as vShield App, Altor Networks, Reflex Systems, TrendMicro, CheckPoint, or IBM. Others do this via inline/out of line devices such as vShield Edge, Catbird, Trend Micro. And still others can do this using PVLANS such as the distributed virtual switch. The inline devices would separate the VMs by portgroups to ensure the necessary protection while the VMsafe style appliances could do this within the hypervisor. In either case your 'Policy' would be enforced.

However NOTE that if the VMs are all on the same subnet then while policy enforcement will work with these tools, a badly configured vSwitch Portgroup would allow any single VM to see all traffic on a given host for the subnet... So now, Auditing becomes a paramount requirement to ensure vSwtich and Portgroup settings do not allow such behavior.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, 2010

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIII: 2009-2021,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill

View solution in original post

0 Kudos
8 Replies
Texiwill
Leadership
Leadership

Hello,

vShield Zones is a Zone to Zone (not 'EDGE') firewall. VMsafe is a Zone to Zone firewall. vShield Edge is an Edge firewall, etc.

Zone to Zone implies no NAT, port redirection, routing, etc. just protect one zone from another. I.e. block port 80 from reaching a VM, etc.

For a comparison of sorts of the major players in this space go to http://www.virtualizationpractice.com/blog/?file_id=41 which will review for you all the current players in this space and what extra they bring to the table besides a firewall.

Consider Zones, App, and 3rd party VMsafe to be placing your Windows Firewall outside of Windows and you may have a better way of looking at their basic functionality.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, 2010

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIII: 2009-2021,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Charu
Enthusiast
Enthusiast

If you are looking for layer-2 segmentation between VMs, without requiring additional VLANs to be provisioned, then you should consider vShield Edge. You can find out more about it at the product page: http://www.vmware.com/products/vshield-edge/. In particular, the Port Group Isolation feature provides L2 isolation for all VMs being protected by an Edge deployment. You can also find more details in the vShield Reference Design Guide: http://www.vmware.com/go/vshield-design-guide.

TheVMinator
Expert
Expert

Thanks - that is a helpful article. In this scenario, one of the goals is to be able to have a group of esx hosts, clusters and vms, all on the same physical subnet, and all with IP's on that subnet - and then from this larger group of VMs, to separate groups of VM's and allow them to only talk to VM's in their group. For example, suppose there are 200 vm's on the 192.168.1.0/24 subnet. They are all going to keep their IP addresses. Suppose 20 of those vm's are in "group A" and 20 are in "group B". Group A vm's should be able to talk to other group a Vm's only. Group B vm's should be able to talk only to other Group B vm's.

However, there could be group A vm's spread out among different esx hosts and clusters. But whatever management tool is controlling the isolation still keeps track of where the Group A vm's are even if they are spread out among separate ESX hosts and ESX clusters. Amidst all of this it is happening without requiring the creation of a separate subnet and and keeping all IP's on the 192.168.1.0/24 subnet. The management piece that is administering the (vshield zones/vshield edge or whatever the solution is) for example, can from one place manage the vm's that are in these separate groups and keep their traffic separate.

Although the article discussed some of these topics from a high-level perspective, I'm not completely clear on the distinctions between products and what they can and can't do to understand which product if any will actually do just this. Can this be done with Vshield Zones? The next commenter talked about vshield Edge "separating layer 2 traffic" Is Vshield edge dealing with separating traffic between VM's on separate logical subnets as a router would or on the same subnet? (In this scenario all the vm's would be created on and stay on the 192.168.1.0/24 subnet)

0 Kudos
Texiwill
Leadership
Leadership

Hello,

Thanks - that is a helpful article. In this scenario, one of the goals is to be able to have a group of esx hosts, clusters and vms, all on the same physical subnet, and all with IP's on that subnet - and then from this larger group of VMs, to separate groups of VM's and allow them to only talk to VM's in their group. For example, suppose there are 200 vm's on the 192.168.1.0/24 subnet. They are all going to keep their IP addresses. Suppose 20 of those vm's are in "group A" and 20 are in "group B". Group A vm's should be able to talk to other group a Vm's only. Group B vm's should be able to talk only to other Group B vm's.

Yes that is possible with many of the virtualization security solutions whether VMsafe or not. This is Zone to Zone protections available from vShield App, vShield Zones, Altor Networks, Reflex Systems, Trend Micro, IBM, Checkpoint, Catbird, etc... Very basic requirement.

However, there could be group A vm's spread out among different esx hosts and clusters. But whatever management tool is controlling the isolation still keeps track of where the Group A vm's are even if they are spread out among separate ESX hosts and ESX clusters. Amidst all of this it is happening without requiring the creation of a separate subnet and and keeping all IP's on the 192.168.1.0/24 subnet. The management piece that is administering the (vshield zones/vshield edge or whatever the solution is) for example, can from one place manage the vm's that are in these separate groups and keep their traffic separate.

Any of the solutions can also do this... Traffic is not necessary 'separate' as it might be on a VLAN but if you feel that is separate enough then that is fine as well.

Although the article discussed some of these topics from a high-level perspective, I'm not completely clear on the distinctions between products and what they can and can't do to understand which product if any will actually do just this. Can this be done with Vshield Zones? The next commenter talked about vshield Edge "separating layer 2 traffic" Is Vshield edge dealing with separating traffic between VM's on separate logical subnets as a router would or on the same subnet? (In this scenario all the vm's would be created on and stay on the 192.168.1.0/24 subnet)

vShield Edge is just that an Edge Firewall much like a PIX firewall, etc. Just a virtual version of such a firewall. It does have other capabilities not found in physical firewalls.

The idea that you have a fluid network that needs to be managed is why you need a virtualization security appliance within your network. All current Appliances require you to place at least one virtual appliance on each host that in turn talk to a management console for all the appliances. So if you have 200 hosts you have 200 appliances talking to a single management node which controls what each of those appliances can do and the policies to enforce on each host. So let's assume the following:

200 hosts. 20 VMs per Trust Zone, 20 trust zones, no two Trust Zones can talk to each other and 20 VMs can be spread over the 200 hosts and there is no known location of the VMs. All VMs on the same subnet.

Your Security Console would have the Policy description that says each trust zone is separate from each other, etc. The policy is sent to the appliances on each of the 200 hosts. and these appliances enforce the policy denying access between VMs of different trust zones.

Any of the mentioned tools can do this. Some do this via VMsafe such as vShield App, Altor Networks, Reflex Systems, TrendMicro, CheckPoint, or IBM. Others do this via inline/out of line devices such as vShield Edge, Catbird, Trend Micro. And still others can do this using PVLANS such as the distributed virtual switch. The inline devices would separate the VMs by portgroups to ensure the necessary protection while the VMsafe style appliances could do this within the hypervisor. In either case your 'Policy' would be enforced.

However NOTE that if the VMs are all on the same subnet then while policy enforcement will work with these tools, a badly configured vSwitch Portgroup would allow any single VM to see all traffic on a given host for the subnet... So now, Auditing becomes a paramount requirement to ensure vSwtich and Portgroup settings do not allow such behavior.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, 2010

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIII: 2009-2021,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill

View solution in original post

0 Kudos
TheVMinator
Expert
Expert

That's an excellent reference - thank you. It almost looks as though for this situation because the goal is to have all VM's on the same IP subnet and not behind NAT, as they would be with Vshield edge, that it is actually vShield App that does what I'm looking for - at least in example number two in this document. In that second example they are using vshield app to prevent communication between vm's that are otherwise on the same ip subnet.

I'm still a little unclear though if it is in fact vshield zones, vshield edge with special port groups, or vshield app that I should be looking at first -

(p.s. now I see that you provided a long answer to my question and I posted this just after your most recent post although I was actually replying to the post before it and hadn't read your most recent post - thanks again I'm looking at your most recent one now)

0 Kudos
Charu
Enthusiast
Enthusiast

If you want all the VMs to be on the same subnet then you wouldn't use vShield Edge, as this product is meant to create isolated network segments that are separated at layer 2. In your case, something like vShield App would be what you'd want, as this provides vNIC-level firewalling for VMs that can be even in the same VLAN. vShield App let you create "security groups", which are logical domains of VMs. You can set rules for network traffic between security groups, and these rules are maintained regardless of what physical server the VMs run on -- they can all be on the same host, and then vMotion to other hosts, and the policies are maintained throughout. You can find out more in the product documentation, or feel free to ask further questions here.

0 Kudos
TheVMinator
Expert
Expert

OK thank you - so it looks like vShield App is what I need to start testing with. And understanding that it is the ability to create vshiled app security groups that distinguishes vshield app from vshield edge helps clarify the issue.

So I was looking at the requirements regarding the version of VMware needed - hoping that it would be included for free, as vshield zones are, with something like the Enterprise license. I looked at the pricing on this website:

if I'm reading this correctly, regardless of your license version, they are saying that you have to pay extra for vshield app - $4500 for 25 virtual machines I'm hoping I'm reading something wrong.

If vshield zones is included with enterprise license, is there any way that either vshield zones, or another open-source solution, can be made to do what vshield app does - allowing you to create your own internal security groups?

0 Kudos
TheVMinator
Expert
Expert

Also, just to add a consideration to the scenario above - where you have

all your vm's on the 192.168.1.0/24 subnet - suppose you are creating 3

security groups of 20 vm's each - group a, group b, and group c. Each

vm in a security group can talk only to other vm's in its own security

group. Now lets say there is another subnet on the physical LAN - a

192.168.2.0/24. One day the first subnet (192.168.1.0 /24) runs out of

IP's, and I want to create a new vm in the 192.168.2.0/24 subnet and make it part of "group a", which up until now has all of its vm's on the first subnet (192.168.1.0/24).

Would this work? Can vShield app (or equivalent product) manage security groups that span multiple subnets on the physical network?

(This is assuming that the router sitting between these subnets is configured to allow all necessary traffic/protocols that the management piece of Vshield app uses)

0 Kudos