it strangely seems that the juniper components are not able to use automatic proxy search. We and already one of our partners have the problem that we do not set a fixed proxy in the internet options. We rather use automatic proxy detection and assign different proxies to different locations based on rules in the pac file.
However we also have a default rule at the end of the pac file so no location should ever be without a proxy returned by the pac file!
The Internet Explorer understands the pac file fine. The user sees the ive login page and can sign in. However the Hostchecker does not try to use a proxy but instead sends the packets to the ive directly. As many other companies we dont allow http/s to the internet directly for security reasons. So in the end the user sees the hostchecker failing although his computer matches the criteria...
A partner company of ours which does not need to pass a hostcheck has the problem that they also use automatic proxy detection and the Terminal Services Client for RDP does not recognize the proxy settings.
So this is kinda bad because a lot of companys use automatic proxy settings for their users or their guest wireless. Juniper Support replied me i should have a specific line for the ive in the pac file which is a cosmetic solution at best because user only use the vpn in our company network to set it up and see if it works. But we cannot tell the rest of the world to add our ive to their proxy pac files....
I dont really think this is not supported. I rather think this is a bug in the firmware/client components or a misconfiguration of some sort...
Anyone here ever experienced this and can give me a hint if this is really a feature shortcome or if there are fixes available?
You may want to check through http://kb.pulsesecure.net/KB17794. This gives details on the types of Auto Configs (for proxies) that are supported by the SA components.
Hope it helps.
One of my clients enables a web proxy and sends the proxy.pac file in a login script.
My comment above was mean to indicate that, depending on client NoScript (or other) settings, it may not be executed. In my case, as 3rd party network support, I don't need access to the resources that it provides, so I don't let it run. This is something that you have to keep in mind if you allow non-domain-member machines to connect to your sslvpn....unless you have very complicated role-mapping rules.