Question

VMWare Horizon Client Remote Desktop Issue

  • 30 November 2022
  • 23 replies
  • 1271 views

Badge

Is anyone else experiencing issues connecting to a remote desktop via VMWare Horizon Client? I have been using the Nokia Trashcan for about a year now and up until mid October, I had no issues establishing a connection through VMWare. However, when I tried to log in yesterday I kept receiving access denied errors and disconnects before even getting to my remote desktop. I had good signal and no other issues with any other software. Today I took my laptop to the office and was able to remote in with no problems so I think that would eliminate the possibility of the issue being related to VMWare or my laptop.


23 replies

Yes, I have been experiencing issues connecting to Horizon for the last few weeks. Usually I am completely unable to connect, it just spins at authenticating endlessly, then throws a tunnel error. If I am able to connect I experience disconnects randomly.

I do not have this happen when connecting via my secondary CenturyLink internet connection.

Additionally, there are two of us here who work for different companies, we both use Horizon, and both of us are experiencing the issue I described above.

Same issue here and I have contacted T-Mobile they said that they won’t do anything to fix it. My IT department has spent many hours trying to fix this and it is t-mobiles issue.  Update T-Mobile made a firmware update that caused this problem and has now has accepted a ticket to address this issue. 

Update T-Mobile made a firmware update that caused this problem and has now has accepted a ticket to address this issue. 

 

Any chance you could provide the ticket number? I’d be happy to add my name to the list of people who need this fixed. After an hour and a half on the phone today with their tech support I don’t feel like they really understood the issue. Having a ticket to reference could be useful.

Update T-Mobile made a firmware update that caused this problem and has now has accepted a ticket to address this issue. 

 

Any chance you could provide the ticket number? I’d be happy to add my name to the list of people who need this fixed. After an hour and a half on the phone today with their tech support I don’t feel like they really understood the issue. Having a ticket to reference could be useful.

I did not revive a ticket number but I was told I would receive a call back on Tuesday of next week with any solutions the find. Will update then. There tech support is very hit or miss the first time I was on the phone with them I got no where.

Update T-Mobile made a firmware update that caused this problem and has now has accepted a ticket to address this issue. 

 

Any chance you could provide the ticket number? I’d be happy to add my name to the list of people who need this fixed. After an hour and a half on the phone today with their tech support I don’t feel like they really understood the issue. Having a ticket to reference could be useful.

I did not revive a ticket number but I was told I would receive a call back on Tuesday of next week with any solutions the find. Will update then. There tech support is very hit or miss the first time I was on the phone with them I got no where.

Alright, thank you. I’m looking forward to hearing what they have to say.

Userlevel 7
Badge +8

The VMware client probably is using PCoIP via an HTML5 session and it uses UDP ports with AES encryption it seems so my guess is there is port blocking via the 426XLAT solution T-Mobile uses. The session might go out but they might be blocking the return. That might be a problem. If you have a VPN that you use for your personal protection you might try using the VPN tunnel to get through the 426XLAT environment as a work around. If you have a VPN solution that provides no blocking for the protocol(s) or ports involved it should then work. I know it is not optimal but the 426XLAT environment T-Mobile has does present some port forwarding limitations.

Thanks for the insight iTinkeralot, but neither of us connect over PCoIP, we instead use Blast. Could the same thing be happening on a protocol other than PCoIP?

 

I’m not a networking professional, and I don’t know what a 426XLAT solution is (and neither does Google by the looks of it) but if what you are suggesting is the case, would the Horizon connections work intermittently as we are seeing now, or would they have ever worked at all? it is the inconsistency in our ability to recreate the issue that is bugging me about this whole thing.

 

I went and found the logs for the Horizon client at C:\Users\UserName\AppData\Local\VMware\VDM\logs and this is what it shows at the time of failure. From what I can see it is identical to a successful connection attempt right up to the 404 error. Perhaps this makes more sense to you:

 

