My lab Unified Access Gateway started life the way a lot of them do: one NIC, one address, everything on it. User traffic, the admin console on 9443, SSH, and the connections back to the Connection Server and the desktops. It worked fine for a long time. It also meant anyone who could reach the login page could reach the admin console.
Splitting a UAG across two NICs is about the cheapest hardening it can get, but it is a redeploy, not a setting. Here is how mine went, and what I would tell myself before starting.
What two NICs buys you
In a two NIC deployment, NIC 1 faces the internet and carries user traffic. NIC 2 carries management and back end traffic: the admin console, the Connection Server and the desktops. The admin console moves off the internet facing side, which is really the whole point. On my rebuild it listens on the management address and nowhere else.
A three NIC deployment splits management and back end apart as well. It is worth it if your management network is already separate from your desktops. For my lab, two was the right call.
The deployment option is chosen when you deploy the OVA, so plan for a new appliance rather than an edit to the old one.
The wizard fields that matter
Forward rules: leave it empty
The field called “Comma separated list of forward rules” looks like the place for firewall rules. It isn’t. It makes the gateway listen on a port and relay that traffic to another host. Horizon doesn’t need it, and anything you put there becomes an extra open port leading into your network.
Default gateway on NIC 1, static routes on NIC 2
The default gateway belongs to the internet facing NIC. Everything internal the gateway talks to then needs a static route on NIC 2, written as network/bits followed by the gateway, comma separated:
10.0.9.0/24 10.0.30.1, 10.0.2.0/24 10.0.30.1, 10.0.40.0/24 10.0.30.1My list covers DNS and NTP, the networks I administer from, and the desktop subnet. The Connection Server sits on NIC 2’s own subnet, so it needs no route.
Two kinds of route are easy to forget:
- Desktop subnets. Without a route, Blast traffic to the desktops heads out through the DMZ default gateway instead.
- Your admin networks. You reach the console on NIC 2, but without a route back, the replies leave through NIC 1. The session fails, or half works, which is worse.
If you add a desktop pool on a new subnet later, add its route too. The routes can be edited in the admin console afterwards, so missing one isn’t a redeploy.
Gateway Specification
Set it to Horizon_Gateway. Only the Horizon edge services get installed, rather than everything a UAG can do. My old appliance was carrying several services I had never used.
SSH
Leave it disabled and use the VM console. If you do need it, the template lets you bind SSH to eth1 with the SSH Interface field, and allow key pairs instead of passwords. Keep in mind that the OS login user the template creates is a full sudo user, so its password is effectively root.
Password policy and banner
The template exposes minimum length, character classes, lockout and idle timeouts for both the OS user and the admin console. The defaults are modest; the OS user minimum is six characters. I raised both minimums to 16. There is also a login banner field, so use it.
One caution: everything typed into the template goes into the VM’s OVF properties, passwords included, and may stay visible there. Limit who can view the VM’s settings in vCenter, or change both passwords after first boot.
Importing the old settings
I exported the old gateway’s settings and imported them into the new one, which saved a lot of clicking. It also brought my old choices along with it: a cipher list that still had two CBC suites, the Blast External URL on 8443, the old certificate. Treat an import as a starting point and review it like a fresh configuration.
Set the networking at deploy time. The export’s network section describes the old single NIC layout, and that is not what you want back.
Cutover
Keeping the same internet facing address means DNS, certificates and any NAT in front stay exactly as they are. There are two ways to get there. Shut the old appliance down and deploy the new one on the same address, which costs a short outage but is simple. Or deploy on a temporary address, test with a hosts file entry, then swap. It’s a lab, so I took the outage.
The side effect: internal users
My new DMZ network can’t be reached from the internal networks. That is how it should be, and it also meant internal clients pointed at the public name stopped working.
The usual Horizon answer is that internal users don’t go through the UAG at all. They connect to the Connection Server directly:
- Point the Horizon Client at the Connection Server’s own name.
- Keep the Connection Server’s Blast Secure Gateway disabled (“Do not use Blast Secure Gateway”), which is the normal setting behind a UAG. Internal clients then connect straight to the desktops.
- Allow your client networks to the desktop subnets on TCP and UDP 22443.
If you’d rather have one name inside and out, split horizon DNS works, but make two changes on the Connection Server first. Give it a certificate that covers the public name, and add the name to locked.properties so browser connections aren’t rejected by the origin check:
portalHost.1=horizon.example.comEither way, any MFA you add at the gateway won’t apply to users who don’t pass through it.
Once it’s running
- MFA. Add RADIUS or SAML at the gateway. RADIUS is the simpler fit for Horizon: users enter a code, then their Windows password, and log in once. Open source works fine here, and privacyIDEA with FreeRADIUS is my pick.
- Syslog. Send the gateway’s logs somewhere they can’t be edited from the box itself.
- Package updates. Newer releases can apply OS and appliance updates on every boot. Take a snapshot before planned restarts, and check the gateway can actually reach the update repository.
- Ciphers. Drop the CBC suites from the server cipher list. Saving the TLS settings made my health check return 503 for a few seconds, and a load balancer that reads 503 as quiesce will briefly steer new users away, so do it in a quiet moment.
- Certificate. Give the gateway a certificate for its own name rather than a wildcard. A wildcard key on an internet facing box is valid for every name in the zone.
- Port 9443. Even on the management NIC, allow the admin console only from the machines you administer from.
