Troubleshooting Blast through UAG


I am having problems with Bast connections through my UAG, I am just finishing off a deployment so its not yet work

When i try to connect through the UAG

In the client i don't get an error , it just spins for 10 seconds and then goes back to the pool selection screen

in the admin console on the connection server it allocates me a vdi in the events log

Is there a way to trouble shoot bast connectivity through the chain ?

it works fine over vpn or internally so in my mind it must be either firewall , the uAG tunnel or SSL error

to add my internal dns is different to my external , i am using a wildcard for the external dns all the way through to my connection server and it looks ok

PCOIP is working fine also


0 Kudos
9 Replies

Make sure your Blast settings on the UAG have the external IP address and port like this. It uses port 443.

Since your PCOIP is working fine I'm guessing DNS resolution on the UAG is fine.


0 Kudos


Do i not have to put https;// ?

ive tried both and neither seem to work still

i get the error the display protocol for this desktop is currently unavailable

on the VM i get this in the blast worker service logs

2018-01-16 20:01:50.416Z [INFO ] 0x3914 ServerAsyncSocket::Listen: SSL Ctx is 0000000002D126E0

2018-01-16 20:01:50.416Z [INFO ] 0x3914 ServerAsyncSocket::Listen: Listen for FEC Async connection, port: 22443, numPorts: -1.

2018-01-16 20:01:50.416Z [INFO ] 0x3914 bora::Log: faSSL: SSL listen requested

2018-01-16 20:01:50.416Z [WARN ] 0x3914 bora::Warning: could not bind

2018-01-16 20:01:50.416Z [ERROR] 0x3914 ServerAsyncSocket::Listen: Error: 1 listening on Client Facing Port: 22443

2018-01-16 20:01:50.422Z [INFO ] 0x3914 ServerAsyncSocket::~ServerAsyncSocket: Destroy Server.

My firewall guy has confirmed the ports are correct from the firewall outside to the dmz interface on the uag , but as the 2nd nic sits on the inside management network its assumed all ports are open , is this correct ?

2018-01-16 20:01:50.422Z [INFO ] 0x3914 ServerAsyncSocket::~ServerAsyncSocket: Destroy Server.

0 Kudos
VMware Employee
VMware Employee

So you authenticate successfully with the Horizon client, get presented the desktops you're entitled to, but then fail to connect to the virtual desktop, right?  If that's the case you know that you have  TCP 443 connectivity to the UAG appliances external nic.  You also know you have 443 TCP connectivity from the UAG appliance to the Horizon connection server because you're able to authenticate and see your entitlements. 

If you're using 443 for the blast gateway - https;//  - then all your external traffic can run through TCP  443.   So at that point, if there's a failure still,  the problem could be narrowed down to the connection between the UAG appliance and the virtual desktops.  I would hop on the UAG console and ping your desktops to begin with. 

Here's a blog I wrote about confirming port connectivity for UAG.  I think it could help.   Even Gooder: Troubleshooting Port Connectivity For Horizon’s Unified Access Gateway 3.2 Using Curl A...

How many nics are you using on the appliance? 

0 Kudos

Is tunneling enabled on the connection server(s) that the UAG are pointed to? Tunneling must be disabled.


IS there a way to confirm your internal connections aren't being blocked. I remember seeing this when port 22443 was blocked, it needs to work bother from the uag to the virtual machine, and from the virtual machine to the uag.

0 Kudos

Hello Shaun

I have the same problem, internal connections via blast work, but external via UAG do not work. PCOIP external works successfully. port 443 for the connection server and 22443 and 9437 for the desktops are released on the firewall. the VIew Client even introduces the machines, but presents an error when opening the desktop. I'm suspicious of a certificate issue. Did you solve the problem? Follow logs fo view client

2018-04-24T08:49:43.817-03:00| main| I125: Begin gathering input Locale Identifiers for the user.

2018-04-24T08:49:43.817-03:00| vthread-9| I125: VTHREAD initialize thread 9 "vthread-9" host id 16988

2018-04-24T08:49:43.958-03:00| main| I125: Number of installed Input Locale Identifiers for the user 2

2018-04-24T08:49:43.958-03:00| main| I125: 1. Language 0x416 Layout unique id 0x7e

