Proxy (Auto-)Configuration Blues
I got seriously fed up with switching proxy settings when switching location of my laptop between company, home and client/partner networks. For some reason or another automatic configuration would not work everywhere, so I decided to write my own PAC (proxy autoconfiguration) script.
The authoritative reference documentation for PAC scripts by Netscape was easily found by googling for "proxy autoconfiguration script" (Interestingly, the same search on MSN did not even return this URL on the first page of search results). A PAC script is nothing more a bit of JavaScript code that must define a FindProxyForURL function.
My initial script looked like this:
If current IP address of machine is in the company intranet subnet, use the proxies that provide internet access from the intranet (company network scenario), otherwise assume direct access is possible (home network scenario).
Unfortunately this script did not work straight away. Writing it was pretty easy, debugging not. An old MIND article provided some help in this area. Attaching a debugger to Internet Explorer didn't seem to work for me - the auto configuration script block didn't show up in the Running Documents. JavaScript alerts in the PAC file helped highlight the problem however (IE6 shows the alerts in popup windows, Firefox writes the alerts to its JavaScript console). It turned out that the myIpAddress function returned the IP Address of a loopback adapter (installed for more complex VirtualPC networking scenarios) instead of the IP Address of the Ethernet adapter connected to the LAN.
Credits to Oliver Presland (Microsoft UK) for pointing out that this problem could be tackled by changing the priority of the network connections. Something that is much more obscure now (open Network Connections applet from Control Panel, Advanced/Advanced Settings... menu, Adapters & Bindings tab, Connections list) than it was in NT4 days. Once the LAN adapter had top priority, the PAC script worked as intended both in the office and at home. That is, until I set up a VPN connection to the company intranet...
The VPN software creates a temporary network adapter that gets an IP address in the company intranet subnet and always seems to claim top connection priority. The result was that once a VPN connection had been setup, all internet traffic would be routed via the company intranet and its proxies. To prevent unnecessary use of company resources I adjusted the PAC script:
This seems to have done the trick. Update: Only problem now is that resolving host names that cannot be found takes an awful long time. Using subnet tests only is a lot faster, so I will do a bit more work to find out which company subnets are used for VPN clients and which are used for company LAN clients.
The authoritative reference documentation for PAC scripts by Netscape was easily found by googling for "proxy autoconfiguration script" (Interestingly, the same search on MSN did not even return this URL on the first page of search results). A PAC script is nothing more a bit of JavaScript code that must define a FindProxyForURL function.
My initial script looked like this:
function FindProxyForURL(url, host) { if(isInNet(myIpAddress(), "158.234.0.0", "255.255.0.0")) { // Connected to company intranet return "PROXY proxy1.intra.example.org:80; PROXY proxy2.intra.example.org:80 } return "DIRECT"; }
If current IP address of machine is in the company intranet subnet, use the proxies that provide internet access from the intranet (company network scenario), otherwise assume direct access is possible (home network scenario).
Unfortunately this script did not work straight away. Writing it was pretty easy, debugging not. An old MIND article provided some help in this area. Attaching a debugger to Internet Explorer didn't seem to work for me - the auto configuration script block didn't show up in the Running Documents. JavaScript alerts in the PAC file helped highlight the problem however (IE6 shows the alerts in popup windows, Firefox writes the alerts to its JavaScript console). It turned out that the myIpAddress function returned the IP Address of a loopback adapter (installed for more complex VirtualPC networking scenarios) instead of the IP Address of the Ethernet adapter connected to the LAN.
Credits to Oliver Presland (Microsoft UK) for pointing out that this problem could be tackled by changing the priority of the network connections. Something that is much more obscure now (open Network Connections applet from Control Panel, Advanced/Advanced Settings... menu, Adapters & Bindings tab, Connections list) than it was in NT4 days. Once the LAN adapter had top priority, the PAC script worked as intended both in the office and at home. That is, until I set up a VPN connection to the company intranet...
The VPN software creates a temporary network adapter that gets an IP address in the company intranet subnet and always seems to claim top connection priority. The result was that once a VPN connection had been setup, all internet traffic would be routed via the company intranet and its proxies. To prevent unnecessary use of company resources I adjusted the PAC script:
function FindProxyForURL(url, host) { if (isResolvable("myhomepc")) { // Can resolve DNS queries without proxy return "DIRECT"; } else if(isInNet(myIpAddress(), "158.234.0.0", "255.255.0.0")) { // Connected to company intranet return "PROXY proxy1.intra.example.org:80; PROXY proxy2.intra.example.org:80"; } return "DIRECT"; }
This seems to have done the trick. Update: Only problem now is that resolving host names that cannot be found takes an awful long time. Using subnet tests only is a lot faster, so I will do a bit more work to find out which company subnets are used for VPN clients and which are used for company LAN clients.
3 Comments:
What I found is that instead of using the myIpAddress function, I used the name that my machine appeared as on the local network.
So in my case my computer is called 'mylaptop.mycompany.com' on the company network. This can only be resolved while on the company network.
So isInNet('mybox.mycompany.com','192.168.10.0','255.255.255.0')
does the right thing only when I'm at work.
Hi,
I had the same problem and came up with a script like your first one.
I understand that a VPN client forces all network traffic to the VPN server, at least in my case. So why not use the proxy at the workplace for all internet connections.
I had no problems even with if I connected with my VPN connection.
Post a Comment
<< Home