Version 6, no access to PAC File

[Franky]

We are using a pac file for the configuration of our client browsers.

At Version 5 the file where placed directly in the wingate program folder.

At the settings of the browser we specified the location of the pac file as following

http://wingate/wingate-internal/proxy.pac

This was working fine in Version 5, after updating to Version 6 it dosn't work any longer.

If i enter this URL directly in the browser i got a ACCESS DENIED and this is exactly the reason why the browser can not load the configuration.. simply said in Version 5 access to this location was possible in Version 6 not..

If i place the file to the Java folder for example i can access it without problems (http://wingate/wingate-internal/java/proxy.pac), but i didn't want change the browser configuration of all clients. This simple test told me that it is working but something must be different now, and this blocks the access to the wingate main folder...



Thank's

Franky

[jamesc]

Hi Franky,

I will have to run this by my colleagues tomorrow; will advise.

[Franky]

That's fine, i am waiting for your result....

[jamesc]

Hi Franky,

We were not able to get to this today; my apologies.

[Franky]

....any news ? :-(((

thank's in advance

[corcoran]

franky - are you getting an 'access denied' message from gatekeeper/puresight plugin??

[MattP]

Hi Franky,

What happens if you just choose automatically detect settings?

[corcoran]

franky - if you have a DNS server, it'd be easier to create a WPAD Cname in your DNS zone then rename your proxy.pac to wpad.dat and set the 'automatically detect settings' option in IE.

what happens when you http://proxy/proxy.pac ?? from any of the machine on your network? In IE you should have it set to use that file, which should also therefore be using 'direct' to connect to anything local..

umm yeah

[jamesc]

Also, try this: http://wingate./wpad.dat

[Franky]

Dear all,

thank you for your help, but still now the Version 6.0.4 is not working like Version 5.x and 4.x in the past.

Thank you also for your workarounds but that is what i want to avoid, to change the settings on all machines if i do a update to Version 6.

Oh yes, maybe i found why this feature (http access to the wingate root directory) is not longer working.. i think Wingate Staff now's already why, because in the prevoius versions of Wingate a security hole is existing and exactly this is based on the wingate root directory.. . it was reported that this security hole is closed since version 6.0 RC1 (build 963) it seems the result is that there is no http access to the wingate root posible any longer.
So it is planed to fix this new error caused by a securtiy fix in the future?

Thanks and best regards

Frank

[MattP]

When you set the client browsers to automatically detect settings they send a request to the DNS server for a wpad file. If WinGate is the DNS server then it creates a wpad file and sends it to the client. This should be all that you are required to do.

[Franky]

Hello Matt,

sorry but i think you didn't understand me in the right way... i would avoid to much action on the client side.. so for me it would be fine if the Wingate 6.x version is working like the previous one.

I didn't understand why it is so hard to understand.. there are also many reasons why the Wingate should not be the DNS Server. One point is the quality of your Software...

The reason why we want update to Version 6 is a big problem in the last 5 version.. if there is to much traffic on it the wingate.exe comes up with a memory leak, the memory which the wingate.exe needs grows up and later wingate generates high traffic on our switches and is crashing totally from time to time, sometimes it slows also down our network with a broadcast storm when the engine was crashed...

As Version 6 was relased the Java authentication was not working well, unfortunality we are using the Java authentication so no update was possible for us.. also other user got this error and at this time the Wingate Staff give's also stupid answers or "workarounds" the same reaction like in the past when the software has majour problems after a new release.

Now in the latest Version 6.x Version the Java Authentication is working well again but you fixed up a security hole and so no direct access to the wingate root by the webbrowser is possible any longer.. again and again this software has majour problems in version 4 in version5 and now in version6

Hey guy's, i now that software development is a hard job but that's your bussines ..

We are planing to consolidate all our locations to a central proxy server so in this case we would buy a new full enterprise license of the Version 6 but now i would beginn for searching for alternative solutions

To long time we had trouble again and again with the wingate software i think this software would be good for 5 user at a home office but in a production enviroment with 500 Users for example the software is very bad and didn't cover the requirments for a company like stability and security.. so maybe we are kick out the Wingate here as soon as possible.

[adrien]

Hi Franky

Just been looking on our forums for PAC issues, and saw this old post.

I don't know if you are still using WinGate, but there could be another way around it if you have any other web server available on your network.

You'd need to redirect the request for

http://wingate/wingate-internal/proxy.pac

To another server and then HTTP redirect this to the correct location, or serve the file from this different server (e.g. not WinGate).

The reason this URL does not work any more is because it relied on an exploit - a security hole. We had to close the hole. The hole was that any URL with the token "wingate-internal" in it was served without access checks using the WinGate folder as the root. So this URL was only ever intended to serve internal files by WinGate. The fix to the hole was only to allow serving this file from either the Java client folder or the resources folder, which were the only folders that this method should be used to access.

However both of which would require a re-write of the URL, and therefore reconfiguration of all your client machines.