2018-04-24T08:49:43.958-03:00| main| I125: 2. Language 0x416 Layout unique id 0x7d

2018-04-24T08:49:43.958-03:00| main| I125: Finished gathering input Locale Identifiers for the user.

2018-04-24T08:49:44.067-03:00| mks| W115: SSL: Unknown SSL Error

2018-04-24T08:49:44.067-03:00| mks| I125: SSL Error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Could not negotiate SSL

2018-04-24T08:49:44.067-03:00| mks| W115+ The remote host certificate has these problems:

2018-04-24T08:49:44.067-03:00| mks| W115+

2018-04-24T08:49:44.067-03:00| mks| W115+ * Host name does not match the subject name(s) in certificate.

2018-04-24T08:49:44.067-03:00| mks| W115+

2018-04-24T08:49:44.067-03:00| mks| W115+ * self signed certificate in certificate chain

2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Expected thumbprint doesn't match actual thumbprint.

2018-04-24T08:49:44.067-03:00| mks| W115: Expected thumbprint is: C2:AD:69:D4:90:4B:E0:CF:FE:CC:B0:0C:34:7B:F4:F0:FF:FB:B7:D2:BD:6C:66:EC:51:7E:1F:12:E5:85:56:46

2018-04-24T08:49:44.067-03:00| mks| W115+   Actual thumbprint is: AE:92:91:C8:EC:B2:FD:21:F3:E4:17:55:C6:BB:4C:69:C2:59:C3:EF:23:77:53:44:5B:18:89:1E:BA:22:EE:F5

2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Cannot verify target host.

2018-04-24T08:49:44.067-03:00| mks| W115: VNC CLIENT: received socket error 13: Connection error: could not negotiate SSL

2018-04-24T08:49:44.067-03:00| mks| I125: VNC CLIENT: Destroying VNC Client socket.

2018-04-24T08:49:44.067-03:00| mks| I125: MKSRoleMain: Disconnected from server.

0 Kudos

Your using a wildcard certificate for your external, but what does your internal dns look like. Does it match the same domain name as the external, or is it different. If its different thats where your running into problems I believe.

0 Kudos

This was our problem when troubleshooting, thanks Ben. Looks like this product will NOT work with an Airwatch integration. Go figure.

0 Kudos
VMware Employee
VMware Employee

Here are a few troubleshooting notes I have on Blast connectivity issues. Most problems are nothing to do with UAG but rather a result of a mis-configured firewall, load balancer or blastExternalUrl.

Blast Connection from the Horizon Client never arrives at UAG

  • Timeout log entry in bsg.log.
  1. Firewall (between the Internet and UAG) blocks the Blast protocol port from the client.
    • TCP 443 (or 8443 if the blastExternalUrl specifies :8443). Also, optionally UDP 8443.
  2. Load balancer session affinity is incorrect or timeout is incorrect and Blast connection is misrouted to the wrong UAG appliance.
  3. Load balancer can sometimes block WebSockets (Blast uses WebSockets).
    • Issues seen with both Netscaler and Microsoft TMG. Enable WebSockets in these devices.
  4. Misconfiguration of blastExternalUrl.
    • Should be set to a value usable by the client to connect to the same UAG appliance. When this isn't the case, UAG never receives the Blast connection.
    • Fix the blastExternalUrl config.

UAG Blast Connection to the Desktop or RDSH is Blocked

  • Misconfiguration of the firewall between UAG and the virtual desktop (or RDS Host).
  • Blast connection inbound from UAG is on TCP 22443 ( and optionally UDP 22443).

Connection Server Configured for Blast Secure Gateway

  • Blast Secure Gateway doesn't support multi hop BSG.
  • Visible in the bsg.log on UAG.

Origin Checking in Connection Server

  • Native client Blast works but HTML Access Blast fails (with some browsers and not others),
  • Common reason is Origin checking failure on Connection Server.
  • Look at the debug log file on Connection Server and search for "Origin" to look for origin checking failures.

Bad SSL Server Certificate on UAG

Certificate Mismatch

  • Offloaded TLS/SSL handled on load balancer and the UAG appliance and load balancer have different certificates.
  • When Blast connection is misrouted to the wrong UAG appliance and that appliance has a different certificate to the correct UAG appliance.
0 Kudos