Smoothwall Filter & Firewall: Blocking Web Proxies and VPNs

A Primer on Web Proxies and VPNs

With the ever-growing uptake and focus on web-filtering and safeguarding in education, there has come a slew of browser extensions, desktop clients and mobile applications designed to penetrate, circumvent or otherwise thwart network-level web filters. Many of these applications have legitimate uses out in the world, but can and frequently do get used with the aim of bypassing web filters. 

Typically, the applications work in one of two ways: local proxy or VPN.

Local Proxy

A local proxy is an application installed to a device that intercepts web requests either from the browser or the entire device, and proxies them directly, or else forwards the traffic on to a predefined public proxy server. Usually in either case, any upstream interception of traffic will only see HTTP/S traffic to literal IP hosts - so instead of seeing a request to https://www.google.com a web filter would see requests to https://142.250.200.14, or else the IP address of an upstream public proxy server. This can make web filtering difficult for some systems as they may rely on being able to identify the website form the HTTP Host header in the traffic, and identifying an IP address is a lot more difficult.

VPN

VPN applications and extensions allow network traffic to be sent and received from a remote host/network securely by creating a virtual network between two endpoints. The Smoothwall Filter & Firewall itself hosts a number of VPN options to allow remote workers to access resources behind the Smoothwall remotely. 

Where VPN's become an issue is when they are used to send web-traffic via an encrypted tunnel to a remote server which then proxies the web requests. Due to the encrypted tunnel that is established between the client and the remote server, web traffic sent over that tunnel cannot be analysed - a web filter effectively becomes blind to whatever is going on within the tunnel. 

There are a multitude of VPN applications and browser extensions and generally they fall into one of three categories: SSL VPN, L2TP/IPSec and Wireguard. 

SSL VPN is a very common VPN solution that utilizes SSL/TLS encryption to establish a secure tunnel between the client and the destination server, through which traffic (web and otherwise) can be forwarded. While Windows does not provide native support for SSL VPN, there are plenty of free desktop clients and browser extensions, many pre-configured with an endpoint, gateway forcing and a pinned TLS certificate, making them very much 'plug and play' for the end user. 
SSL VPN, typically, uses:

  • UDP port 1194

or

  • TCP port 443

L2TP/IPSec is a less-common but by no means less effective set of secure tunnelling and transport protocols that allow either a site-to-site VPN or a traditional client-server VPN to be established. While the method of encryption is different, the ultimate effect is the same.
L2TP uses various port numbers:

  • TCP port 1701
  • UDP port 500
  • UDP port 4500.

IPSec VPN is a layer 3 protocol that communicates over IP protocol 50 (ESP).
It might also require:

  • UDP port 500 for Internet Key Exchange
  • UDP port 4500 for IPSec NAT-Traversal.

Wireguard is a relatively new VPN technology and is gaining traction as a faster, simpler and leaner alternative to SSL VPN and IPSec. It is entirely UDP based due to perceived shortcomings of TCP-over-TCP tunnelling. 
In many implementations Wireguard is configured with a default UDP port:

  • UDP 51820

However it can use any high ports (49152:65535) as required. 

The Non-Standard Port Problem

VPN and Web Proxy applications alike may not use the typically expected UDP/TPC ports to achieve their goal. A developer of such an application may decide to obfuscate web traffic or secure tunnels by using any of the non-registered high ports (TCP/UDP 49152:65535) or, better yet, use a registered port to masquerade the traffic as a different service. For example, Psyphon, a highly effective proxy-avoidance tool, tunnels web-traffic out over TCP Port 53, making it easily mistaken for DNS traffic. 

The issue here is that web filters will typically expect web traffic on TCP 80 and 443 for HTTP/S respectively, and as such traffic directed over non-standard high ports or masquerading as other services may not be intercepted and filtered. 

For many of these applications however, if their preferred destination port cannot be reached, they may fall back to normal HPTTP/S or whatever port is used by the applications method of transport - this is both an advantage, and a weakness that can be exploited to prevent their use. 

Blocking Web Proxies and VPNs

The method for blocking such applications should be viewed as a holistic approach - one of a number of techniques may prove initially mildly effective however in concert a handful of well-thought network changes and device management policies can effectively put an end to undesired Web Proxy and VPN use. 

The overall 'method' comes down to a few questions:

  1. Is the device managed and under my control?
    • If yes then all VPN and Web proxy software and browser extensions can be ruled our by disallowing the installation of such by the user, and by blocking access to USB ports and external media. This puts an end to the issue at the root.
    • If no, then...
  2. What services does the device need to function to an acceptable level?
    • BYOD devices typically only need HTTP/S and DNS for their most common use. It is unlikely BYOD devices need access to anything beyond this for application use and web browsing. Obviously, there may be exceptions based on who the device belongs too and their individual requirements. 
  3. Can required services be provided locally, or otherwise proxied through a system I control?
    • DNS can be provided either from a local DNS server with public forwarders or otherwise proxied using the Smoothwall.
    • Web services can be provided by the Guardian Web Filter via an explicit or transparent proxy. 
    • This means BYOD devices can be effectively firewalled off from the public internet and their required services provided from local, controlled sources, and those sources alone have access through the firewall to the public internet. As an example, you can provide a local DNS server to the BYOD device through DHCP, however if the user were to manually edit their DNS settings on the device to a public DNS server, they would find DNS no longer working due to the firewall blocking the access.
  4. Can my Web-Filter detect and defeat the applications where standard web ports are used?
    • If in blocking outbound access to the applications endpoints on its preferred ports the applicaiton reverts to HTTP/S or uses HTTP/S by default, and the traffic is passed through the Guardian Web Filter, the answer is yes. 

