Squid E2guardian

Option A: Azure Portal

Search the Marketplace for Squid + E2guardian Filtering and Caching Proxy on Ubuntu 24.04, choose your VM size, and provide your SSH public key. Attach a network security group that allows:

• TCP 22 (admin SSH) from your management network only.
• TCP 8080 (the proxy) from your client subnet only. Never allow it from Internet or Any. An open proxy is found and abused within hours.

Do not add an NSG rule for port 3128. Squid listens on the loopback interface only and is never reached from off the machine.

Option B: Azure CLI

The rule that matters here is allow-proxy-clients. It is scoped to a client CIDR, never to Internet.

RG="squid-e2guardian-prod"; LOCATION="eastus"; VM_NAME="filterproxy-01" IMAGE_URN="sac1647283583153:squid-e2guardian-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name fp-vnet --address-prefix 10.60.0.0/16 --subnet-name fp-subnet --subnet-prefix 10.60.1.0/24 az network nsg create -g "$RG" --name fp-nsg az network nsg rule create -g "$RG" --nsg-name fp-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name fp-nsg --name allow-proxy-clients --priority 110 \
  --source-address-prefixes "10.60.1.0/24" --destination-port-ranges 8080 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:squid-e2guardian-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name fp-vnet --subnet fp-subnet --nsg fp-nsg --public-ip-sku Standard

Connect over SSH as azureuser:

ssh azureuser@<vm-ip>

Find the public IP with az vm show -d -g squid-e2guardian-prod -n filterproxy-01 --query publicIps -o tsv.

Three units must be active. The filtering proxy is coupled to both the allowlist and the caching upstream, so a healthy e2guardian implies a healthy squid and a healthy allowlist.

sudo systemctl is-active squid e2guardian e2guardian-firewall ss -tln | grep -E ':8080 |:3128 |:22 ' || true e2guardian -v | head -1 squid -v | head -1 echo "stack verified"

The output shows all three units reporting active. It also shows e2guardian listening on 0.0.0.0:8080, Squid listening on 127.0.0.1:3128 (loopback only), your admin SSH on 0.0.0.0:22, and the two version banners.

active active active LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* LISTEN 0 256 127.0.0.1:3128 0.0.0.0:* LISTEN 0 256 0.0.0.0:8080 0.0.0.0:* e2guardian 5.5.9r Squid Cache: Version 6.14

This is the key step. A running service does not prove that a filtering proxy filters. A status code does not prove it either, because a block page and a real page can both return successfully. The check below compares the content returned for a permitted site against the content returned for a blocked one, both fetched through the proxy.

The image ships exactly one demo block entry: example.org, IANA's reserved documentation domain, so blocking it affects no real service. example.com is not blocked, and both domains serve the same page when unfiltered, which makes them a clean pair for the test.

printf 'ALLOWED example.com -> ' curl -s -m 20 -x http://127.0.0.1:8080 http://example.com/ | grep -o '<h1>[^<]*</h1>' printf 'BLOCKED example.org -> ' curl -s -m 20 -x http://127.0.0.1:8080 http://example.org/ | grep -o '<title>[^<]*</title>' echo "filtering verified"

The permitted request returns the real page (<h1>Example Domain</h1>). The blocked request returns E2guardian's own block page (<title>E2Guardian - Access Denied</title>), and the real page content is absent. That difference shows the filter doing its job.

ALLOWED example.com -> <h1>Example Domain</h1> BLOCKED example.org -> <title>E2Guardian - Access Denied</title>

In this image, E2guardian does not fetch from the internet itself. It forwards permitted requests to the local Squid, which fetches them or serves them from its cache. You can see both halves of that.

First, the request you just allowed appears in Squid's access log. That proves E2guardian forwarded it to the caching upstream instead of going straight to origin:

grep -m1 'example.com' /var/log/squid/access.log

1786236560.021 14 <client> TCP_MISS/200 929 GET http://example.com/ - HIER_DIRECT/<origin> text/html

Then, to see a real cache hit, fetch a cacheable object through Squid twice. TCP_HIT or TCP_MEM_HIT in the log means Squid served the repeat from cache instead of refetching it:

D=$(mktemp -d); echo "cache probe" > "$D/probe.txt" ( cd "$D" && python3 -m http.server 18080 >/dev/null 2>&1 & echo $! > /tmp/origpid ) sleep 1 curl -s -o /dev/null -x http://127.0.0.1:3128 http://127.0.0.1:18080/probe.txt curl -s -o /dev/null -x http://127.0.0.1:3128 http://127.0.0.1:18080/probe.txt sleep 1 grep 'probe.txt' /var/log/squid/access.log | awk '{print $4, $7}' | tail -2 kill "$(cat /tmp/origpid)" 2>/dev/null echo "caching verified"