2022-12-02T12:10:21.266-06:00 INFO (01) [libcdk] : TaskCombiner: ParseResult for CdkGetTunnelConnectionTask(PEND).
2022-12-02T12:10:21.266-06:00 INFO (01) [libcdk] : CdkTunnelClient_SetFingerprint: Tunnel Server expected fingerprint is [redacted]
2022-12-02T12:10:21.266-06:00 INFO (01) [libcdk] : CdkProxy_GetProxyForAutoSettings: Call WinHttpGetProxyForUrl for https://server.domain.com:443/ice/tunnel?22E368E6_EC77_4E2D_8717_EC59583B2DCF.
2022-12-02T12:10:21.268-06:00 INFO (01) [libcdk] : CdkProxy_GetProxyForAutoSettings: Failed to get WinHTTP proxy info with error 0x00002f94.
2022-12-02T12:10:21.268-06:00 INFO (01) [libcdk] : CdkTunnelClient_Connect: Connecting to tunnel server 'server.domain.com:443' over HTTPS.
2022-12-02T12:10:21.268-06:00 INFO (01) [libcdk] : TaskCombiner: CdkGetTunnelConnectionTask(DONE) removed, group task num:2, total task num:2.
2022-12-02T12:10:21.268-06:00 INFO (01) [libcdk] : TaskCombiner: SetResult for CdkGetTunnelConnectionTask(DONE).
2022-12-02T12:10:21.323-06:00 INFO (01) [libcdk] : CdkTunnelClient_SocketConnectCb: The tunnel connection is running in non-FIPS mode.
2022-12-02T12:10:21.523-06:00 EROR (01) [libcdk] : CdkTunnelClient_HandleHttpError: Received Http error: 
HTTP/1.1 404 Not Found
Date: Fri, 02 Dec 2022 18:09:54 GMT
Content-Length: 1934
Content-Type: text/html
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self';font-src 'self' data:;script-src 'self' 'unsafe-inline' 'unsafe-eval' data:;style-src 'self' 'unsafe-inline';img-src 'self' blob: data:
X-Frame-Options: SAMEORIGIN
Connection: close
2022-12-02T12:10:21.581-06:00 EROR (01) [libcdk] : CdkTunnelClient_HandleHttpError: Received Http error: 
HTTP/1.1 404 Not Found
Date: Fri, 02 Dec 2022 18:09:54 GMT
Content-Length: 1934
Content-Type: text/html
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self';font-src 'self' data:;script-src 'self' 'unsafe-inline' 'unsafe-eval' data:;style-src 'self' 'unsafe-inline';img-src 'self' blob: data:
X-Frame-Options: SAMEORIGIN
Connection: close

Userlevel 7
Badge +8

I found a reference to error 0x00002f94 in a VMware link. Old bug related to a proxy fix but should be fixed in the 5.4 client back in 2020. We can see it does use port 443 for a secure HTTP connection. It connects to the tunnel server and then has an HTTP error. Maybe searching on VMNware community to see if there are more matches? I am not sure what browser is best/recommended for use with the client. In effect they should be pretty much the same with respect to behavior due to the standards. It has been a bit since I went fishing in the VMware community but there might be something there. 

The 464XLAT is the IPv4/IPv6 construct that T-Mobile appears to use. Some refer to it as CGNAT which is referencing for carrier grade NAT, network address translation. The behavior may have something to do with a change of how T-Mobile is doing the traffic handling over IPv6. You can see clearly in your client both IPv4 and IPv6 are active. i.e. the dual stack. In packet captures I have seen they tend to use IPv6 for types of multicast delivery. The whole IPv4 services over IPv6 is a bit complicated and does have limitations so port forwarding as with a more traditional IPv4 routing process is not possible. 

The way the VMware client sets up the “tunnel” communication to the server seems like it should work. It might be good to check with IT and see if they have done upgrades to the VMware environment in the office. Maybe the client needs to be updated. However, you stated that in the office it works so that sort of seems to rule that out. In another thread in the VMware community there is a reference to a change in the F5 configuration that may have been involved at one point. The tunnel seems to be established and then closed. Maybe something again related to the F5s and load balancing the traffic. I would try a different browser or two and see if the same behavior persists. Check the VMware community as well. I don’t have an account in there now. I know this could be a rabbit hole so I might better grab a root and stop the fall. 😎

Userlevel 7
Badge +8

One thing you might look at is the external IP. Use the site whatismyipaddress.com before setting up and then if the tunnel forms and holds but then fails check the IP address again. Maybe it is related to the change in the IP address from an external perspective impacting the routing and the session? I don’t know just speculating. You state when in the office it works but over the T-Mobile links it fails. Well the external IPv4 addresses do change from time to time so it might be something to look at. Again VMware would probably be the best resource for pulling this one apart.

Badge

Update T-Mobile made a firmware update that caused this problem and has now has accepted a ticket to address this issue. 

 

Any chance you could provide the ticket number? I’d be happy to add my name to the list of people who need this fixed. After an hour and a half on the phone today with their tech support I don’t feel like they really understood the issue. Having a ticket to reference could be useful.

I did not revive a ticket number but I was told I would receive a call back on Tuesday of next week with any solutions the find. Will update then. There tech support is very hit or miss the first time I was on the phone with them I got no where.

