DMZ Design for VMware Unified Access Gateway and the use of Multiple NICs

DMZ Design for VMware Unified Access Gateway and the use of Multiple NICs

Introduction

VMware UAG is a virtual appliance used by several End-User Computing products to support remote access from the Internet into applications and virtual desktops running in corporate data centres or in the cloud. It is a layer 7 security appliance that is normally installed in a De-militarized Zone (DMZ) and is used to ensure that the only traffic entering the corporate data center is traffic on behalf of a strongly authenticated remote user. You can read more details of this here Technical Introduction to UAG for Secure Remote Access - VMware End-User Computing Blog - VMware Blo...

UAG is usually installed by using a PowerShell command. This avoids the need to use a GUI and simplifies installation allowing all configuration settings to be precisely applied so that the appliance is secure and production ready on first boot. See Using PowerShell to Deploy VMware UAG.

One of the configuration settings for UAG is the number of virtual Network Internet Cards (NICs) to use. UAG has a deploymentOption settings which is specified as onenic, twonic or threenic. Each NIC must be on a separate segment so onenic, twonic or threenic corresponds to environments with one, two or three segments respectively. The Admin UI and REST API on port 9443 is accessible on the Management NIC.

onenic - Front-end, Management and Back-end on eth0. Admin UI is accessible on eth0.
twonic - Front-end on eth0, Management and Back-end on eth1. Admin UI is accessible on eth1.
threenic - Front-end on eth0, Management on eth1 and Back-end on eth2. Admin UI is accessible on eth1.

The use of multiple physical networks or vLANS within a DMZ is not new. Reducing the number of open ports on each vLAN/segment and separating out the different types of network traffic can significantly improve security. This post describes the purpose of multiple NICs with UAG and outlines some of the security and performance benefits. The benefits are mainly in terms of separating and isolating the different types of network traffic as part of a defense-in-depth DMZ security design strategy. This can be achieved either by implementing separate physical switches within the DMZ, with multiple vLANs within the DMZ or as part of a full NSX managed DMZ.

A Typical Single NIC DMZ Deployment

The simplest deployment of UAG is with a single NIC where all network traffic is combined onto a single network. This works well for a simple DMZ. Traffic from the Internet facing firewall is directed to one of the available UAG appliances. Authorized traffic is then forwarded by UAG via the Inner firewall to resources on the internal network. Unauthorized traffic is discarded by UAG.

AccessPointNIC1.png

Figure 1 - UAG ONENIC Option

Separating Unauthenticated User Traffic from Backend and Management Traffic

An improvement over the single NIC deployment is to specify 2 NICs. The first is still used for Internet facing unauthenticated access, but the backend authenticated traffic and management traffic are separated onto a different network as shown in figure 2 below.

AccessPointNIC2.png

Figure 2 - UAG TWONIC Option

In this two NIC deployment, traffic going to the internal network via the inner firewall must have been authorized by UAG as any unauthorized traffic will not be on this backend network. Management traffic such as the REST API for UAG will only be on this second network.

If a device on the unauthenticated front-end network was compromised, such as the load balancer, then reconfiguring that device to bypass UAG would still not be possible in this two NIC deployment. It combines layer 4 firewall rules with layer 7 UAG security. Similarly, if the Internet facing firewall was misconfigured to allow TCP port 9443 through, this would still not expose the UAG Management REST API to Internet users. A defense-in-depth principle uses multiple levels of protection, such as knowing that a single configuration mistake or system attack will not necessarily create an overall vulnerability.

In a two NIC deployment, it is common to put additional infrastructure systems such as DNS servers, RSA SecurID Authentication Manager servers etc. on the backend network within the DMZ so that they can not be visible on the Internet facing network. This guards against layer 2 attacks from the internet facing LAN from a compromised front-end system and effectively reduces the overall attack surface.

Most UAG network traffic is the display protocols for Blast and PCoIP. With a single NIC, display protocol traffic to/from the Internet is combined with traffic to/from the backend systems. When two or more NICs are used, the traffic is spread across front-end and back-end NICs and networks. This can result in performance benefits by reducing the potential bottleneck of a single NIC.

