When a Smoothwall has been configured with multiple internal interfaces often each interface will need to have a web proxy configured on them too, both transparent and non-transparent. In this article we will discuss best practices, how to setup PAC files for each proxy and what other considerations are to be had.
The details of configuring both transparent and non-transparent proxies on an interface can be seen in the online user assistance, so we won't go into detail on this here. Some considerations to be taken before setting up a proxy on an interface are:
- Is both transparent and non-transparent needed?
- What authentication should be used?
- How should the proxy treat unauthenticated requests?
- Is a PAC file needed?
- How is the traffic getting to the internet and should internal traffic be blocked?
Transparent versus non-transparent
There's nothing preventing setting up both a transparent and a non-transparent proxy on an internal interface. Transparent is often configured by default due to this not needing any client configuration but there may be cases for software needing to know that it's going through a proxy for it to work reliably, in which case, having the option to set a proxy is an advantage. The main difference between the two types are:
- Transparent proxies intercept any outgoing traffic destined for ports 80 and 443. If exceptions are needed, the proxy itself needs to be configured to exclude specific source and destinations and this can only be done by IP address.
- When clients do not have proxy settings, they will perform their own DNS resolution and send the request to an IP address, which is why destination exceptions have to be done by IP, not domain. Whereas a client with proxy settings sends it's request directly to the proxy, which then performs the DNS lookup and retrieves the page for the client.
- Transparent proxies need additional configuration considerations for HTTPS traffic due to the reason above.
- There are fewer authentication methods available for transparent proxy setups.
A more in-depth look at these differences and what they mean can be found here:
With regards to authentication methods, the difference here is that the direct NTLM/Kerberos methods are not available for a transparent proxy. We don't recommend that you use these methods as they might cause issues with applications that are unable to reply to Kerberos or NTLM requests. The recommended setup currently is to use iDex and/or login scripts as a base for domain joined devices and RADIUS for BYOD devices. This means the method called "Core authentication" can be used on both transparent and non-transparent proxies.
A more detailed description of the authentication methods can be found in the manual and in the KB article here:
In short, the main challenge when dealing with user authentication, is that a lot of applications use web ports and protocols. The majority of those don't support proxy authentication so by using iDex, login scripts and RADIUS, identification of users happen when they log in to their device or network, not when they talk to the proxy. By the time they do reach the proxy, the proxy already knows who the user is so there is no need to ask for authentication.
How to treat unauthenticated requests
All proxies have an option to assign a specific user group permissions to unauthenticated requests. This is a great option for open access on a WiFi guest network, for example, so all access is done to a certain web filter level. If a user is authenticated, they will get their user group permissions, if the access is not authenticated, they will be filtered according to the unauthenticated access permissions. By default, the setting will be set to use the built-in group "Unauthenticated IPs".
This options also allows the ability to filter users by the proxy port they use. Multiple non-transparent proxies can be configured on the same interface as long as they use different ports. Using this option, you could setup any number of proxies, and use the unauthenticated access option to assign them to specific groups. For example, the proxy on port 800 will treat you as a teacher. The proxy on port 805 will treat you as a student etc. Obviously you won't have usernames in the logs when using this option but you will have the right permissions for the user provided proxy settings are set accordingly.
Using and creating PAC files
Smoothwall has the option to generate PAC files for proxy settings. This is done in the "Web proxy - Web proxy - Automatic configuration" section. A PAC file can be configured for each interface that has a non-transparent proxy configured. Only one proxy can be set in the PAC file if multiple non-transparent proxies have been configured on a single interface.
PAC files can also be customized and uploaded to the Smoothwall if non-standard options are required. A good resource for authoring PAC files can be found here:
More information on creating PAC files on Smoothwall can be found in the help and also in the knowledge base here:
The option to autodiscover proxy settings is available in all desktop browsers and this feature also makes use of the PAC file - in this case, the file will be called wpad.dat and Smoothwall will generate this file by default as well. Using the autodiscover option is a good way of managing proxy settings, especially for devices that are portable. With this option, devices will use the proxy on site automatically and off site, will just go direct. The process for configuring autodiscovery for proxy settings in your network is fairly simple. If the Smoothwall is used to host the WPAD settings file, the following steps needs to be taken:
- Configure an alias in DNS for wpad pointing at the Smoothwall host name.
- If a Microsoft DNS service is used, remove the host name wpad from the DNS blocklist.
- Use group policy to enable the "autodiscover proxy" setting.
If these steps have been taken, clients should be able to issue the command "ping wpad" on the command line and resolve this to the Smoothwall IP address of the interface serving the wpad.dat file. When a browser is set to autodiscover, the browser will try to resolve the wpad host name and if successful, ask that host for the wpad.dat file and set proxy settings according to the content of the wpad.dat file. If the browser cannot resolve the wpad host name, it won't use proxy settings.
Managing traffic paths
A Smoothwall web proxy will send internet traffic out via the default gateway configured on an interface. It is possible to have multiple internet connections on a Smoothwall system and thus also multiple gateways. When the Smoothwall is used as a firewall with directly connected internet connections, it's possible to route traffic out via a specific internet connection based on source networks. This allows one to use specific internet connections for BYOD networks for example.
One other consideration is to understand how web traffic is routed when the Smoothwall has multiple internal networks connected, like BYOD, LAN and Admin networks. While the firewall rules can be setup to block traffic going from BYOD to other internal networks for example, additional rules may be needed for the web filter configuration to prevent HTTP(S) access from BYOD to other internal networks as web traffic going via the proxy is not affected by firewall rules.
When designing a web proxy setup, you should take all of the above considerations into account. Smoothwall will assist with any questions you may have about your setup so please contact support or if a rework is being done, have a word with your account manager who will be able to facilitate getting a solutions architect advice on how to proceed and get the best security and functionality from your Smoothwall installation.