URL filter not working

Network Web Proxy, URL Filter & Update Accelerator
1

Good morning everyone,

I am currently experiencing a configuration anomaly that I am unable to properly interpret.

Recently, I decided to perform a complete upgrade of my home infrastructure. To ensure greater consistency and a cleaner configuration, I opted for a fresh installation of the system, avoiding the restoration of any existing backups. This decision was driven by the need to remove legacy configurations accumulated over time that are no longer necessary, as well as to improve the overall maintainability of the environment.

During the reconfiguration phase, I implemented the URL filtering service, with particular focus on HTTPS traffic inspection. To achieve this, I carefully followed the official documentation available at the following link:

Specifically, I configured the WPAD (Web Proxy Auto-Discovery Protocol) mechanism to allow network clients to automatically detect proxy settings and apply filtering policies, including for encrypted connections.

However, despite strictly following all the steps outlined in the guide (including the configuration of the wpad.dat file, DHCP/DNS options, and proxy parameters), the observed behavior is not as expected: the system does not seem to correctly apply filtering when the configuration is distributed automatically.

To rule out client-side issues, I performed tests by manually configuring the proxy settings within applications. In this scenario, filtering works correctly, including HTTPS traffic handling. This suggests that the issue is likely confined to the auto-discovery process or the configuration distribution mechanism.

At this point, I am unable to precisely identify where the problem might lie (WPAD configuration, DNS resolution, DHCP options, or another component in the chain).

Do you have any suggestions on which components or logs I should analyze to isolate the root cause of the issue?

2

one thing I noticed and I think it’s the problem is that if I click on the open pac file link located on the proxy page it doesn’t download anything, but it just stays there spinning

3

If your clients are Windows, check if you have correctly declared the wpad CNAME in hosts.

image
image1007Ă—530 18.3 KB

Check if the client is getting http://wpad/wpad.dat and then http://wpad.<IPFirelocaldomain>/wpad.dat

4

If you are using Firefox, that is because by default these days it will not download a file from an http url, although that may depend on your Firefox settings.

On my Firefox if i try and download it a window is show that says “File not downloaded: Potential security risk”, although on my system, it actually did download the file to the Downloads directory but would not open it.

If you click on the download manager icon it will show if that was the case. Click on that entry and it will open a window giving you the option to Remove file or Open.

If you click the Open button it will then give you the option to open it with a text editor etc.

5

the host part is configured and if I try the two links you suggested it doesn’t download anything

host
host1041Ă—264 36.4 KB

6

Yes, Adolf, I use Firefox, but I also tried Edge.
In my case, it doesn’t download anything, as if it were supposed to download something, but it doesn’t download anything, and after 5-10 minutes it tells me the URL is unreachable.

7

Could you please show a screenshot of the Additional DHCP options section of your dhcp server wui page.

8

Then we need to solve that because the browser will be using that url to access the wpad file.

The section in the dhcp server wui page might giva a clue to that but I will try and think what else might cause that link to not be downloaded at all.

9

Can you confirm that the file proxy.pac exists in /srv/web/ipfire/html/ and that in the same directory there is wpad.dat linked to proxy.pac

the proxy.pac should have ownership nobody:nobody and permissions 644.

If they are both present can you check if you can do a less command on both the proxy.pac file and the link file wpad.dat.

10

I found the problem, at least I think.
I had written an incorrect string in the Additional DHCP options section of DHCP,
but even after restarting the proxy and Apache,
I had to reboot the machine, and now it works.