TCP_HIT/200 http://127.0.0.1:18080/probe.txt TCP_MEM_HIT/200 http://127.0.0.1:18080/probe.txt

You now have filtering and caching in one appliance.

The allowlist accepts loopback and RFC1918 sources and drops everything else. You can exercise the real rule with a foreign source address. 203.0.113.7 is from TEST-NET-3, a range reserved for documentation, so it can never collide with your own network.

The first request is the positive control. If a permitted source could not relay either, a refusal would prove nothing.

sudo nft list table inet e2guardian
H=$(hostname -I | awk '{print $1}')
sudo ip addr add 203.0.113.7/32 dev lo 2>/dev/null || true printf 'permitted source %s -> ' "$H" curl -s -m 15 --interface "$H" -x http://$H:8080 http://example.com/ | grep -o '<h1>[^<]*</h1>' printf 'unauthorised source 203.0.113.7 -> ' curl -s -m 8 --interface 203.0.113.7 -x http://$H:8080 http://example.com/ >/dev/null 2>&1 && echo "RELAYED" || echo "refused by the source allowlist"
sudo ip addr del 203.0.113.7/32 dev lo 2>/dev/null || true echo "relay refusal verified"

The permitted private address relays successfully, and the unauthorised address is dropped.

To serve clients from a range outside RFC1918, add it to the e2g_allowed set in /etc/e2guardian/sac-firewall.nft and run sudo systemctl restart e2guardian-firewall. Then widen your NSG rule to match.

Every request, allowed or denied, is recorded. E2guardian's log carries the filtering decision, and Squid's log carries the cache decision. Denied entries carry the reason and the list that matched, which makes the appliance auditable.

sudo tail -n 3 /var/log/e2guardian/access.log echo "access log verified"

Each e2guardian line records the timestamp, client address, URL, method and status. For a denial, it also records the reason, such as *DENIED* Blocked site (local): example.org. Forward both logs to your SIEM with any standard log shipper.

The first-boot service wrote a root-only note that describes this VM's proxy endpoint, the access control in force and the TLS posture. Read it:

sudo cat /root/squid-e2guardian-info.txt echo "instance note verified"

The note is owned by root:root with mode 0600. It states that the appliance has no login and no bootstrap credential, and it records the private proxy endpoint. No public proxy endpoint is advertised, because clients should always reach the proxy over your own network.

The block list is a plain-text file with one domain per line. A bare domain also covers its subdomains. Locate the file:

E2G_LISTS=$(sed -nE 's/^[[:space:]]*\.Define[[:space:]]+LISTDIR[[:space:]]*<([^>]+)>.*/\1/p' /etc/e2guardian/e2guardianf1.conf | head -1)
echo "your block list is at $E2G_LISTS/localbannedsitelist"
sudo grep -v '^#' "$E2G_LISTS/localbannedsitelist" | grep -v '^$' echo "block list located"

Add your own domains to that file, and remove the example.org demo line when you no longer need it. Then apply the change:

sudo systemctl reload e2guardian echo "policy reloaded"

E2guardian also ships upstream's category and weighted-phrase lists in the same directory (bannedsitelist, bannedurllist, weightedphraselist and others). You can populate them with a commercial or community blocklist feed.

The localbannedsitelist used above is upstream's dedicated file for local administrator additions, so your entries stay separate from any feed you import.

From a machine on your client subnet, set the standard proxy environment variables, or configure the proxy in your browser or operating system network settings. Point them at the e2guardian port 8080, never at Squid. For example:

PROXY=$(sudo sed -n 's/^PROXY_URL=//p' /root/squid-e2guardian-info.txt)
echo "using proxy $PROXY" export http_proxy="$PROXY" export https_proxy="$PROXY" curl -s -o /dev/null -w 'allowed site -> HTTP %{http_code}\n' http://example.com/ curl -s http://example.org/ | grep -o '<title>[^<]*</title>'
echo "client proxy configuration verified"

Run these commands from a client machine, using the private address from the instance note. The allowed site returns HTTP 200 and the blocked site returns the E2Guardian block page. That confirms the client goes through the filter and its cache instead of straight out to the internet.

HTTPS requests are filtered by the hostname in the CONNECT request, so domain policy applies to HTTPS as well as HTTP, without any interception of the encrypted payload.