Failed To Get Winhttp Proxy Info With Error 0x00002f94
Violette Taps
The error values listed below are returned by GetLastError when one of the Microsoft Windows HTTP Services (WinHTTP) functions fails, and are also returned in the lower 16 bits of HRESULT error returns from the WinHttpRequest object.
The server requires SSL client Authentication. The application retrieves the list of certificate issuers by calling WinHttpQueryOption with the WINHTTP_OPTION_CLIENT_CERT_ISSUER_LIST option. For more information, see the WINHTTP_OPTION_CLIENT_CERT_ISSUER_LIST option.
If the server requests the client certificate, but does not require it, the application can alternately call WinHttpSetOption with the WINHTTP_OPTION_CLIENT_CERT_CONTEXT option. In this case, the application specifies the WINHTTP_NO_CLIENT_CERT_CONTEXT macro in the lpBuffer parameter of WinHttpSetOption. For more information, see the WINHTTP_OPTION_CLIENT_CERT_CONTEXT option.
The connection with the server has been reset or terminated, or an incompatible SSL protocol was encountered. For example, WinHTTP version 5.1 does not support SSL2 unless the client specifically enables it.
The login attempt failed. When this error is encountered, the request handle should be closed with WinHttpCloseHandle. A new request handle must be created before retrying the function that originally produced this error.
Indicates that a required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file, or that the validity periods of the certification chain do not nest correctly (equivalent to a CERT_E_EXPIRED or a CERT_E_VALIDITYPERIODNESTING error).
One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server. To determine what type of error was encountered, check for a WINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification in a status callback function. For more information, see WINHTTP_STATUS_CALLBACK.
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.
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 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.
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.
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:
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.
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.
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.
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.
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.
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.
The isResolveable, myIPAddress and dnsResolve proxy script support functions
in WinHTTP are broken. It appears that dnsResolve and isResolveable will
work only if the host string parameter contains an IPv4 literal address;
they will not work for DNS names.dateRange and timeRange are not implemented by WinHTTP. That is currently
by-design.I haven't been able to confirm the issue with isInNet yet, but that sounds
like a bug too.The broken isResolveable, myIPAddress and dnsResolve functionality is a
serious defect. Currently there is no timeframe for when a fix could be
available. I would recommend that you contact Microsoft Product Support
Services, report and escalate the issue, and request a hotfix.
Regards,Stephen Sulzer
Microsoft CorporationThis posting is provided "AS IS" with no warranties, and confers no rights.
"Alan Yu" wrote in message
news:#pkfaL13...@TK2MSFTNGP11.phx.gbl...
I was putting together this message to email to you directly when I
discovered this thread on the newsgroups, so I will post it instead.I've been attempting to migrate to WinHTTP 5.1 and I've found several
show stoppers on the new version. I don't see a whole lot of
discussion in the newsgroups about this dll so I take it there aren't
many people using the features. Here are the issues I've found:Basic authentication to a web site via WinHTTP 5.1 Fails to
authenticate. If I change my COM reference (in vb6) to the 5.0
version instead of the 5.1 version, my BASIC authentication works once
again. I can post relevant source code if it would be helpful.Auto-Proxy detection does not evaluate autoconfing (PAC) scripts
identically to IE 6.0. Some javascript functions (such as isInNet and
dnsResolve) are broken. Specifically, the isInNet() function only
works if you pass it an IP address as the first parameter, even though
it is documented that it's supposed to accept a hostname or an IP.
Also, the dnsResolve() function is supposed to convert a hostname to
an ip address and it incorrectly returns to 'false' for any string
passed to it. As a result of these errors, auto-proxy-detection will
fail on customer networks that utilize these functions as part of
their autoproxy pac file (which works correctly in IE6). It'll
basically be hit-or-miss if trying to utilize auto proxy detection at
a new customer site.Calling for an End-Of-Life on WinHTTP 5.0 when 5.1 still contains
significant bugs is a premature move. If there is a newer version of
WinHTTP.dll please let me know so I can test these issues with that
version.My version of winhttp.dll is 5.1.2600.1106, which ships with Windows
XP SP1.ThanksRon DeFulioPS: Since it appears I am not the only one encountering this problem
with the autoproxy support, I would hope that posting my findings here
will help escalate the problem further."Stephen Sulzer [MSFT]" wrote in message news:...