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

testing
squid
v7

(fdlqjk7tn8) #1

Version used: nethserver 7.3

Suppose the Nethserver host has:

  • IP address: 192.168.1.1. LAN IP subnet is 192.168.1.0/24
  • FQDN (set at install time or modified via the nethserver web admin interface): proxy.lan.example.com

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

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

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



    // eno1:192.168.1.0 green authenticated
    if (isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0"))
        return "PROXY 192.168.1.1:3128";


    // DEFAULT
    return "PROXY 192.168.1.1:3128";
}

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 http://proxy.lan.example.com/wpad.dat 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:

http://docs.nethserver.org/en/v7/web_proxy.html#authenticated-mode

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

Regards,


Clients do not recognize wpad.dat
Enable dns_v4_first on
Wpad.dat misformed due to wrong $smb
(Giacomo Sanchietti) #2

(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.


(Stefano Zamboni) #3

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


(Jeroen Visser) #4

…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.


(Giacomo Sanchietti) #5

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; 

(Giacomo Sanchietti) #6

Everything ready for QA: https://github.com/NethServer/dev/issues/5555

Thank you so much @fdlqjk7tn8


ERROR: Negotiate Authentication validating user
ERROR: Negotiate Authentication validating user
(Thorsten) #7

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


(Davide Principi) #8

PING :ping_pong:

This issue is still on testing :frowning: https://github.com/NethServer/dev/issues/5555

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:


(Markus Neuberger) #9

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.


(Giacomo Sanchietti) #10

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


(Davide Principi) #11

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.


(fdlqjk7tn8) #12

@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


(Giacomo Sanchietti) #13

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.


(Giacomo Sanchietti) #14

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