When you consider the proxy settings as part of your overall network design - e.g. in a DMZ / firewall / access control context, you'd expect proxy settings to be managed through network services such as dns and dhcp. So, how do we include proxy settings here?

PAC

PAC, Proxy Auto Configuration, is based on a javascript function that takes the requested URL by the browser, processes it, and returns instructions to the browser on where to get the requested web page (or any other file). The javascript in question is called the "pac" file, and lives on a web server. Obviously, to implement Proxy Auto Configuration on a local network in order to manage the use of your local proxy server, you need to run a web server alongside your proxy server(s).

Here's a sample pac file. The function FindProxyForURL(url, host) is the main component of the script. It can simply return a proxy server for any and all requests, or you can use variables and the usual control structures (case, if .. then .. else, ...) to diversify and customize.

function FindProxyForURL(url, host) { return "PROXY proxy.foo.com:8080; DIRECT"; }

PAC allows you to centrally manage the proxying (i.e. which proxy to use, and how), but still requires you to set up each client to use the appropriate Automatic Proxy Configuration URL.

WPAD

WPAD, Web Proxy Automatic Discovery, extends the PAC mechanism by providing the Automatic Proxy Configuration URL through standard network services such as dns and dhcp. This means that a client can receive its proxy settings the same way it's getting other network settings (IP address, default gateway, DNS and/or WINS servers, ...) : through dhcp.

The client receives the url to this wpad script through dhcp option 252. Your browser needs to be configured to use proxy auto-discovery ! you still need to configure clients once.

Notes

By convention, the PAC file is normally named proxy.pac. The WPAD standard uses wpad.dat.
Windows Server 2008, Microsoft DNS server blocks request for the (address of a) wpad host.
Firefox does not support WPAD via dhcp, only via DNS (apart from plain "PAC").

DNS-based WPAD

To set up DNS-based WPAD, your DNS server needs to have a DNS entry for a host named WPAD, which is the web server where the wpad script lives. The other requirements (web server, document root, mime type, ...) still apply - you just don't need the dhcp option 252.

Transparent Proxy

pac and wpad only work for clients/applications who are susceptible to it - web browsers, yes, but what about other applications ?

set http_proxy=http://proxy.mydomain.com:8080/
or to deali with it on the network (TCP/IP) level : using packet filtering and routing

Socks

Socks is a network/application protocol for a transparent, multi-application proxy server, which can proxy (just about) any application, and can thus be used to manage access to remote servers through a firewall.

Tutorials

Web Proxy Autodiscovery Protocol with dnsmasq

http://ebalaskas.gr/blog/2014/08/29/web-proxy-autodiscovery-protocol-with-dnsmasq/

Posted by ebal at 10:15:18 in planet_ellak, planet_Sysadmin

It seems that you can push a WPAD to desktops via dhcp.

My proxy is based on squid running on 8080.

I ‘ve build a WPAD file similar to the below:

wpad.dat

function FindProxyForURL(url, host)
{
return "PROXY 192.168.1.2:8080; DIRECT";
}

next thing is to publish it via a web server.

I am using thttpd for static pages/files:

how to test it:

# curl -L 192.168.1.2/wpad.dat

after that a simple entry on Dnsmasq

dhcp-option=252,"http://192.168.1.2/wpad.dat"

and restart your dnsmasq

Dont forget to do a dhcp release on your windows machine

Tag(s): dnsmasq, squid, WPAD

Setting up WPAD with DHCP

https://gist.github.com/wen-long/6020543

a wpad file. This is the same javascript file as the pac file, renamed (or symlinked) to wpad.dat
a web server to host the wpad.dat script. The wpad script needs to be located in the document root of the http server
the web server must be configured for .dat files with a MIME type of "application/x-ns-proxy-autoconfig"
a dhcp server, configured with option 252 = "http://your.server.here/wpad.dat"

Setting up Web Proxy Autodiscovery Protocol (WPAD) using DNS

