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.
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
WPAD, DHCP and DNS
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.
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
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.
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 (shExpMatch( host, "intranet*"))
if (shExpMatch( host,"example.com"))
if (shExpMatch( host,"*.example.com"))
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:")
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
- Create A or CNAME records in the forward zone for WPAD and the hostname of the AXS Guard appliance.
- In case you are using Kerberos authentication: create a PTR record in the reverse zone for the hostname of the AXS Guard appliance.
- 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
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
Since the Windows domain is
axsguard.com, clients will attempt to resolve
wpad.axsguard and finally
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
The option to subsitute URLs is only available for advanced administrators.
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
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
Testing DNS and HTTP Requests
Once you have configured your environment, clients should be able to locate and request the
The easiest way to test your configuration, is by starting a web browser on a client and navigating to
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
- Choose a system-wide ACL, e.g.
predef-no-porn. This will become the default web ACL for all users.
- 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.
- 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.