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 Blogs
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 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.
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.
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.
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.
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.
Figure 5 - UAG Console showing route and tracepath commands
