Anatomy Of A Successful Tunnel Connection
At a high level there's roughly 4 network paths to consider for a successful Tunnel connection. First, a functional Tunnel deployment begins with communication from a UAG appliance to a WS1 UEM tenant over outbound 443 traffic. Through this connection the UAG appliance not only retrieves it's initial configuration, but also up-to-date information about trusted endpoint devices. Next, there's the outbound 443 connection from endpoint devices to the UEM tenant through which endpoint configurations are obtained, including network traffic rules that control routing of traffic on the endpoints through the Tunnel client. Then there's the VPN connection itself from the endpoint device through the Tunnel client to the Tunnel server. By default, this is over TCP port 8443, but can be configured for any other port. Finally, there's the last leg of the journey from the UAG appliance to the internal resource or, in a cascade mode deployment, from the UAG appliance to a back-end UAG appliance and then onto the internal resource.
Tunnel Edge Scan focuses on validating the path between endpoints devices and the Tunnel server, where the VPN connection is established. This compliments the Test Connection feature available from the WS1 UEM console, which primarily validates communication from the UAG appliance to WS1 tenant.
Test Connection Under Tunnel Configuration
Within the WS1 UEM console, under the Tunnel Configuration page, lies the useful but often misunderstood Test Connection option.
What this tool primarily confirms is a successful connection from the UAG appliance to the WS1 UEM tenant, an absolutely critical connection for the functionality of Tunnel. UAG reaches out to the UEM tenant not only for it's basic configuration but also for a list of acceptable clients endpoints to accept connections from.
What this tool primarily confirms is a successful connection from the UAG appliance to the WS1 UEM tenant, an absolutely critical connection for the functionality of Tunnel. UAG reaches out to the UEM tenant not only for it's basic configuration but also for a list of acceptable clients endpoints to accept connections from.
However, Test Connect doesn't validate the accessibility of the configured Tunnel hostname to endpoints. It's possible to have positive test results from Test Connection, but have a Tunnel instance that is completely unavailable to the world due to connectivity challenges. For instance, you could have a successful Test Connection test but not have the DNS or port connectivity in place required for external access to Tunnel. It's a gap that's confused a many number of customers, not to mention a VMware employee or two.
Tunnel Edge Scan attempts to bridge this gap by validating the external accessibility of the configured Tunnel hostname. While we can't fully simulate the exact network path clients will require for VPN connectivity, we can at least confirm general availability of Tunnel through a scan executed from Google Cloud where Tunnel Edge Scan is hosted.
Tunnel Edge Scan coupled with the built-in Test Connection feature provides a more holistic view of Tunnel health. Test Connection validates communication from the UAG appliance to the WS1 tenant, while Tunnel Edge Scan confirms that external devices will view the Tunnel hostname as expected.
Collectively, both tests will help admins navigate common initial configuration challenges regarding networking and SSL communication.
Interpreting Tunnel Edge Scan Results
To begin with, it's important to confirm that the Tunnel hostname falls within the SSL subject returned from the SSL cert used by Tunnel.
Generally speaking you need to cross reference the scan results with the Tunnel Configuration/Server Authentication section in the UEM console. In particular we're validating the outside world is receiving the SSL cert from the Tunnel hostname as expected.
Generally speaking you need to cross reference the scan results with the Tunnel Configuration/Server Authentication section in the UEM console. In particular we're validating the outside world is receiving the SSL cert from the Tunnel hostname as expected.
Of further interest is the Acceptable Client Cert CA Name reported by Tunnel Edge Scan. It's a telltale sign of a VMware Tunnel deployment, often yielding some unambiguous confirmation. In cases where customers are leveraging WS1 UEM's built in cert authority, the Acceptable Client Cert CA Name will include, "AwVPNDeviceRoot," within the name, along with information of about the tenant and OG the Tunnel instance supports. When folks use their own certificates for authentication this attribute isn't nearly as revealing, but often folks go with WS1's built-in CA.
Performing Checks Manually Against Your Tunnel Edge
While it's easier to leverage Tunnel Edge Scan for an initial diagnosis, it's good to have these openssl commands in your back pocket for further troubleshooting and investigation. Simulating the results of Tunnel Edge Scan is all about getting crafty with openssl.
As far as basic port connectivity goes there's tools like nmap, powershell port query or even good old fashion telnet. Further, to get absolute certainty that packets are making it to specific ports on the UAG appliance you can leverage Test Packets. Once port connectivity is sorted out it's time to move on to the openssl commands.
openssl s_client -connect tunnel-pt.airwlab.com:8443
Along with validating that SSL is functioning properly on port 8443, buried in the output you'll see the Acceptable client certificate CA names output.
Holly cow! Talk about some palm reading. This SSL attributes tells us a heck of a lot about the deployment a Tunnel instance is associated with, including the tenant URL and customer OG.
Next, to validate the SSL thumbprint yielded by the Tunnel service, there's the command:
openssl s_client -connect tunnel-pt.airwlab.com:8443 | openssl x509 -fingerprint -sha1
Less than halfway down the output you'll see the Sh1 fingerprint.
Sha1 is the same format used for the thumbprint reported by the Tunnel Configuration within the UEM console.
Finally, for an environment that leverages port sharing over 443, you'd need to specify SNI as well.
openssl s_client -connect tunnel-pt.airwlab.com:443 -servername tunnel-pt.airwlab.com
For a wonderful deep dive into Tunnel connections check out the Tech Zone Article, Understand And Troubleshoot Tunnel Connections.
I'll Be Your Mirror
Fundamentally, Tunnel Edge Scan is providing a mirror for your UAG based Tunnel deployment. "This is how you're Tunnel instance presents to the world and most likely to all your endpoint devices unless something unusual is going on." If something is amiss with your Tunnel Edge Scan, then you're endpoints are likely to encounter similar challenges and you should troubleshoot accordingly.
No comments:
Post a Comment