Graber did you hear anything back from T-Mobile on this? Curious as to what they had to say about it.

They said it was not there issue (it is) but would check some ports and latency issues and get back to me.  If this doesn’t fix the issue I will be looking in to a new isp

Userlevel 7
Badge +8

Just curious. Did they see the information you recorded? In the behavior with the failures for Netflix clients to be able to stream the packet captures two users did reflect the HTTPS port 443 fails to connect. On the one he uses Comcast and it works and when he tries to connect to Netflix to stream with T-Mobile it fails and the failure is clearly the inability to connect to the HTTPS server.

It would not surprise me if someone made a mistake that causes the problem either in gateway firmware or in their filtering. An actual packet capture of the initiation of the connection process would probably have the same signature. 

The thread is: Netflix is no longer streaming  (It can’t establish the HTTPS session start.)

Is anyone else experiencing issues connecting to a remote desktop via VMWare Horizon Client? I have been using the Nokia Trashcan for about a year now and up until mid October, I had no issues establishing a connection through VMWare. However, when I tried to log in yesterday I kept receiving access denied errors and disconnects before even getting to my remote desktop. I had good signal and no other issues with any other software. Today I took my laptop to the office and was able to remote in with no problems so I think that would eliminate the possibility of the issue being related to VMWare or my laptop.

They are aware of the issue and do not have any solutions. They sent new boxes and stated it will work, but did not. Then they stated they will not support outside vm connections. 

Userlevel 7
Badge +8

Before you pull the rest of your hair out try changing the DNS on the client to quad9s 9.9.9.9 and just give it another try. I am pretty sure the VMware client is using HTTPS for the session and it may help. Outside connections to the local home network will be a problem due to the 464XLAT they use. Port forwarding is a bit of a problem with their network as they extensively use IPv6 and to translation back and forth between IPv4 and IPv6. 

If that has no positive impact it is not related to DNS resolution due to the DNS coming from the gateway IP address. I use quad9 for my DNS and it works quite well. CloudFlare is anther or Google. The public DNS servers are a better choice in my opinion and you can set your clients as such and it will hurt nothing.

I’m also experiencing this issue.  Good thought re: DNS, but I’ve tried changing my laptop to quad9s and am still having the issue.  It doesn’t happen when I go to a friend’s house (who has Comcast, yuk), and it still happens to me even when I’m connected directly to the t-mobile gateway (instead of to my home router), so I’m also pretty confident that this is a T-Mobile issue.

Just talked with tech support and they mentioned it it not something they are supporting and there is no plan in the near future to support it. I guess I’ll have to revert back to my previous ISP as this app is critical for me. I don’t use it everyday but I can’t go to the library or tether to my phone, other provider, every time I need too. In addition I still have the connection issue with Netflix.  At least I’m still in my free trial period.

Userlevel 7
Badge +8

I would guess if it was working and is not not working it is due to some port blocking that T-Mobile is doing. Some users are still having issues with Netflix and I don’t believe it has anything to do with Netflix. I am pretty sure the VMware client sets up a session with HTTPS and given how many types of applications use HTTPS I would guess it is a blocking issue on ports for the return traffic back and forth between the server and client. 

They might be able to allow it but do not want to. There might be some specific security considerations that they have concerns over with 3rd party actors trying to penetrate the networks. Others seem to have encountered the same issue. 

 Trouble Ticket # 67531560, here is the T-Mobile ticket if you want to call in to see if you can get any other info. As of right now they will do nothing to fix it.

As of last weekend Netflix is working well on all my equipments and VMWare Horizon Client Remote Desktop is connecting and working well.

Userlevel 7
Badge +8

Interesting. There were some issues with Netflix delivery and it appeared to be some port blocking possibly or maybe it had something to do with DNS resolution. They never actually share information about the major interruptions. The Netflix one caused quite a stink. Don't mess with my streaming was the scream heard. I would bet the two were related to the same mistakes.

As of last weekend, Netflix plays on all my equipments an VMWare Horizon Client Remote Desktop can connect and work properly. No change required on my side.

Have there been any updates from T-Mobile on this issue. I see some have had it resolved while others still have the problem. I just got the gateway this week and cannot get into my work desktop through Horizon Client.

I’m 99% confident that it’s an issue with UDP routing on their network.  I subscribed to a VPN that lets me establish a TCP tunnel from my router to their server (basically, the entire time that the traffic is on the t-mobile network) and everything’s working great for me (except for the performance hit that comes from using the VPN).

Reply