HOWTO - Setup working wpad.dat with web gui on alternative port

Started by hbc, March 13, 2019, 10:47:09 AM

Previous topic - Next topic
I followed all the steps of the howto, but wpad does not work ,some form of debug I can do, to see where the error may be


What happens if you type in browser "http://firewall-ip/wpad.dat"? Does it download wpad.dat?

Can you telnet to firewall-ip port 80? Port open? Did you create a wpad.dat file via webproxy menu? Does it exist as /usr/local/www/wpad.dat?

What say log files. You have to analyze more analytic. Just saying it dos not work, it not much help.
Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz (24 cores)
256 GB RAM, 300GB RAID1, 3x4 10G Chelsio T540-CO-SR

Hi , I did the three different tests:

1 - telnet ip lan firewall port 80 successful

2 -  download wpad.dat successful

3 - the file exists in the path, but the configuration inside does not show anything

I did a packet inspection with wireshark and I see that the dhcp is not serving the wpad.

I attach images.

Quote3 - the file exists in the path, but the configuration inside does not show anything
Did you create matches, proxies and rules for wpad in webproxy configuration? Also very important: the wpad.dat is only written to disk, when you click save in any other webproxy tab.
Maybe they should add an apply button to pac tab, to just write wpad.dat to disk.

Not every system supports dhcp. It's also important to as the wpad dns entries. Do a tcpdump on port 53/udp and check requests for hostnames starting with wpad
Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz (24 cores)
256 GB RAM, 300GB RAID1, 3x4 10G Chelsio T540-CO-SR

it's strange, but I can not get it to surf, I see that the dhcp is serving the wpad and the dns too, take a look at my screenshot.


So wpad is delivered, but proxy not used? Seems to be wrong logic in wpad.dat for proxy selection.

I would check 3 things:


  • Browsers have auto proxy detection enabled
  • nginx access log for download access of wpad.dat
  • functionality of wpad.dat
Most browsers allow to set the url for proxy auto configuration statically. Enter your url to wpad.dat manually and check whether proxy is selected like you intended. If not, you have a wrong logic.
Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz (24 cores)
256 GB RAM, 300GB RAID1, 3x4 10G Chelsio T540-CO-SR

2: test it using curl http://wpad.example.com/wpad.dat
3: test you can test that using node.js (basic syntax test, in theory also if the file is working)

if those are fine, the PAC file may not be used.


Quote from: ssbarnea on April 14, 2019, 04:39:22 PM
One related issue that I found is that if you disable redirection from 80->443 you lose the ability to load wpad from HTTP. See https://github.com/opnsense/core/issues/3416
This issue could be solved by omitting https redirects for wpad.dat file.

To have the WeBGUI being redirected to port 443 and wpad.dat file being accessible via port 80 and port 443 simultaneously the redirect expression in the webgui configuration script /usr/local/etc/inc/plugins.inc.d/webgui.inc has to omit https redirects for wpad.dat file.

According to lighttpd mod_redirect documentation (https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModRedirect) short-circuiting the redirect rules without triggering a redirect is possible by specifying a blank target.

Hence, the redirect expression in the webgui configuration script /usr/local/etc/inc/plugins.inc.d/webgui.inc should be amended as follows:

    /* add HTTP to HTTPS redirect */
    if (
        $config['system']['webgui']['protocol'] == 'https' &&
        !isset($config['system']['webgui']['disablehttpredirect'])
    ) {
        $redirectport = $lighty_port != "443" ? ":{$lighty_port}" : '';
        foreach ($listeners as $listener) {
            if (is_ipaddrv6($listener)) {
                $listener = "[{$listener}]";
            }
            $lighty_config .= <<<EOD

\$SERVER["socket"] == "{$listener}:80" {
    \$HTTP["host"] =~ "(.*)" {
        url.redirect = ( "^/wpad.dat" => "" ,
                         "^/(.*)" => "https://%1{$redirectport}/$1" )
    }
}


I would be more than happy if the developers would take this change into consideration.

Hi,

I've a similar issue.

I've the wpad.dat


admin@OPNsense:/tmp % cat /usr/local/www/wpad.dat
/*
  PAC file created via OPNsense
  To use this file you have to enter its URL into your browsers network settings.
*/
function FindProxyForURL(url, host) {




if (((!isPlainHostName(host)) && (!shExpMatch(host, "*.home.lan")))) {
return "PROXY 192.168.1.1:3128";
}

   // If no rule exists - use a direct connection
   return "DIRECT";
}


but


curl --header "X-Forwarded-For: other.net"  -I 192.168.1.1/wpad.dat
HTTP/1.1 301 Moved Permanently
Location: https://192.168.1.1/wpad.dat
Date: Sat, 13 Jun 2020 18:57:44 GMT
Server: OPNsense


failed.


$ dig -t txt  opnsense

; <<>> DiG 9.11.19-RedHat-9.11.19-1.fc31 <<>> -t txt opnsense
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29865
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;opnsense. IN TXT

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sa Jun 13 21:12:17 CEST 2020
;; MSG SIZE  rcvd: 37


also doesn't show any TXT entries. Even I've checked the WPAD boxes for DHCP, unbind and did reboot.

Firefox is configured for auto detection, I didn't use transparent proxy and HTTPS yet. I'm testing squid/C-ICAP/clamav combo basically where I faced this problem. Does it really work only in transparent mode using rules?

You need to deliver it via HTTP as well. In your case you get a 302 because you are redirected to the HTTPS port.

Quote from: fabian on June 13, 2020, 10:22:26 PM
You need to deliver it via HTTP as well. In your case you get a 302 because you are redirected to the HTTPS port.

thanks. Even after some investiagting I have to use the https proxy. The logs shows only my Fedora WLAN check (http://fedoraproject.org/static/hotspot.txt) is using HTTP :(

Does applying ACME LetsEncrypt certificate simplify the use of, e.g. transparent proxy, since no self-signed certs are required to be distributed?

They cannot be used for the proxy since you need a CA certificate