Recently, the Unified Access Gateway (UAG) 3.6 was released and our fear has come true… UAG is now the Super Edge for VMWare. Content Gateway, Tunnel, and now SEG are all part of the VMWare gateway product. There’s no question that its a very divisive product for true and not so true reasons, but let’s take some time and start discussing it…
My Lab Setup
I bought a nice little server at my house to make the magic happen. I purchased a fun little PowerEdge at my local Micro Center for about $3000 (yes I’m that crazy) because I’ve always wanted to build my own lab and let’s be honest we should all have one at this level.
The basics around my lab setup are:
- 32 GB of RAM
- Raid-1 pair of 2 TB Drives
- ESXi 6.7
- Windows Server 2016 with a Single DC with ADCS, DNS, DHCP, File Share, IIS. Group Policy
- UAG OVA Deployment
- Port Forwarding on my Arris router to setup external access for my UAG
- Future State
- 2nd server for intermediate CA
- Additional Servers for On-Premise Setup
UAG OVA Deployment
The UAG deployment itself is very simple. It’s mostly about answering basic questions. Let’s walk through it..
Starting with Deploying the OVF Template and Browsing to the OVA
Type in a VM name and Select the Location
Select your ESXi Host
Now you just review the info and continue on..
Setup your NICs and Network Mappings, which is up to your preference. In a lab its not relevant, but typically you should consider separate NICs and VLANs to follow InfoSec best practices.
Now pick your datastore…
Now you are selecting what VLANs to put the 3 networks on (Management, Front End and Back End along with the IP address settings
Now you will configure all of the networking and set your account credentials..this is the most important part otherwise you will end up rebuilding the box.
Once complete, it will build your UAG, which will take some time. One bug that exists in the OVA build process is sometimes you will see a bad build, but that mostly effects when people build their UAG on the ESXi console vs vCenter. This becomes very clear when trying to browse to the URL: https://servername:9443/admin/index.html. As you can see below, this is the screen you should see.
Configuring the UAG
Once you have logged in, you will want to do some optimization and setup. We will need to handle a few key things to ensure its properly secure before setting up the SEG:
- SSL Setup
- TLS Security
Once you login, go into the TLS Server Certificate Settings menu, which is the first thing you should do..
Follow my screenshot below by uploading your certificate, inputting the password, and checking the boxes. The major key is not to name the alias (this is when you want to overwrite an existing certificate).
If necessary, I suggest going to my Github here to grab my OpenSSL scripts for creating a proper certificate request.
You will see this screenshot to show that you did it successfully:
TLS Security is sort of my thing. I always strongly suggest to check your work by going out to the SSL Labs Server Test when rolling out any technology to see how secure the platform is. Reality is that it is inevitably up to you to secure your platform. VMWare is the taco,but YOU have to add in the condiments.
The SSL test shows a few things to be aware of from a security posture. The items that I care about are:
- TLS 1.3 isn’t enabled (This doesn’t matter yet as TLS 1.3 is pretty new yet super exciting)
- SEVERAL weak ciphers enabled. A new version of a proxy should not have RSA ciphers enabled. That’s a major no-no! Read this here to learn why!
- No HSTS support, but you “could” argue if you only have one protocol enabled its irrelevant, but that may not be a reality if you want to use your UAG for multiple technologies.
- No HTTP/2 Support (Boo!!!)
Removing weak ciphers
The only item here you can really remediate is the weak ciphers, so let’s do that together!
First, we go back into the console and go to System Configuration
We will focus on the ciphers, but I also suggest setting up SysLog to keep your security team happy! Don’t forget to use the “i” where you can as they did a nice job of adding these in and they can be very helpful.
Once we extrapolate the defaults, we see these entries below, let’s take note that there is only ONE cipher listed that is a good one: (The ones in bold are weak ciphers)
Setting up the SEG
The SEG setup is pretty easy. You will basically take your same setup that you had for SEGv2 and bring that over, but for thoroughness a few screenshots below. A few things to remember, the external URL is either your load balancer OR the UAG endpoint:
Configuring SEG in the UAG
The last portion is configuring the Mem Config GUID from WorkspaceONE UEM in the UAG and hope that the magic happens!
Now, we go back into the console, and toggle “Edge Service Settings” and go into the “Secure Email Gateway Settings Section”
Now, you configure all the good stuff! Enter the API settings like you see below, your UAG or Load Balancer hostname, the MEM GUID (no that’s not a right one!), and if you expand advanced settings I strongly suggest adding in the Root Certificates just to be extra thorough.
A few painful, gut-wrenching minutes later you will see the green light! That means you are cooking with gas!
We all can use a little help
We have a nice little tool set available on the UAG that will make life easier.
You can install TCPDump so you can take packet captures for troubleshooting as you see below by running sh /etc/vmware/gss-support/install.sh.
Once installed you can run commands like this: tcpdump -i eth0 -n -v udp port 8443 to collect a packet capture on UDP/8443. I suggest looking at the tcpdump guide here for more info.
For those who are new to Linux, CURL is your friend always. You can leverage curl to test back-end connectivity and ensure your network/security team did their jobs! It’s pretty simple to use and so very powerful!
As you can see a simple curl -v https://outlook.office365.com shows me that I can connect, that I’m using TLS 1.2, the certificate, the handshake, and so much more!
You can grab logs by clicking on the Log Archive button. Don’t forget as usual you can go into Log Level Settings below to turn up the log level, but DON’T forget to turn it back down afterwards.
Your Friend: REST API
REST API calls can be useful on the UAG, with many of them undocumented anywhere, but fear no more! Mobile Jon is here to document the calls! Below, is a list of the various API calls and their function…
https://UAGSERVER:9443/rest/v1/config/system: Provides you with a JSON-formatted response with your UAG server info.
https://UAGSERVER:9443/rest/v1/config/adminusers: Provides you with a JSON-formatted response of all UAG admin accounts
https://UAGSERVER:9443/rest/v1/config/edgeservice/seg supports PUTs and lets you programatically update your SEG configuration
The remainder of the current API commands can be found in this YAML file on my GitHub site here
I definitely recommend investigating the other scripts available on the UAG, which live in /opt/vmware/gateway/scripts. You have several useful scripts like scripts for changing the admin password, stopping and starting the SEG service, changing the DNS tables, configuring SEG clustering, and much more.
I think that’s more than enough on this 🙂 This should give you a great foundation as you plan to move toward the UAG. It’s not all rainbows and unicorns sadly. You will definitely have to get used to certain things in the UAG. The UI isn’t as robust as on WorkspaceONE UEM. It’s more basic, which makes configuring it much easier but it doesn’t always help you understand what you are missing like the great test connection functionality we have had for years.
We will continue to need to work on things. There are some small bugs you may notice, like if you click refresh in your browser, it will make you log back in, but overall it’s a HUGE value to get to a single platform for all external connectivity. The UAG is a very powerful platform, but as you know with great power comes great responsibility.