http://tektab.com/2012/09/26/setting-up-web-proxy-autodiscovery-protocol-wpad-using-dns/

by Saad Faruque

In order to use the DNS only method to setup Web Proxy Autodiscovery Protocol (WPAD) you need to check on the following

To use WPAD using DNS method a DNS entry is needed for a host named WPAD. This name should be resolvable from the clients machine. If your domain name is example.com, the client machine should be able to resolve your web servers IP address looking up wpad.example.com.
Web server must be configured to serve the WPAD file with a MIME type of “application/x-ns-proxy-autoconfig”
A file named wpad.dat must be located in the WPAD Web server’s root directory.
The host at the WPAD address must be able to serve a Web page.

So if you are a member of example.com domain the browser is looking for this url for the PAC file http://wpad.example.com/wpad.dat

Manually Setting up client browser to use Web Proxy Autodiscovery Protocol (WPAD)

Firefox

Option -> network -> Settings

Select “auto-detect proxy setting for this network”

Firefox, connection setting, Auto-detect proxy settings for this network, WPAD, auto detect, proxy

Chrome

Settings -> show advanced settings (at the bottom) -> Change proxy settings

Under connections tab click on LAN settings

Enable “automatically detect settings” (disable all other option)

Local Aria Network (LAN) Settings, local area network setting, ie, automatically detect settings, wpad, proxy autodetect

IE

Tools -> internet option -> connection -> LAN setting

Enable “automatically detect settings” (disable all other option)

Local Aria Network (LAN) Settings, local area network setting, ie, automatically detect settings, wpad, proxy autodetect

Check if the traffic is going through proxy

In my setup I have been using squid as a proxy, so I monitor for “tail -f /var/log/squid/access.log” and check for traffic request from the client. Make sure any transparent proxy configuration is turned off to avoid wrong reading.

Please share if you know of any other way to check from the client side.

If your traffic is passing through the proxy server, congratulations you have successfully configured automatic proxy configuration server with a PAC file.

Automatic Proxy Configuration

http://users.telenet.be/mydotcom/library/network/pac.htm

Manage proxy settings remotely and dynamically

The problem

When you're dealing with automatic system configuration and hands-free system administration in a managed environment, you may find that there's this one item that's hard to deal with : Proxy servers.

Some web browsers provide tools for hands-free configuration. For Internet Explorer, there are IE Administration Resource Kits. Internet Explorer's proxy settings can also be managed with Policies, usually Group Policy Objects in a Active Directory environment. Firefox can be configured remotely with 'Mission Control", a.k.a. AutoConfig.

However, when you consider the proxy settings as part of your overall network design - e.g. in a DMZ / firewall / access control context, you'd expect proxy settings to be managed through network services such as dns and dhcp. These are, after all, your tools to manage your network : dynamic host configuration. So, how do we include proxy settings here ?

PAC : Proxy Auto Configuration

Proxy Auto Configuration is based on a javascript function that takes the requested URL by the browser, processes it, and returns instructions to the browser on where to get the requested web page (or any other file) : directly from the web server in question, or through a given proxy.

The javascript in question is called the "pac" file, and lives on a web server. Therefore, the browsers need to be configured to use an "automatic proxy configuration script", by providing the url to the proxy script in the web browser's settings (eg Firefox : Preferences : Connection Settings : Automatic Proxy Configuration URL ). Obviously, to implement Proxy Auto Configuration on a local network in order to manage the use of your local proxy server, you need to run a web server alongside your proxy server(s). This server needs to associate the .pac extension with MIME type "application/x-ns-proxy-autoconfig".

function FindProxyForURL(url, host) { return "PROXY proxy.foo.com:8080; DIRECT"; }

PAC allows you to centrally manage the proxying (i.e. which proxy to use, and how), but still requires you to set up each client to use the appropriate Automatic Proxy Configuration URL. Once set up, it does allow central management : you can modify the pac script (on the web server) to change all the clients' behavior.

