Wingate "Check for updates" failing

[SpareRib]

I've only just got around to installing wingate after purchasing some months ago (damn other priorities!).

So far I've installed the latest version (WinGate8.2.1.4711-USE) onto a windows server 2012 R2 virtual server.

After initial install and registration, I attempted to run the check for updates service, however was met with some certificate path exceptions. After looking at the trusted certificates I could see that the chain used by the updates.qbik.com host was not trusted by the 2012 R2 server. So far I've downloaded two certificates from my client machine and added one to the trusted root certification authorities store and one to the trusted intermediate certification authorities store.

This seems to have made the certification path check happier, however I'm now getting a different error which simply states:
(https://updates.qbik.com/serviceV2.php) Error -1 fault: SOAP-ENV:Client [no subcode]
"End of file or no input: Operation interrupted or timed out"
Detail: [no detail]

checking the forum I see one other user with the same issue, but no resolution other than a follow up from Adrien
viewtopic.php?f=12&t=41109&p=38252

Following the queries in that thread:
This server does go through an ASA firewall, however it has unrestricted access on ports 80 and 443. I can't see anything in the logs to indicate it's being blocked. There are some anomalous hits from this server to 10.0.0.1:137 and 10.0.0.2:137 which is odd as those IPs aren't in our addressing scheme.

anything else I can try? short of installing wireshark/netmon?

cheers.

[adrien]

Hi

that looks like the connection is getting closed without any data.

If you manually select "check for updates" does it also fail?

Regards

Adrien

[SpareRib]

I meant to post this last Tuesday before I went on leave, i'm not sure why I didn't... anyway... (there's a follow up post to this one as I've just done some more testing/monitoring)

hi,

Yes it does fail when checking manually as well as the automated check.
It occurs when using the console both remotely and locally to the wingate server...

I'm able to use Wingate as a proxy, so I know it has access to the internet.

Is anyone else running this version installed fresh from the download available on the website?
My development installation has stopped working for updates as well. I reinstalled this instance from the latest download on the website as an attempt to fix a blue screening issue I was experiencing (disabling the extended network feature ended up resolving that problem). Prior to the reinstall, the check for updates was working, however it no longer works after the latest install.

So that's two different installations, both with full internet access, not working to check for updates with the latest version. Both were installed through the download available on the website (WinGate8.2.1.4711-USE)..
Dev OS - Windows Server 2008 R2
Prod OS - Windows Server 2012 R2

Cheers

[SpareRib]

Hi,

I've just done some more testing and I think I might have worked out why it's failing.

After changing the Wingate service to use an existing proxy we have, the update process successfully connected for the first time. (I had to allow a few certificate revocation list endpoints to be accessed anonymously as the connection didn't authenticate).

After this, I changed the Wingate service back to not use a proxy and tried again. I still had the other proxy window monitoring and I saw a few hits appear, even though Wingate is not set to use a proxy at the moment.

From this, I'm guessing that Wingate service is attempting to connect to the internet and is adhering to the auto-detect proxy settings we publish for clients... i'll keep looking into it from this angle, but if you or anyone else knows how to stop this from happening before I find a fix, let me know! :)

Cheers.

[SpareRib]

So just as a follow up to my issue:

the issue revolves around the update process within Wingate using the WinHTTP Web Proxy Auto-Discovery service to check the network for an automatic proxy configuration. We publish such a configuration on our network, so the update process was told it should use a proxy to access the update web service at wingate.com.

I couldn't find an easy way to stop just one application from utilising this auto-discovery service, so instead I modified the automatic proxy configuration script so that if it's running on the wingate server it knows to go direct to the internet.

pretty straight forward for anyone already working with such a proxy configuration file, but this is the code snippet to fix my issue (replace ip address appropriately).

Code:

function FindProxyForURL(url, host)
{
// If the source ip is the wingate server
   if (myIpAddress() == "10.10.10.10")
   {
      return "DIRECT";
   }
// more rules ....
}


cheers,
Brendon

[adrien]

thanks for that.

I didn't think it should be trying to use auto proxy detect, since we have explicit config for a proxy. I'll have to double check that - you're right it does use WinHTTP. It may be related to settings in the OS, which are in the system account.

I believe there is a way (some command line app) to set proxy configuration for system apps, so there may be an alternative fix to turn off proxy auto detection for the system account.

Adrien

[SpareRib]

No worries. just thought I better add some closure to the forum thread since it's a pet hate of mine when I'm researching an issue and a forum just goes dead without an answer or response from the OP.

Not sure why it only started happening recently though. I'm sure it used to work on my evaluation version I had running on server 2008r2. But that server plus my production one all started showing the above error as of the newest version.

[adrien]

OK thanks for that

looks like it was fixed in the WinGate 7.x branch a long time ago, but the fix didn't get migrated down to the WinGate 8.x branch. I'll do that.

thanks so much for reporting!

Regards

Adrien