TRAINING LAB

Securing Internet Access with pfSense & Squid

pfSense 2.6.0 · Squid · SquidGuard · LightSquid · VMware Workstation 17

Context

Building on the virtualized lab from case study n°4 (AD DS / DNS / DHCP / WDS on Windows Server 2022), I added a pfSense 2.6.0 firewall VM to act as the network gateway. The goal was to secure outbound internet access for all machines on the private LAN (192.168.100.0/24), filter web traffic through a Squid transparent proxy, and enforce access policies — replicating real-world enterprise perimeter security.

Network Architecture

Hypervisor: VMware Workstation Pro 17
pfSense VM: FreeBSD 12 64-bit — 10 GB HDD, 2 GB RAM
WAN (em0): Bridged to host 4G USB modem — DHCP — 192.168.1.110/24
LAN (em1): VMnet8 (NAT) — 192.168.100.220/24 (pfSense gateway)
AD server (DCAD22): 192.168.100.250 — AD DS, DNS, DHCP, WDS
File server (SRVSAMBA): 192.168.100.130 — Samba shares
Clients: 192.168.100.21, 192.168.100.22
pfSense web UI: https://192.168.100.220

Setup phases

1
Phase 1 — pfSense installation
Created a new VM in VMware Workstation (FreeBSD 12 64-bit, 10 GB, 2 GB RAM) with two network adapters: NIC 1 set to Bridged (connecting directly to the host machine's 4G USB dongle as WAN), NIC 2 set to Custom VMnet8 (the existing private LAN). Booted the pfSense 2.6.0 ISO, accepted the license, selected French keymap, and proceeded with the standard installation. After reboot, the console confirmed WAN on em0 (192.168.1.110/24) and LAN on em1 (192.168.100.220/24).
2
Phase 2 — Firewall aliases & rules
In the pfSense web UI, created two IP aliases under Firewall → Aliases: 'SRV' (192.168.100.130 = SRVSAMBA, 192.168.100.250 = DCAD22) and 'Client' (192.168.100.21, 192.168.100.22). Configured LAN rules: allowed DNS (UDP 53) from SRV alias, allowed ICMP echo-requests from SRV, then added an explicit block rule 'REFUS SRV VERS INTERNET' (IPv4 any from SRV) — placed above the default allow-all rule. This ensures servers can resolve DNS and respond to pings but cannot initiate outbound internet connections.
3
Phase 3 — Squid proxy & SquidGuard
Installed three packages via System → Package Manager: squid (0.4.45_9), squidGuard (1.16.18_20), and LightSquid (3.0.6_9 — reporting dashboard). Configured Squid as a transparent proxy on the LAN interface (port 3128), enabled SSL inspection using an internally generated CA (Pfsense-CA, self-signed, valid 10 years, C=FR / ST=Ile de France / O=greta / L=argenteuil). Configured SquidGuard with category-based URL blacklists. LightSquid was enabled for per-user traffic reporting accessible from the pfSense UI.

Outcomes

Gateway: pfSense 2.6 routing and NATing all LAN traffic through the 4G WAN connection
Access control: Servers (SRV alias) blocked from internet; only DNS + ICMP exceptions allowed
Web filtering: Squid transparent proxy + SquidGuard blocking unwanted URL categories
HTTPS inspection: Self-signed internal CA deployed for SSL bump on outbound HTTPS
Reporting: LightSquid dashboard providing web usage statistics per client
Skills: pfSense, firewall rules, IP aliases, Squid proxy, SquidGuard, PKI / CA management

Security notes

Least-privilege firewall rules: only allow the minimum required egress ports and destinations — the default allow-all rule must always be the last rule, never the first.
HTTPS inspection requires a trust decision: the internal CA (Pfsense-CA) must be imported as a trusted root in every client browser or OS, otherwise HTTPS sites will show certificate warnings.
SquidGuard URL blacklists only work on HTTP and on intercepted HTTPS — traffic that bypasses the proxy (direct IP connections, DNS-over-HTTPS) will not be filtered.
Log review is part of operations: LightSquid reports and Squid access logs must be checked regularly to verify that rules are working and to detect anomalous traffic patterns.
Alias maintenance matters: the SRV and Client IP aliases must be kept up to date as the network grows — outdated aliases silently break the firewall policy.

Screenshots