The absolute worst version I had of this was in China (and I think Korea as well).
I was troubleshooting an issue where a company's client computers which connected to the company VPN wouldn't have internet access post-connection.
The problem turned out to be that instead of sending a NXDOMAIN they'd return their ad server and then _always_ send back some JS to show ads.
The company network used PAC files (these are a piece of JS with a single FindProxyForURL() function) via an internal-only URI to steer most requests to our proxies, while keeping some internal.
The problem came about when clients would first start up the OS would attempt to access the internal-only URI before the VPN client finished connecting. In a normal network it'd get nothing and life would carry on. With this problematic ISP they'd get something that /should/ have been a PAC file, but because it was some other piece of JS without FindProxyForURL() it wouldn't work as a PAC file and thus the client wouldn't go to the proxy.
The expiration on this piece of JS was set to some absurd amount of time, so when the client would eventually try hitting our PAC file server again (happens every 20 minutes on Windows) it wouldn't get our file because it thought the garbage one from the ISP was newer. And the ISP updated their hijacking JS more frequently than we updated our PAC file.
There were two possible solutions to this. One, routinely touch the PAC file so it's date was newer than whatever the ISP put out. Or two, set up an external A record for the internal PAC server name to keep the hijacking from working. We went with the second.
I was troubleshooting an issue where a company's client computers which connected to the company VPN wouldn't have internet access post-connection.
The problem turned out to be that instead of sending a NXDOMAIN they'd return their ad server and then _always_ send back some JS to show ads.
The company network used PAC files (these are a piece of JS with a single FindProxyForURL() function) via an internal-only URI to steer most requests to our proxies, while keeping some internal.
The problem came about when clients would first start up the OS would attempt to access the internal-only URI before the VPN client finished connecting. In a normal network it'd get nothing and life would carry on. With this problematic ISP they'd get something that /should/ have been a PAC file, but because it was some other piece of JS without FindProxyForURL() it wouldn't work as a PAC file and thus the client wouldn't go to the proxy.
The expiration on this piece of JS was set to some absurd amount of time, so when the client would eventually try hitting our PAC file server again (happens every 20 minutes on Windows) it wouldn't get our file because it thought the garbage one from the ISP was newer. And the ISP updated their hijacking JS more frequently than we updated our PAC file.
There were two possible solutions to this. One, routinely touch the PAC file so it's date was newer than whatever the ISP put out. Or two, set up an external A record for the internal PAC server name to keep the hijacking from working. We went with the second.