Horizon 7.5 UAG 3.3 Destination Server

[mem111555]

I am unable to make a connection to the destination server. What are some things I could do to troubleshoot this error? I am using horizon 7.5 with UAG 3.3 and a two-NIC configuration.

[techguy129]

Start with the logs.

Collecting Logs from the Unified Access Gateway Appliance

[BenFB]

There are a lot of variables here. Could you provide us with the config file you deployed the UAG from (feel free to sanitize any sensitive information)?

[catracho]

Were you able to resolve this? I have the same issue in my home lab.

[BenFB]

This is likely one of two issues.

1. Incorrect routes with multi-nic deployment.
2. Firewall blocking TCP 443 from the UAG to the load balancer/connection server.

If you share a sanitized version of the INI file you deployed the UAG with I can help rule out a few things.

[sjesse]

Like others said I'd check the logs and firewall rules. I'd review your deployment as well, I saw this once because I didn't enter the dns servers correctly, so the UAG couldn't find the connections servers.

[markbenson]

Download the logs .zip and look for errors in esmanagger.log.

Login to the UAG console as root and run tracepath with the host name you used for proxyDestinationUrl. e.g. "tracepath cs1.myco.int".

Depending on the certificate used on Connection Server, you may need to ensure that proxyDestinationThumbprints have the correct certificate thumbprint configured.

[catracho]

Attached is my ini and esmanager log. I did want to mention I am running Horizon 7.6 and UAG 3.3.1. Also, this is just a lab environment setup on VMware Workstation so there is no real firewall  between the DMZ and internal networks. This is my network setup:

VMnet1 Host-only 192.168.73.0/24 VMNetwork

VMnet2 Host-only 192.168.75.0/24 DMZ

DC1 (DNS, DHCP, CA) 192.168.73.10

Connection1 192.168.73.11

Composer1 192.168.73.12

Security1 192.168.73.13

File 192.168.73.14

vCenter 192.168.73.15

ESXi1 192.168.73.16

UAG1 192.168.73.17 192.168.75.17

I appreciate your help. Thanks!

[sjesse]

10/23 11:38:33,524[nioEventLoopGroup-4-1]ERROR client.HttpClient[lambda$send$1: 209][]: unable to connect to connection1.lab.int:443, reason=io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to host: connection1.lab.int/192.168.73.11:443

10/23 11:38:33,533[Monitoring]ERROR view.ViewEdgeService[healthCheckBroker: 267][]: Exception message:io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to host: connection1.lab.int/192.168.73.11:443

there is a root logon you setup for the uag, can you ping the connection server? Based on your information your doing this with vmware workstation, and if I remember right unless you do something special the two host only networks don't route between each other without a router in between them. To get fancy with vlans I used to use sophos utm, but I made my own.  Another option is https://vyos.io/  but I've never used it.

[catracho]

I can ping it. Also, the UAG has NICs on both the internal and DMZ networks.

[BenFB]

You need to make sure you have your gateway/routes configured correctly.

You can use the following to explicitly specify the gateway or routes depending on your configuration.

defaultGateway=

routes0=

routes1=

routes2=

[kevinpower]

Hello,

We've got the same problem in our environment.

Can you print the output of the following command "route"?

Please notice that when you deployed a UAG, you need to give the default gateway of the eth1 interface which is being connected to the dmz network.

Using two default gateways can cause some problems

[catracho]

As I mentioned before, in my case this is a lab environment being run completely in Workstation. The solution ended up being a simple one. I was deploying a "FIPS" UAG. I discarded the one I was having issues with and deployed a non FIPS ovf and it immediately connected to the Connection server.

[laehcim]

may I know how to deploy in Non Fips mode?

[BenFB]

There is a fips and non-fips OVA. Make sure to download the correct one.

[markbenson]

@gatracho - Your esmanager logs showed:

10/23 17:42:30,613[nioEventLoopGroup-4-1]ERROR client.HttpClient[exceptionCaught: 286][]: Exception caught while communication to backend: javax.net.ssl.SSLException: Received fatal alert: handshake_failure

This is because you were using a FIPS mode UAG in combination with a non FIPS mode Connection Server and there are no common ciphers. This combination is not supported and so you got the SSL handshake error. With non-FIPS Horizon environment you must also use a non-FIPS UAG. Only use FIPS mode UAG if your requirements demand it, in which case, the other components of Horizon must also be in FIPS mode.

The non-FIPS UAG does have common ciphers and as you pointed out, resolved your problem.

Other examples of failure to connect to Connection Server on this thread are commonly caused by basic routing problems (insufficient static routes), or with a misconfigured CS cert thumbprint setting on UAG.

[markbenson]

mem111555​ Did this answer this issue?

[iforbes]

Don't do 2-nic topology. I struggled to make it work for weeks. Go with the 1-nic and your default gateway (firewall?) can be configured to handle all the applicable rules.

[BenFB]

I would strongly disagree with you. The two NIC deployment is the better choice so you can firewall both sides of the UAG. You also have to factor in the reduced capacity of hairpining all your traffic through a single NIC. Depending on your network layout and experience with routing it can add some complexity but it is worth it.

[markbenson]

I agree with BenFB​ - this issue is unrelated to the number of NICs, but in general, multi NIC is better - see DMZ Design for VMware Unified Access Gateway and the use of Multiple NICs for reasons.