How To Configure Squid As An Egress Gateway

17 Feb, 2024
Xebia Background Header Wave

This blog configures Squid Proxy as an egress gateway to filter web traffic.

Always ensure that you comply with applicable laws and regulations when implementing network traffic management solutions.

Filtering web traffic

Users and applications visit many different websites, possibly including malicious websites. Thus, to protect the user and application network, web traffic is often filtered.

Firewalls filter traffic based on attributes such as IP address, protocol and domain name. The available attributes depend on the firewall’s operating layer. The higher the layer, the more advanced (and costly) the firewall.

As web proxy, Squid, filters traffic based on information shared via the Proxy protocol. However, Squid can also be configured to intercept traffic to transparently filter traffic based on IP address, protocol and domain name:

Connectivity overview

Image source:

Deploying an intercepting Squid Proxy egress gateway

The following infrastructure is configured to only allow access:

  1. Internet egress via the Squid Proxy instance(s)
  2. Traffic filtering Squid Proxy instance(s)

Find the complete example on GitHub

Internet egress configuration

First, client internet traffic is routed to the Squid Proxy instance(s):

resource "google_compute_route" "example_gateway_internet" {
    project    = var.project_id
    name       = "${}-gateway-internet"
    dest_range = ""

    network      =
    next_hop_ilb =
    priority     = 900

Second, Squid Proxy is allowed to send and receive packets with non-matching destination or source IPs:

resource "google_compute_instance_template" "gateway" {
    project     = var.project_id
    region      = "europe-west1"
    name_prefix = "gateway-${}-"

    # NOTE: IP Forwarding allows send/receive packets with non-matching destination or source IP
    can_ip_forward = true


Finally, client internet traffic arriving at the Squid Proxy instance is redirected to the Squid Proxy listening ports:

iptables -t nat -A PREROUTING -s ${load_balancer_ip} -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP

iptables -t nat -A PREROUTING -s ${load_balancer_ip} -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3130
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -A PREROUTING -p tcp --dport 3130 -j DROP

Traffic filter configuration

First, Squid is configured to intercept traffic:

http_port 3129 intercept
https_port 3130 intercept ssl-bump tls-cert=/etc/squid/certs/ca-cert.pem tls-key=/etc/squid/certs/ca-key.pem tls-default-ca=on

Second, an allowlist is specified:

Finally, the whitelist is applied to the intercepted traffic:

acl http_proxy myportname 3129
acl http_allow dstdomain "/etc/squid/allowlist.txt"

acl https_proxy myportname 3129
acl step3 at_step SslBump3
acl ssl_allow ssl::server_name "/etc/squid/allowlist.txt"

# Try to pass-through requests, bump otherwise
ssl_bump splice ssl_allow
ssl_bump peek step1
ssl_bump stare step2
ssl_bump bump all

# Deny invalid HTTP requests
http_access deny http_proxy !http_allow

# Deny invalid (bumped) HTTP(S) requests
http_access deny step3 https_proxy !ssl_allow 


Regardless of the fact that transparently inspecting traffic is a gray area (does the protection outweigh the privacy violation?), inspecting traffic is challenging. Inspection may fail, because of server response not understood by Squid Proxy, or filtering attributes such as the SNI might no longer be available due to Encrypted Client Hello (ECH).

As most problems arise with encrypted traffic, consider using an explicit proxy instead. If that’s no option, likely you’re better of using a managed offering that reduces the operations efforts, but comes with a (premium) price tag.


With Squid Proxy you can filter web traffic on domain names to protect your networks. However, take note of the limitations of intercepting encrypted traffic and consciously weigh the privacy implications.

Image by Lars Nissen from Pixabay

Laurens Knoll
As a cloud consultant I enjoy taking software engineering practices to the cloud. Continuously improving the customers systems, tools and processes by focusing on integration and quality.

Get in touch with us to learn more about the subject and related solutions

Explore related posts