WPAD : Web Proxy Automatic Discovery

WPAD extends the PAC mechanism by providing the Automatic Proxy Configuration URL through standard network services such as dns and dhcp. This means that a client can receive its proxy settings the same way it's getting other network settings (IP address, default gateway, DNS and/or WINS servers, ...) : through dhcp - it's getting interesting now.

Wpad can work through dhcp, which is the recommended solution. As with pac, you need a wpad file on a web server. The client receives the url to this wpad script through dhcp option 252. To set this up, you need :

a wpad file. This is the same javascript file as the pac file, renamed (or symlinked) to wpad.dat
a web server to host the wpad.dat script. The wpad script needs to be located in the document root of the http server
the web server must be configured for .dat files with a MIME type of "application/x-ns-proxy-autoconfig"
a dhcp server, configured with option 252 = "http://your.server.here/wpad.dat"

Your browser needs to be configured to use proxy auto-discovery ! This kinda defeats the purpose : you still need to configure clients (once). This can be done during the initial baseline setup. The advantage over PAC is that with WPAD, the location of the wpad file is transparent to the clients : if you decide to move it to another server (or rename the server), all you need to do is adjust the path in the dhcp option, instead of setting a new auto-configuration url on all clients. It can also be used to accommodate roaming users / laptops : they will get proxy settings relevant to the network the connect to (and get their dhcp settings from).

One caveat: Microsoft's Internet Explorer version 6.01 expects the string in option 252 to be NUL-terminated. As such, it unconditionally strips off the final character of the string before using it. Earlier versions of Microsoft's Internet Explorer do not do this. To satisfy all versions, simply explicitly include a NUL (\0)as the last octet of the string.

WPAD can work without dhcp. In this case, the client tries to derive the WPAD URL from its own DNS hostname, and just tries any probable solution. Therefore, a client set up to use wpad while no wpad file is available on your network, may end up using just any wpad file (and thus any proxy server) on any network. This opens doors to all sorts of browser hijacks and other security issues (see also wpad.com).

To avoid this attack vector, starting with Windows Server 2008, Microsoft DNS server blocks request for the (address of a) wpad host. You can see this when you run dnscmd dnsservername /info globalqueryblocklist . To undo it, reset de block list to only include istapi : dnscmd dnsservername /config /globalqueryblocklist isatap . This setting doesn't propagate to other dns servers: you need to run this on all your dns servers.

As it happens, Firefox does not support WPAD via dhcp, only via DNS (apart from plain "PAC"). So on a network with Windows DNS servers, Firefox won't be able to do web proxy auto-discovery without the fixes shown just before.

Configuration examples

sample Apache wpad setup

        ## ?? /etc/apache2/conf/mime.types
        text/html                                 html htm
        application/x-ns-proxy-autoconfig        dat

        ## ?? /etc/apache2/httpd.conf
        AddType application/x-ns-proxy-autoconfig .dat

sample lighttpd wpad setup

        ## /etc/lighttpd/lighttpd.conf
        mimetype.assign = (
                 ".html" => "text/html",
                        ".txt" => "text/plain",
                        ".wpad" => "application/x-ns-proxy-autoconfig",
                        [...]
        )
        [...]

sample dhcp3d wpad setup

        ## ?? /etc/dhcp3d/dhcp3d.conf
        subnet 123.123.123.123 {
                [...]

                option custom-proxy-server "http://your.server.here/wpad.dat";

                }

Alternative solutions - see which one works for you ...

option option-252 "http://wpad.host.co.nz/proxy.pac";

or even

        ## in the global section of your configuration:
                option wpad-url code 252 = text;                  ##(defines a new option)

        ## in either the global or appropriate subnet section(s) of your configuration:

                option wpad-url "http://wpad.my.domain.tld/proxy.pac\n"; ##(applies new option)

set option 252 on Microsoft Windows DHCP server

