Non-transparent proxy: WPAD file contains IP address of Nethserver server, should be FQDN

Version used: nethserver 7.3

Suppose the Nethserver host has:

  • IP address: LAN IP subnet is
  • FQDN (set at install time or modified via the nethserver web admin interface):

Nethserver 7.3 creates this wpad.dat file on /var/www/html/:

function FindProxyForURL(url, host)
    // Direct access to localhost
    if (isInNet(host, "", ""))
        return "DIRECT";

    // Direct access to local hosts
    if (isPlainHostName(host))
        return "DIRECT";

    // eno1: green authenticated
    if (isInNet(myIpAddress(), "", ""))
        return "PROXY";

    // DEFAULT
    return "PROXY";

Notice it uses PROXY return values containing the server LAN IP address.

When a user whose workstation web browser has been configured (in a way or another) to use as a proxy auto configuration script then he/she is:

  • Presented a proxy authentication dialog
  • The credentials, even when correctly entered, aren’t accepted

The /var/log/squid/cache.log log file records:

2017/06/12 11:19:50 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}

Which indicates the browser is trying to negotiate NTLM (which is unsupported by Nethserver’s Squid as of Netherver 7.x) instead of Kerberos.

The switching or fallback to NTLM by the browser is caused by the fact that the proxy specification sent by the WPAD file is a IP address.

This contradicts Nethserver own documentation:

If I modify the wpad.dat file and set the PROXY lines to return proxy things start to work. But, as you know, this will only work until Nethserver overwrites it automatically at some point.



(Sorry I completely missed this thread :frowning:)
Thank you for reporting and writing down an excellent issue!

I fear the proposed solution will not work on many installation where the FQDN of the machine is not the one used by LAN clients to access the gateway itself.
From my experience, I could say that more than 50% of installations have a bad FQDN on firewalls.

We should find a solution which fit any usage scenarios without breaking existing installations.

I disagree… if the environment is misconfigured (and proper use of DNS in lan is a must nowadays) it’s not a NS issue.
user must be informed how things are supposed to work and helped in configuring them accordingly

1 Like

…that is technically a configuration error and not something to cater too much to. An attention dialogue would be nice, but breaking proper setups by assuming simplified use-cases is probably not the best idea. Maybe offer the simplified setup, but also offer an advanced setup, which assumes best practices being followed.


The PAC specification allow multiple PROXY directives.

Inside the pull request discussion, I suggested to output something like:

PROXY <FQDN>:3128; PROXY <IP_GREEN>:3128; PROXY <IP_BLUE>:3128; 

Everything ready for QA:

Thank you so much @fdlqjk7tn8

1 Like

Hi, I am not sure, but I found a vice versa bug / posting …


PING :ping_pong:

This issue is still on testing :frowning:

I know @davide_marini would love to check it out, but I know he’s quite busy. Does anyone want to chime in?

Yes it seems a similar bug in ns 6.7 :thinking:

Both test cases worked for me :+1:

For the second test case I changed my local hosts file to resolve somename.somedomain to my gateway IP.
After setting automatic proxy settings to “http://somename.somedomain/wpad.dat” proxy is still working in kerberos mode. Tested with Chrome, Firefox and Edge.


It seems that there is no simple solution.

We propose to add a new prop WpadFqdn to force the FQDN on the wpad file, if the prop is disabled (default) the wpad will use only ip address as before.

@fdlqjk7tn8 what do you think?

Edit: otherwise we could force to use FQDN id the server is joined to an AD (local or remote), otherwise always use the IP address.
Could this change break any existing installation?

/cc @davidep @davide_marini


Yes it could do. I think we need the prop to preserve old installations and introduce a new default in the future:

  1. WpadFqdn=no, today: to retain backward compatibility
  2. WpadFqdn=auto, future default for new installations: depends on accounts provider type
  3. WpadFqdn=yes, always use FQDN in WPAD file

We can reduce it to a boolean value though: case 2+3 could be collapsed together.


@giacomo @davidep

I humbly agree with your last proposal. It could help in the two scenarios: Full AD integration with Kerberos auth and customers with a working albeit slightly wrong setup.

Edit: typo


We don’t have much time right now for such modification and the testing requires a lot of time to avoid regressions.

@fdlqjk7tn8 do you want try to implement it?
Otherwise I’m willing to revert the modification and close the issue as wantfix for now.

I’m closing the issue as wantfix for now.
Feel free to open a new issue with the new implementation.

1 Like

Has anyone came up with a new implementation?

I think the use of a prop, as @davidep stated here, will solve the problem.

I’m currently looking at the code inside /etc/e-smith/templates/var/www/html/wpad.dat and at first glance, it seems to me that refactoring the code inside 70proxyMode and 90proxyDefault is the way to go.

Can I get some help?

I guess the modification should be there, but I didn’t check carefully.
Probably you need a fragment like 00vars which setup the variable to use in the later fragments (this is just an idea).
What help do you need? Feel free to ask :slight_smile:

1 Like

Okay, I think this implementation addresses the problem correctly. I created the following files:

By setting the property WpadFqdn=yes you get the wpad.dat file to use FQDN instead of IP address. This can be done with this

db configuration setprop squid WpadFqdn yes

This ensure that Active Directory Windows machines can use MS Edge, MS Internet Explorer, Chrome, Windows Updates and so on.