Internet application not honouring Proxy PAC file

Mucker

8/28/24, 4:24 AM

We have an app (excel add-in) that is configured to get it's proxy settings from IE (WinInet). This is how most modern apps work these days, they just hook into your system/IE proxy settings and use them. IE settings are to use a PAC file script and works fine for all other apps without issue.

This app will work for several hours then it just breaks. The issue is very inconsistent. We used Wireshark to capture the network traffic and found that when it breaks it is because it is bypassing the proxy and trying to go direct. I have seen this sort of thing before, but it either works 100% or doesn't 100%. In this case, you can see in the network that the app IS using the proxy and working fine; then for some odd reason it decided to go direct.

Here is what I have observed and my thoughts:

Based on the above, my conclusion is that the app is the problem. However, the vendor claims that no other customer of theirs has this issue so they are refusing to look into it. I am inclined to believe them to be fair, because it is Oracle and they have told me that there are some massive enterprises using this.

In all my years in IT I have never seen this behaviour - where an app is trying to go direct to the Internet when it is configured to use a proxy/PAC file (assuming it is configured correctly of course).

When it works or fails, the URL it is going to is exactly the same – this rules out any specific rules in the PAC causing the issue
When it fails, before and after I can see successfully proxy connections to other URLs using other apps like IE – this rules out the proxy not being accessible at the time of the issue.
The PAC file is very simple are there are no rules to send any traffic “Direct”.
At one point, I thought that maybe the server which hosts the PAC file might not be accessible at the exact time the app tries to access the Internet. However, I ruled this out by the fact that other apps work fine at the time of this error. I also created a PowerShell script which constantly did a GET to retrieve the http status 200 when the error happened. This all came back fine which suggests no issues with the PAC file server.

Where I am going to look next is to investigate the process around what happens when the PAC file is downloaded. Does anyone know how to troubleshoot or enable logging for WinInet? I cannot find anything about this on the Internet.

0 + 9

proxy

internet-explorer

pac

Jan

8/28/24, 6:48 AM

Proxy is not worth it. Just go DIRECT if possible

Greg Askew

8/28/24, 9:18 AM

`my conclusion is that the app is the problem.` This is unlikely. What is "direct"? The application doesn't even know what that means. The proxy is a setting for the *web browser*. Additionally, Internet Explorer is no longer supported.

Mucker

8/28/24, 9:51 AM

@GregAskew, the app leverages something called WinInet (TLDR, it uses whatever is set in IE). Most modern apps these days can use this via the dotnet library. BTW, a proxy is NOT just for web browsers, it can be used for any app that be configured to use proxy and make http/s calls - so it can use it.

Greg Askew

8/28/24, 10:21 AM

Again, the 32-bit Excel plugin vendor is not likely to be the cause. It functions at the application layer, not the network layer. Focus on the obsolete end of life 32-bit Internet Explorer and the various interactions it has with the operating system. There's plenty of fertile territory, like eliminating domain policy, local policy, and creating a test system with as few distractions as possible to assist with isolation and symptom elaboration.

Mucker

8/28/24, 10:38 AM

I see where you are going Greg. I intially followed all of that. We have ruled out group policy, and we have created test accounts too. Bear in mind my point about that ALL other apps (IE included) do go through the proxy (I can see this from the network captures), and so does this add-in, for a time. If it was a group policy, it would consistenly work or not work, it would not be intermittent. Let's forget about IE, I can see you know your stuff, I mentioned this to dumb things down. To be more accurate, it is using the system proxy settings - This is most commonly configured IE, but it

Mucker

8/28/24, 10:40 AM

applies to most browsers, Edge and Chrome. Office doesn't have any settings itself for proxy settings as it uses the settings from the system/IE for this. So IE is not relevent in this topic, I only mentioned it because this where most people are familiar with inputting proxy settings for Windows. hope that clears it up.

Greg Askew

8/28/24, 12:32 PM

The proxy settings are stored in the registry. A simple and easy test would be to enable auditing of that location. On a normal system that location is not accessed often. For example, when a web browser is opened. Or when policy (if specified in policy) is applied. Very little access. Also the pac file, little access from the source specified in policy.(and it is cached). Should be easy to identify the registry setting being accessed at the point of failure, the value of that setting, correlated with policy environment debug logging. The setting is being accessed, and the value isn't there.

Greg Askew

8/28/24, 12:38 PM

It's possible that something is standing on the location of that setting or accessing the file that should be cached too often, and intermittently it fails, but even that is not something an Excel plugin vendor can speak to. That's just a bad design that needs a simple workaround.

Mucker

8/28/24, 10:52 PM

hi Greg, yes we have checkd all of that. Its just a normal web proxy. As I said, it does use the proxy, but suddenly then reverts to going direct (no proxy). I have no idea what would cause this to happen other than not being able to process the PAC file at that exact moment. As I said above though, the PAC file server is up at the time when this happpens. Anything else you can think to try?

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Internet application not honouring Proxy PAC file

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.