In summery, blocking Web Proxies and VPNs comes down to the following:

  1. Lock down managed devices so no such software can be run. 
  2. Identify services the devices need to function and utilize local servers or proxies to provide that service without direct access to the internet.
  3. Block all outbound access at the firewall except for the local servers and proxies on the ports they need to function. 
  4. Employ the Guardian Web Filter with HTTPS Inspection to detect and block VPN tunnels over HTTPS and proxied web requests. 
  5. Finally, any service that is required but cannot be proxied or provided locally should be considered closely and where possible outbound access locked down to known public destination addresses.

Configuring Guardian

In the Guardian Web Filter:

  1. Create a Web Filter Policy to block the following categories:
    • Web proxies
    • All HTTP URLs Containing an IP Address
    • All HTTPS URLs Containing an IP Address
  2. Create a HTTPS Inspection Policy set to 'Decrypt and Inspect' for the following categories:
    • Web proxies
    • All HTTP URLs Containing an IP Address
    • All HTTPS URLs Containing an IP Address
  3. Optionally, block traffic with no SNI over the transparent proxy:
    • Navigate to Web proxy > Authentication > Manage Policies.
    • Edit any Transparent Authentication policy present.
    • Set the 'Behaviour' value to 'Block HTTPS traffic with no SNI header' and save the policy.
    • Restart the proxy as prompted. 
    • NOTE: this may negativity impact web allowed web traffic that by design does not use an SNI header, such as WhatsApp. If in doubt, set the Behaviour to 'Allow Transparent HTTPS incompatible sites and filter others using name from certificate'.

Configuring the Firewall

Assuming the Smoothwall Filter & Firewall is deployed as the edge firewall in the network, then you may configure outbound firewall policies to restrict outbound access to the internet for internal clients, and thus cut off the paths many VPN and Web proxy applications use to circumvent web filtering. 

If your network is segmented using VLANS or separate physical interfaces on the Smoothwall appliance, then controlling outbound access for different devices becomes much easier to manage.

See our article on configuring Firewall rules.

The following example shows the 'lock down' approach mentioned earlier in this article:

Firewall

Note: Any service that is provided or proxied by the Smoothwall does not require a firewall policy - these are set up by the system internally. 

 

A Few Well Known Players

See below a list of well known VPN, Web proxy and other 'censorship-avoidance' tools. Please note this list is not exhaustive and the ports listed may change as the whim of the developers, as such it should be used as a rough guide. 

Proxy Ports Additional Notes Last Checked
Betternet 1194, 5228, 7268, 9110  Will attempt to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only 20th June 2019
CyberGhost 8078   20th June 2019
F-Secure Freedome VPN 500, 2744   31st January 2018
Freegate 1024 - 65535   March 2017
freevpn.og 8010 Will attempt to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only 20th June 2019
GPass 1024-65535   January 2017
Hexatech 5228, 9110   20th June 2019
Hideman VPN 500, 995   31st January 2018
HotSpot Shield 105, 179, 465, 990, 1024-65535 Will attempt to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only  20th June 2019
Kiwi VPN 1194   24th June 2019
Opera Free VPN 1194, 5353 Will attempt to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only 20th June 2019
PrivitizeVPN 1723  

January 2017
Private Internet Access VPN

UDP port 51820 (Wireguard)

TCP port 1337

TCP/UDP ports 49152 - 65535 (High Ports)

TCP/UDP port 8080 (HTTP-ALT)

TCP/UDP port 853 (DNS over TLS)

UDP 53 (DNS)

UDP 123 (NTP)

  

November 2021
Secure VPN 82, 115, 500, 910, 4500   24th June 2019
Security Kiss 123, 5000, 5353   20th June 2019
SetupVPN 3000   24th June 2019
Snap VPN 500 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. 24th June 2019
SpeedVPN 7, 1024-65535   20th June 2019
Spotflux 443 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. January 2017
Surf VPN 9970-9979   24th June 2019
Thunder VPN 53, 81, 465, 802, 936   24th June 2019
Tor 1024-65535 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. 24th June 2019
TunnelBear 7011   20th June 2019
Turbo VPN 500   24th June 2019
VPN Monster 23, 25, 66, 110, 119 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. 24th June 2019
VPNGate 500, 992, 995, 1024-65535 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. 24th June 2019
VPN360 UDP 443, 500, 4000   24th June 2019
Yoga VPN 5000, 8000, 52000 Will attempt to connect on port 80 or 443 so ensure that the HTTPS inspection policy is set to either Decrypt and inspect or Validate certificate only. 21st June 2019

Windscribe 

 

 UDP ports: 80, 443. TCP and UDP ports: 500, 1194, 4500, 5228, 54783 Attempts to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only.

21st June 2019

Wireguard

Default: UDP 51820

High ports: 49152:65535

 Attempts UDP 51820 connection first, otherwise it falls back to trying to use high ports. As long as firewall is locked down and high ports blocked it should not work.

17th June 2021
X-VPN This proxy uses a range of different ports (including 21, 25 and 53), you will need to lock down your firewall and only open ports that are necessary Attempts to connect on port 80 or 443, so ensure that the HTTPS inspection policy is set to their Decrypt and inspect or Validate certificate only. 26th June 2019