Hi
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
Thanks
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.
Hey
Do i not have to put https;//externaldns.com:443 ?
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.
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;//externaldns.com:443 - 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?
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.
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.
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.
This was our problem when troubleshooting, thanks Ben. Looks like this product will NOT work with an Airwatch integration. Go figure.
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
UAG Blast Connection to the Desktop or RDSH is Blocked
Connection Server Configured for Blast Secure Gateway
Origin Checking in Connection Server
Bad SSL Server Certificate on UAG
Certificate Mismatch