right click on the server and click "Set predefined options" to add 252 as a String value (it's not in there by default. SeeMS KB 252898 for more.) Then insert the wpad url value. This adds the option 252 proxy-auto-config to the list of available dhcp options. You can now enable the option in the server or scope option dropdown list.

Note re. dhcp configuration : You might want to try using an IP address instead of hostnames; apparently, DNS lookups don't always work.

Note re Internet Explorer clients : It seems that (some versions of) IE eat the last character of the URL given in option 252, because it assumes the last character is an EOL and can be disposed of. You have to append a space there (or any other character such as \n or \0) to get it working.

sample dnsmasq wpad setup

        ## dnsmasq is a combined dns and dhcp server
        ##         /etc/dnsmasq.conf
        dhcp-option=252,http://your.server.here/wpad.dat

Sample DNS config for DNS-based wpad

        ## Add all or some of the following entries to your DNS zone file.
        wpad IN A 192.168.0.254
          IN TXT "service: wpad:!http://wpad.host.co.nz:80/wpad.dat"
        wpad.tcp IN SRV 0 0 80 wpad.host.co.nz.

sample wpad file

        // proxy configuration script for wpad

        function FindProxyForURL(url, host) {
                // variables
         var ProxyAddress = "192.168.123.123"
         var ProxyPort = "3128"
         var strProxy = "PROXY " & ProxyAddress & ":" & ProxyPort

         var localnet = "192.168.123.0"
         var localmask = "255.255.255.0"
         var localdomain = "kicks.xx"

         var dmznet = ""
         var dmzmask = ""

                 // local addresses / urls with subdomains of localdomain don't need proxy
                if (shExpMatch(url,"*." & localdomain & " /*"))         {return "DIRECT";}
                if (shExpMatch(url, "*." & localdomain & ":*/*")) {return "DIRECT";}

                // local and DMZ addresses go DIRECTly
                if (isInNet(host, localnet, localmask) || (isInNet(host, dmznet, dmzmask)){
                  return "DIRECT";
                }

                 // All other http requests go through proxy - can be adapted for other protocols
                  //         fallback ; go DIRECTly to the WWW if proxy doesn't respond
                //                        (will be limited by firewall web access rules if any)

                if (url.substring(0, 5) == "http:") {return strProxy & " ; DIRECT"; }

                 // catch all ; go directly to the WWW (will be limited by firewall web access rules if any)
                return "DIRECT";
         }

Transparent Proxy

pac and wpad only work for clients/applications who are susceptible to it - web browsers, yes, but what about other applications ? Think outside the box : look for alternative solutions that provide equally good opportunities for dynamic, centralized remote/hands-free system and network administration. Eg: for apt, the http/ftp software download and install tool on Debian Linux systems, there's apt-proxy. Network applications started from a Linux console can also get proxy settings from the user profile, eg.

        ## /etc/profile - systemwide user profile

        http_proxy=http://proxy.mydomain.com:8080/
        https_proxy=https://proxy.mydomain.com:8080/

        export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC http_proxy https_proxy

Yet another way of dealing with this problem is on the network (TCP/IP) level : using packet filtering and routing, you can intercept packets with a given destination port (eg 80: http) and redirect/reroute them to the ipaddress:portnumber of your proxy server, which then should fetch the required data, and send them back to the client. In this approach, the client is not configured to use a proxy, and is unaware of the redirection. This can be accomplished with eg. iptables (packet filtering and redirection) and squid (proxy server). You need to configure squid to specifically deal with this sort of redirected requests.

Needs a closer look. Start here: Transparent Proxy HOWTO

Socks

Socks is a network/application protocol for a transparent, multi-application proxy server. Most proxy-servers are application-specific, eg Squid : http and ftp proxy, ...; SOCKS can proxy (just about) any application, and can thus be used to manage access to remote servers through a firewall.

A SOCKS server can be used in combination with WPAD : WPAD scripts can return "SOCKS" (in stead of "DIRECT" or a proxy-url).