Skip to content

WPAD Quick Setup Guide

About this Document

In this document, we provide a quick overview of the steps required to configure WPAD with AXS Guard. HTTPS inspection is not covered by this document; see the Web Access manual on this site for more information about HTTPS inspection, a.k.a. SSL inspection.

Features, Services and Firewall Configuration

To use WPAD, which is a web access component, the corresponding services must be activated and running. Go to System > Feature Activation > Web Access to verify if the following features are activated:

  • AXS Guard HTTP Accelerating Proxy
  • AXS Guard Web Content Scanner

These services must be in a running state and be accessible to your clients. The AXS Guard proxy server listens on TCP port 3128. The AXS Guard firewall automatically opens this port for you when the features are activated; no additional steps are required.

The sec-proxy rule will be added to the stat-sec firewall policy. To verify your firewall configuration, go to Firewall > Policies > Static and click on stat-sec.

WPAD, DHCP and DNS

WPAD

The Web Proxy Auto-Discovery or WPAD protocol is a method that allows clients in a network to automatically discover a designated proxy server. The proxy server acts as a web filter, provides shared network connections and caches data to speed up web requests.

DHCP & Option 252

Option 252 provides a WPAD URL to DHCP clients, allowing them to automatically configure their proxy settings. Option 252 is defined in draft-ietf-wrec-wpad-01.

When a DHCP client has been configured for automatic proxy detection, it will check for DHCP option 252 by default, which is why we recommend you add it to your DHCP server's configuration on AXS Guard.

If you are using a Windows DHCP server, please consult the adequate Microsoft documentation in order to add this option.

DNS

When DHCP option 252 cannot be used in your network environment, e.g. when using static IP addresses on devices where automatic proxy detection has been configured, the devices will attempt to automatically configure their proxy settings via DNS.

The client will first try to resolve wpad.your.domain. If it succeeds, it will try to retrieve the wpad.dat file from that location.

If the client fails to resolve wpad.your.domain, it will try to resolve wpad.your and then wpad until it is able to find a wpad.dat file.

Note that even with DHCP option 252, the FQDN in the WPAD URL must always be resolvable; a correct DNS configuration is therefore extremely important.

In the following sections, we explain the different WPAD scenarios that are supported by AXS Guard.

WPAD Scenarios & DNS Records

For automatic proxy detection to work, the correct DNS records must be added to your DNS server. These records allow clients to locate the wpad.dat file and the proxy server specified in this file.

The wpad.dat file (see the example below) contains the FQDN of the proxy server. Clients must be able to resolve this FQDN at all times.

    function FindProxyForURL(url, host)
        {
            var proxyserver = "PROXY axsguard.example.com:3128; DIRECT";
            if (isPlainHostName(host))
                    return "DIRECT";
            if (shExpMatch( host, "intranet*"))
                return "DIRECT";
            if (shExpMatch( host,"example.com"))
                    return "DIRECT";
            if (shExpMatch( host,"*.example.com"))
                    return "DIRECT";
            if (!isResolvable(host))
                    return "DIRECT";
            if (url.substring(0, 5) == "http:" ||
                        url.substring(0, 6) == "https:" ||
                            url.substring(0, 4) == "ftp:"||
                            url.substring(0, 4) == "wss:" ||
                            url.substring(0, 7) == "gopher:")
                    return "PROXY axsguard.example.com:3128; DIRECT";
            if (url.substring(0, 5) == "wais:")
                    return "DIRECT";
            else
                    return "DIRECT";
        }

AXS Guard and Windows Domains are Identical

Using AXS Guard as your DNS Server

AXS Guard automatically creates the required A, CNAME and PTR records for WPAD; no additional configuration is required.

Using Windows as your DNS Server

  1. Create A or CNAME records in the forward zone for WPAD and the hostname of the AXS Guard appliance.
  2. In case you are using Kerberos authentication: create a PTR record in the reverse zone for the hostname of the AXS Guard appliance.
  3. Follow the documented steps to deactivate the global query blocklist. This is necessary in order to resolve WPAD.

AXS Guard and Windows Domains are Different

URL Substitution

When DNS is used for automatic proxy detection, Windows clients will attempt to resolve wpad in their own domain.

For the remainder of this chapter, we'll assume that the Windows domain is axsguard.com and that the AXS Guard system domain is axsguard.lan. Since the Windows domain is axsguard.com, clients will attempt to resolve wpad.axsguard.com, then wpad.axsguard and finally wpad.

Clients will send a HTTP request for wpad.axsguard.com to AXS Guard while its web server will only respond to requests for wpad.axsguard.lan, which is in its system domain. As a result, clients will get a (111) connection refused message.

In order to solve this, requests for wpad.axsguard.com need to be substituted, i.e. wpad.axsguard.com needs to be translated to wpad.axsguard.lan.

The option to subsitute URLs is only available for advanced administrators.

Fully-Customized WPAD

By default, the wpad.dat file will refer to the AXS Guard hostname and system domain. AXS Guard allows you to fully customize the wpad.dat file and replace all occurrences of axsguard.lan with axsguard.com.

Using the AXS Guard DNS Server

AXS Guard cannot serve multiple forward zones. To resolve wpad.axsguard.com, AXS Guard needs to forward the request to another DNS server. This means you have to configure DNS forwarding on AXS Guard so requests for axsguard.com can be resolved by another DNS server, most likely your Active Directory domain controller.

Using a Windows DNS Server

Windows DNS servers are able to serve multiple forward zones, so there are two options:

  • Create a forward zone for axsguard.lan. Create A and/or CNAME records for WPAD and the AXS Guard hostname in this zone.
  • Configure conditional forwarding for axsguard.lan.

Testing DNS and HTTP Requests

Once you have configured your environment, clients should be able to locate and request the wpad.dat file.

The easiest way to test your configuration, is by starting a web browser on a client and navigating to http://wpad.axsguard.com/wpad.dat and http://wpad.axsguard.lan/wpad.dat.

Automatic Proxy Detection

Direct Access to Websites

You can customize the WPAD configuration on AXS Guard to allow clients to access specific hosts and IP addresses directly.

Once you have added an exception for a given website, clients will automatically bypass the proxy server and connect to this website directly.

In case the website is not located in the same subnet as the client, the HTTP request will still have to pass AXS Guard, which means you must configure the firewall and application control system (if applicable) appropriately in order to allow the request.

Testing your WPAD Configuration

  1. Choose a system-wide ACL, e.g. predef-no-porn. This will become the default web ACL for all users.
  2. Check the proxy settings of your browser and operating system. Chromium and browsers which are based on the same engine, such as Microsoft Edge, will use the proxy settings of the operating system. Check the online documentation of your browser for additional information.
  3. Visit a random website. Consult the web access logs on AXS Guard to verify if the website was visited via the proxy server.

User Authentication, Computers and ACLs

A system-wide ACL is enforced for all users. But maybe you want different ACLs for different users. In that case, there are several possibilities.

If your users have AXS Guard accounts, either created locally or via LDAP synchronization, assign the desired ACL to the individual users or groups.

Next you need to make sure that your users can authenticate against AXS Guard. There are several ways to accomplish this: via Kerberos, the SSO Tool, basic authentication, etc. See the authentication guide on this site for additional information about user authentication.

In case you do not want to enforce user authentication, you can create computer records on AXS Guard and assign an ACL to each record. The ACL is then enforced based on the IP address of the computer.

Of course, you can also combine user authentication with computer records as needed.