VMware's own deployments of UAG such as for Horizon Air, uses the two NIC deployment approach.

UAG supports a further separation by also allowing separation of the management traffic onto a specific management LAN. HTTPS management traffic to port 9443 is then only possible from the management LAN. This final option is shown in figure 3 below.

AccessPointNIC3.png

Figure 3 - UAG THREENIC Option

Routing

During UAG deployment it is common to specify a default gateway. In complex environments involving multiple NICs and routing through more than one gateway, UAG also supports the ability to specify explicit IP routes. These are routes that don't use the default gateway.

For example, with a TWONIC UAG deployment, the network routing may involve a default gateway for all IP traffic destined for Internet located devices. Additionally network routing to the Internal Network may involving routing through a separate back-end gateway.

Front-end DMZ Network: 192.168.9.0/24

UAG Front-end IP address (ip0): 192.168.9.51

Internet Access gateway: 192.168.9.1

Backend and Management DMZ Network: 192.168.0.0/24

UAG Back-end IP address (ip1): 192.168.0.51

Internal network Access gateway: 192.168.0.1

Internal Network: 10.0.0.0/16

The configuration for UAG would be:

ip0=192.168.9.51

ip1=192.168.0.51

defaultGatteway=192.168.9.1

routes1=10.0.0.0/16 192.168.0.1

When UAG needs to connect to a host on the Internal network with an IP address of say 10.0.0.120, the routing entry on UAG would force this connection to go via the back-end gateway 192.168.0.1 on the second NIC (eth1). The NIC used by UAG for any outgoing IP traffic is selected based on the destination IP address and for destinations not on any local segment, the contents of the routing table. For any destination not on any of the local segments, UAG will look for an explicit route for that network. If no routes are found, it will direct traffic via the default gateway which is normally the gateway to the Internet.

From the UAG console, where you login as root, you can run "ifconfig" to look at the addresses for each NIC (eth0 and eth1 in a TWONIC setup) and run the "route -n" command to show the active routing table.

UAGRoutes1.png

Figure 4 - UAG Console showing ifconfig and route commands

To check the routing table for any IP destination address you can run the "tracepath -n destination-ip-address-or-hostname" to see details of the route.

UAGTracepath1.png

Figure 5 - UAG Console showing route and tracepath commands

In order to specify private (non public) IP address routing for the address ranges defined in RFC 1918 - Address Allocation for Private Internets you can specify these as in this example:

routes1=10.0.0.0/8 192.168.0.1,172.16.0.0/12 192.168.0.1,192.168.0.0/16 192.168.0.1

Then all possible private addresses will be accessed via the second (eth1) NIC via the 192.168.0.1 gateway. This saves having to specify multiple individual subnets for internal routing. The default gateway for public Internet IP addresses would be the default gateway on the Internet facing NIC (eth0).

Comments

Thank you for the great document Mark;

When testing the 2 and 3 NIC configurations I had an issue where traffic would only travel through the fist NIC.  Since my firewall settings would only allow internal traffic through the 2nd or 3rd NIC, users would be unable to connect.

(all NICs would be in same VLAN- DMZ)

Also, is there a need to configure the gateway for this to work in unconventional configs (x.x.x.250 being the gateway)

Thank you

Jose

Hi Jose,

Thanks for posting.

You're right that with 2 or 3 NIC setups you have to configure routing carefully. This is particularly the case when your DMZ has more than 1 gateway. With Access Point 2.7.2 and newer we added the ability to automatically add routes to the appliance at deployment time. Look at the referenced PowerShell document and search for "routes". The appliance can only have one default gateway and that is taken from your vSphere network protocol profile associated with the named network. You can log on to Access Point console as root and run "route -n" to look at the routing table. You can try to ping backend servers such as the Horizon View Connection Server to verify that routing is set up correctly. The choice of NIC for outbound connections on Linux is determined by addressing and the routing table.

It is perfectly normal that the backend traffic goes out on the backend NIC(s), so you are right to have the firewall rules you have.

I suspect your issue is standard Linux routing and routes0, routes1 and routes2 can be used to solve it.

Mark

Version history
Revision #:
1 of 1
Last update:
‎10-04-2016 03:48 AM
Updated by: