I bit the bullet and implemented vShield Edge within my environment along side my existing virtual firewall (thankfully I have some other IP available). But this was not without its problems, it appears there is some critical information missing from the manuals. After a call to VMware, I noticed my mistake (which I actually forgot was necessary). Finally, I have a working vShield Edge but the documents still need a bit of work. Hopefully, these notes will help those going forward.
The first thing to realize, is that vShield Edge is written for security folks to use and not for virtualization administrators. The rules you apply are very similar to those found with in the O’Reilly book Building Internet Firewalls. Which is, actually, one of the better books out there on how to properly create the rules for your firewalls. My copy is well used and marked as I used to build my own firewalls.
I had, what I expected was a simple use for vShield Edge. I wanted to use Edge to protect a View environment while using my existing virtual firewall for my standard DMZ and network. However, I also wanted the View virtual desktops to talk to my new vCloud environment. But the first task was to add in View so that it could talk to my existing environment then add in the vCloud mechanisms. Figure 1 depicts what I wanted to happen, in this case, all I am adding is View into the mix with vShield Edge.
So why use vShield Edge and not my existing virtual firewall? Mainly because, I already serve on port 80 and 443 various existing web services and for View to work not only do I need to serve up port 80 but 443 for View traffic amongst others. So instead of adding in reverse proxies and other complicated features to give me access to more services hanging on port 80 and 443, I assigned a new IP to a vShield Edge Firewall.
vShield Edge, unlike VMsafe type firewalls (vShield App, Trend Micro Deep Security, Reflex Systems vTrust, Juniper vGW, etc.) sits between two vSwitch portgroups (whether on the same vSwitch or different vSwitches). In my case, different portgroups on two vSwitches for the external, and two portgroups on the same vSwitch for the internal side of the traffic.
However, there needs to be a few more things added to the diagram to make View work in a secure fashion. That is the View Connection Broker, and the View Security Server. These two would fall into different aspects of my network to protect them. Figure 2, shows their placement. But the key is why I placed these two services where I did.
The View Security Server acts as a gateway between the desktops and the connection broker and the actual client. In essence, you get a SSL Tunnel from the View Client to the Security Server, and from there communication happens to broker, which hands off to the security server a desktop to which it can connect. If the Security Server was not there, there would not be an SSL tunnel and the hand off would be between the client and the connection broker. Which means you would need to open quite a few more holes in your firewall. The connection broker could live within the View environment, but you really want to protect this server from the hostile environment of the desktops, so in essence the View trust zone (orange in figure 1 and 2) should only contain the desktops.
In our diagram are two vShield Edge (vSE) components, each with their own specific rules. The first is truly a bastion firewall, while the right most (in figure 2) is a way to keep the hostile desktop zone from reaching the internal VMs except on well known ports. But first, how to configure each Edge firewall so that you can actually use them. Just installing and turning on Edge is not enough.
Step 1:
Remember vShield is designed for security folks who understand firewalls, so a bit of information first:
There are two sides and really two sets of tables within an Edge firewall. The first is the External Interface, with its associated firewall. The second is an Internal Interface with its own associated firewall. You can go in and out of each of these interfaces. So for example, if you want to have traffic go from the external to the internal interfaces. You need to allow, Incoming on the External (into the external interface into the middle area of the Edge firewall), and Outgoing on the Internal interface (or into the internal network). There exists a middle area, which is between these two interfaces which is covered by Network Address Translation (NAT) and routing rules.
Step 2:
Set up the NAT, to allow all those IPs on the Internal interface to masquerade as the external IP address. This we would think would be setup by default, but that is not the case. You need to setup the source NAT your self. In other words, you need to modify the source address of the VMs inside the vSE to masquerade as the external IP address. The actual, external interface is blocked out in Figure 4, however lets assume it is W.X.Y.Z and we want ANY internal IP to map to W.X.Y.Z.
Step 3:
Setup external and internal firewall rules to allow the following services through:
- ICMP (to allow people to ping your external addresses to see if they are alive)
- UDP based DNS (53/udp)
- HTTP (80/tcp)
- HTTPS (443/tcp)
- PCoIP (4172/tcp and 4172/udp)
- RDP (3389/tcp)
You also want the same rules for outgoing so that you can respond to the requests appropriately.We will assume the internal IP address is A.B.C.D and the External is W.X.Y.Z. So what does this mean in vSE speak? Enter the following rules:
| Source | Source Port | Destination | Dest Type | Interface Direction |
| A.B.C.D/24 | Any | icmp | Int:In | |
| W.X.Y.Z/32 | Any | icmp | Ext:Out | |
| A.B.C.D/24 | Any | Any | DNS-UDP | Int:In |
| W.X.Y.Z/32 | Any | Any | DNS-UDP | Ext:Out |
| Any | Any | Any | HTTP | Ext:In |
| Any | Any | Any | HTTP | Ext:Out |
| Any | Any | Any | HTTP | Int:In |
| Any | Any | Any | HTTP | Int:Out |
| Any | Any | Any | HTTPS | Ext:In |
| Any | Any | Any | HTTPS | Ext:Out |
| Any | Any | Any | HTTPS | Int:In |
| Any | Any | Any | HTTPS | Int:Out |
| Any | Any | Any | tcp:4172 | Ext:In |
| Any | Any | Any | tcp:4172 | Ext:Out |
| Any | Any | Any | tcp:4172 | Int:In |
| Any | Any | Any | tcp:4172 | Int:Out |
| Any | Any | Any | RDP | Ext:In |
| Any | Any | Any | RDP | Ext:Out |
| Any | Any | Any | RDP | Int:In |
| Any | Any | Any | RDP | Int:Out |
So why 4 rules for every port we want opened? Remember Step 1, where we have two distinct interfaces? We need to deal with each interface separately. We allow these ports In if we also need to allow them Out, so that we have continued communication. We could also try to set up the rules like we do for icmp and DNS-UDP, but I found all 4 are needed for each port.
Step 4:
Use the default ‘block all’ Traffic Police to anything not already listed as open. During testing you may have to set the Traffic Policy to allow, but we really want this to be Blocked per Figure 5.
Step 5:
Allow Communication to the View Desktops. We do this via a route. The View desktops sit on the network I.J.K.0/24, and the Internal side of the vSE is A.B.C.254. So the static route looks like Figure 6. The route says to take all traffic destined for I.J.K.0/24 and pass it through the A.B.C.254 address. Which happens to be the
Step 6:
Using vShield App or vShield Edge, allow the following to communicate from the View Desktops and Security Server:
- Active Directory
- Internal DNS
- View Connection Broker
- and Ultimately my internal vCloud Director
Is that All?
But is this everything? Actually it could be but if you look closely at Figure’s 1 and 2, you will notice that that there is no firewall between the View Zone and the Internal Zone, well not one you can see. The first approach to this was to use vShield App to keep the View Zone from the Internal Zone, but you can also use a vShield Edge appliance to achieve the same behavior. So that you end up with the following overall design of an existing environment (Figure 7).
What is very interesting here, is that vShield Edge can be used to protect bastions, but also to create separation between various trust zones while limiting access between the view desktops and the real internal aspects of your network.
Thanks to @vTexan and his VMware View 5 Install Guide. Without this helpful page, I would not have been able to proceed with my own implementation. Please be aware, however, that the steps @vTexan gives are not necessarily the most secure. Adding in the properly placed firewalls is just one aspect of a secure view implementation, but there is also the proper choice of role based access controls (RBAC) for active directory. The View Connection Broker, requires Active Directory access, but should be limited to a non-domain admin for a newly created View only OU into which the desktops should go. Why, because View needs to be able to modify all aspects of Active Directory for the desktops, so the permissions should be such that the Active Directory user used by View should be limited in scope on what it can modify.
An Aside
I tried to use vShield App to protect the View trustzone from the Internal trust zone but vShield App fails badly if the vShield App appliances suddenly become unavailable. Given that I had 3 such failures, in 8 hours, that were fairly catastrophic, I chose to use on vSE to protect my trust zones.
Conclusion:
So now, we have a fully protected View environment using several vSE’s to provide adequate protection. In addition, we now have a cook book of steps necessary to get vShield Edge up and running (Steps 1-4). Lastly, we have expanded those steps to those required to allow View to communicate properly from the Security Server to the VMs in question.
