DEV Community: ZeroTrust Architect

Your ISP Box Was Never Designed to Protect You — Here's What We Did About It

ZeroTrust Architect — Thu, 28 May 2026 06:07:06 +0000

We talk to a lot of small business owners. And when we ask them what's protecting their network, we get the same answer almost every time.

They point at the box their internet provider gave them.

That box. The one blinking in the corner. The one nobody ever touches.

Here's the thing nobody tells them: that box was never designed to protect you. It was designed to connect you. Two very different jobs.

🧑‍💻 Experienced with networking? The basics are covered in the first two sections — feel free to jump straight to So we put ourselves in the chain.

What the ISP box actually does

Your router forwards traffic. That's it. When you visit a website, it passes the request along. When the response comes back, it delivers it to your device. It does this for everything — legitimate requests, malware callbacks, phishing traffic, all of it — without asking a single question.

It's not a flaw. It's by design. ISP routers are built to be universal and simple. Security is simply not their job.

So if something on your network gets compromised — a laptop, a phone, even a printer — your router will happily forward whatever traffic that device generates. Nobody's watching.

Two concepts that unlock everything

Before we built CacheGuard, we spent a lot of time figuring out how to explain the problem to non-technical people. We landed on two ideas that make everything else click.

1. An IP address is a postal address for a device

Every device on your network has one. Your laptop, your phone, your printer — each has a unique number like 192.168.1.42. When your laptop sends a request to a website, it includes that address so the network knows where to deliver the response. That's all an IP address is.

Two flavours matter here:

Private IP — used inside your office. Devices talk to each other, but the internet can't reach them directly.
Public IP — the address your ISP assigns your router. It's how the outside world sees your entire network.

2. A default route is just a rule: "when in doubt, ask the gateway"

When a device wants to reach something on the internet and doesn't know the exact path, it follows its default route — a rule that points it toward a gateway device. The gateway figures out the next step.

In a typical office:

Your devices → Router (ISP box) → ISP → Internet

Every device in the office has a default route pointing at the router. The router has a default route pointing at the ISP. Simple chain.

Here's the insight: whoever controls the gateway controls the traffic.

So we put ourselves in the chain

That's exactly what CacheGuard does. It inserts itself between your devices and your ISP router:

Your devices → CacheGuard → ISP Router → Internet

Your devices' default route now points to CacheGuard. CacheGuard's default route points to the ISP router. The chain still works — but now there's a checkpoint in the middle that can:

Block malicious domains and malware
Filter content by category
Cache web content to speed up browsing
Log and monitor all network activity
Control access by device or user

And the ISP router? It needs zero changes. It keeps doing what it always did.

What the setup actually looks like

CacheGuard runs on any standard PC or virtual machine. It needs two network interfaces:

WAN — connected to your ISP router
LAN — connected to your office switch

[Internet]
    |
[ISP Router]        ← e.g. 192.168.1.1  (unchanged)
    |
[CacheGuard]        ← WAN: 192.168.1.2 / LAN: 10.0.0.1
    |
[Office switch]
    |
[All your devices]  ← default route: 10.0.0.1

At the IP level:

CacheGuard WAN gets an IP on the ISP router's subnet (e.g. 192.168.1.2). Its default route points to the ISP router (192.168.1.1).
CacheGuard LAN gets an IP on a separate subnet (e.g. 10.0.0.1). This becomes the gateway for all office devices.
Your devices get their default route updated to 10.0.0.1 — easiest done by letting CacheGuard act as your DHCP server.

💡 You don't need to reconfigure your ISP router at all. CacheGuard simply inserts itself and the router carries on as before.

Why free and open-source

A small dental practice faces the same phishing attacks as a large corporation. A five-person agency is just as vulnerable to ransomware. The difference is resources — and we think that's the wrong reason for someone to go unprotected.

CacheGuard is free, open-source, and built to be deployed by someone who isn't a network engineer. The web-based admin interface walks you through configuration, and the defaults are sensible and secure out of the box.

Where to go from here

👉 Full plain-English setup guide
📖 CacheGuard Documentation
💬 Community forum

Also worth reading if you want to go deeper on network architecture: What is a DMZ network?

Blocking Adult Content at the Proxy Layer: Mandatory HTTPS Enforcement, Category Filtering, and Always-On VPN

ZeroTrust Architect — Wed, 20 May 2026 07:58:36 +0000

DNS-based adult content filtering is the most commonly recommended approach and the least reliable technically. Here is why it fails and how to implement proxy-layer filtering that cannot be bypassed with a DNS settings change.

Why DNS filtering fails for adult content blocking

DNS filtering intercepts name resolution queries and returns NXDOMAIN for blocked domains. Three bypass vectors make it unreliable:

1. Manual DNS override (30 seconds, no technical knowledge required):

# iOS: Settings → Wi-Fi → [network] → Configure DNS → Manual → 8.8.8.8
# Android: Settings → Network → Private DNS → dns.google
# Windows: Network adapter settings → IPv4 → DNS servers → 8.8.8.8

Result: queries go to Google's resolver, which does not enforce your blocklist.

2. DNS over HTTPS (DoH) — enabled by default in several environments:

Firefox: uses Cloudflare DoH by default (about:config → network.trr.mode = 2)
Windows 11: DoH supported natively, configurable without admin rights
Chrome: uses DoH when the configured DNS server supports it

DoH encrypts DNS queries in HTTPS, making them indistinguishable from regular web traffic. Your DNS filter never sees the query.

3. Mobile data — bypasses the home network entirely. No DNS filtering, no network controls.

Proxy-layer enforcement architecture

[Client] → [iptables REDIRECT] → [Squid proxy] → [Category filter] → [Internet]
                                        ↑
                    Cannot bypass: traffic physically redirected by kernel

Step 1: Mandatory proxy via iptables

# Redirect all HTTP to transparent Squid port
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
  ! -d 192.168.1.1 -j REDIRECT --to-port 3128

# Block direct HTTPS bypassing the proxy
# (Squid handles HTTPS via CONNECT in explicit mode)
# Force all clients to use explicit proxy for HTTPS:
iptables -A FORWARD -p tcp --dport 443 -j DROP

For explicit proxy mode: configure clients to use 192.168.1.1:3128 as proxy. The FORWARD DROP rule ensures any device that ignores the proxy configuration cannot reach port 443 directly.

Step 2: Squid adult content category filtering

# /etc/squid/squid.conf

url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 5

# /etc/squidguard/squidGuard.conf

dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

dest adult {
    domainlist adult/domains
    urllist    adult/urls
}

dest anonymizers {
    domainlist anonymizers/domains
}

acl {
    default {
        pass !adult !anonymizers all
        redirect http://192.168.1.1/blocked.html
    }
}

The anonymizers category blocks web-based proxy services that could be used to route around the adult content filter.

Step 3: HTTPS filtering via CONNECT method

In explicit proxy mode, HTTPS connections use the HTTP CONNECT method. The proxy sees the destination hostname in plaintext before the TLS handshake:

CONNECT www.adult-site.com:443 HTTP/1.1
Host: www.adult-site.com:443

Squid evaluates ACLs against the CONNECT target:

acl adult_ssl ssl::server_name_regex -i "/etc/squid/adult_domains.txt"
http_access deny CONNECT adult_ssl

For category-based HTTPS filtering without SSL decryption, this provides hostname-level blocking. For URL-path-level filtering on HTTPS, SSL inspection (ssl-bump) is required.

Extending filtering outside the home: always-on IKEv2 VPN

Mobile devices on cellular data bypass all home network controls. An always-on VPN routes all device traffic through the home gateway regardless of the underlying network:

# /etc/ipsec.conf — StrongSwan full-tunnel VPN
conn family-devices
    keyexchange=ikev2
    leftsubnet=0.0.0.0/0    # Route all traffic through tunnel
    rightsourceip=10.9.0.0/24
    rightdns=192.168.1.1    # Internal DNS
    auto=add

iOS always-on VPN (via configuration profile):

<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
    <dict>
        <key>Action</key>
        <string>Connect</string>    <!-- Connect on any network -->
    </dict>
</array>

Android always-on VPN: Settings → Network → VPN → [profile] → Always-on VPN + Block connections without VPN.

Once the device is on the VPN, all traffic routes to the home gateway → through the Squid proxy → through the category filter → then to the internet. The adult content filter applies regardless of the physical connection.

URL blacklist maintenance

Category databases require regular updates. Options:

Free community-maintained lists (variable quality, manual update)
Commercial subscription databases (higher coverage, automated updates)

For automated updates via cron:

# Update squidGuard category database
0 3 * * * /usr/bin/squidGuard -C all && /usr/bin/squid -k reconfigure

CacheGuard ships Squid + SquidGuard + mandatory proxy enforcement + IKEv2 VPN pre-integrated, with an optional URL blacklist subscription for continuously updated adult content categories.

→ https://www.cacheguard.com/block-adult-content-home-network/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Implementing a Three-Zone DMZ With a Single Firewall: iptables Rules, Zone Isolation, and Traffic Flow Analysis

ZeroTrust Architect — Wed, 20 May 2026 07:57:48 +0000

A DMZ is implemented by placing internet-facing servers in a network zone that is accessible from the internet but isolated from the internal LAN. A single firewall with three network interfaces is sufficient for most SME deployments. Here is the technical implementation.

Network topology

[Internet]
    |
   eth0 (WAN: 203.0.113.1)
    |
[Firewall/Gateway]
    |           |
   eth1        eth2
(DMZ:        (Internal LAN:
192.168.10.0/24)  192.168.1.0/24)
    |
[Web server: 192.168.10.5]
[Email server: 192.168.10.6]

Default zone policies

The firewall's default posture for each zone crossing:

From → To	Default policy	Rationale
Internet → DMZ	Deny (explicit permits only)	Only specific published services allowed
Internet → Internal	Deny all	No direct external access to internal LAN
DMZ → Internal	Deny all	Compromised DMZ server cannot reach internal
Internal → DMZ	Permit	Internal hosts manage DMZ servers
Internal → Internet	Permit	Outbound internal traffic allowed
DMZ → Internet	Permit (restricted)	DMZ servers can reach external resources

iptables implementation

# Flush existing rules
iptables -F FORWARD
iptables -P FORWARD DROP   # Default deny all zone crossings

# === INTERNET → DMZ ===
# Allow inbound HTTPS to web server
iptables -A FORWARD -i eth0 -o eth1 -d 192.168.10.5 -p tcp --dport 443 -j ACCEPT
# Allow inbound SMTP to email server
iptables -A FORWARD -i eth0 -o eth1 -d 192.168.10.6 -p tcp --dport 25 -j ACCEPT
# Allow established/related return traffic
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# === INTERNET → INTERNAL ===
# Default DROP already covers this (no explicit permit)

# === DMZ → INTERNAL ===
# Default DROP covers this.
# Explicit permit: web server to internal database only
iptables -A FORWARD -i eth1 -s 192.168.10.5 -o eth2 \
  -d 192.168.1.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i eth2 -s 192.168.1.20 -o eth1 \
  -d 192.168.10.5 -m state --state ESTABLISHED,RELATED -j ACCEPT

# === INTERNAL → DMZ ===
# Allow internal management access to all DMZ servers
iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT

# === INTERNAL → INTERNET ===
iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT

# === DMZ → INTERNET ===
# DMZ servers can reach the internet for updates, API calls
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

# === NAT ===
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Traffic flow verification

After applying rules, verify each permitted and denied flow:

# Should succeed: internal host reaching DMZ web server
curl -k https://192.168.10.5  # from 192.168.1.x host

# Should succeed: internet reaching DMZ web server (test with external tool)
curl -k https://203.0.113.1   # after DNAT rule (see below)

# Should fail: DMZ server reaching internal LAN (not the database)
# From 192.168.10.5:
ping 192.168.1.1    # Expected: no response (FORWARD DROP)

DNAT for public service exposure

To expose DMZ services to the internet via the gateway's public IP:

# DNAT: inbound HTTPS on public IP → DMZ web server
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
  -j DNAT --to-destination 192.168.10.5:443

Reverse proxy in the DMZ

A more secure architecture places a reverse proxy in the DMZ rather than the web server directly. The reverse proxy:

Terminates TLS (holds the certificate private key)
Applies WAF inspection (ModSecurity + OWASP CRS)
Forwards clean requests to backend servers in the internal zone

[Internet] → eth0 → [DMZ: Reverse Proxy + WAF] → eth2 → [Internal: App server]

The app server is never directly reachable from the internet. Only the reverse proxy is in the DMZ. WAF inspection happens before any request reaches the application.

CacheGuard zone architecture

CacheGuard implements this via its native zone model: external zone (eth0), internal/web zone (eth1) with optional rweb VLAN for web servers, and auxiliary zone (eth2) for general DMZ services. Zone policies are configured through the web interface without writing iptables rules directly.

→ https://www.cacheguard.com/what-is-a-dmz-network/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

GDPR Article 32 and NIS2 Article 21: Mapping Cybersecurity Requirements to Concrete Network Controls

ZeroTrust Architect — Wed, 20 May 2026 07:57:31 +0000

Both GDPR and NIS2 specify technical security requirements in principle-based language. This guide maps those principles to concrete network security controls — what each requirement means technically, and which controls satisfy it.

This is a technical guide, not legal advice.

GDPR Article 32: Technical Requirements

Article 32 requires "appropriate technical and organizational measures" and specifically mentions:

GDPR Article 32 requirement	Technical interpretation
Pseudonymization and encryption of personal data	Encryption in transit (TLS/IPsec) and at rest (disk encryption)
Confidentiality, integrity, availability, resilience	Network segmentation, redundancy, access control
Ability to restore availability	Failover, backup, tested recovery procedures
Regular testing and evaluation	Vulnerability scanning, penetration testing, log review

Encryption in transit: IPsec VPN implementation

# StrongSwan IKEv2 — encrypts remote worker traffic
conn gdpr-remote-access
    keyexchange=ikev2
    left=%any
    leftcert=server.crt
    leftsubnet=0.0.0.0/0    # Full tunnel — all remote traffic encrypted
    right=%any
    rightsourceip=10.8.0.0/24
    ike=aes256-sha256-ecp256!
    esp=aes256-sha256!
    auto=add

This satisfies encryption in transit for remote workers. Encryption at rest (full-disk encryption, database encryption) is a separate control at the endpoint/server layer.

Network segmentation: zone-based firewall

# Zone isolation: separate VLAN for servers holding personal data
# Default deny between zones
iptables -I FORWARD -i eth1.servers -o eth1.workstations -j DROP
iptables -I FORWARD -i eth1.workstations -o eth1.servers -j DROP

# Explicit permit: specific application only
iptables -A FORWARD -i eth1.workstations -d 192.168.10.5 -p tcp --dport 443 -j ACCEPT

Zone segmentation limits the blast radius of a compromise. An attacker who compromises a workstation cannot directly reach database servers in a different zone.

NIS2 Article 21: Ten Mandatory Cybersecurity Measures

For in-scope organizations, Article 21 specifies ten mandatory measures. The network-relevant ones:

Access control and identity management

# Squid LDAP authentication — restrict proxy access to authenticated users
auth_param basic program /usr/lib/squid/basic_ldap_auth \
  -b dc=example,dc=com -f '(&(sAMAccountName=%s))' -h ldap.example.com
auth_param basic children 10
auth_param basic realm Network Access

acl authenticated proxy_auth REQUIRED
http_access deny !authenticated

Network segmentation (same as GDPR above)

NIS2 is more explicit: it requires documented network segmentation policies, not just technical controls. The iptables rules above need accompanying documentation describing the segmentation design and rationale.

Encryption

Same controls as GDPR — IPsec for remote access, TLS for internal service communication, certificate management.

Incident detection and response

# iptables logging for anomaly detection
iptables -A FORWARD -j LOG --log-prefix "FORWARD: " --log-level 4

# Review logs for:
# - Unusual outbound connection volumes
# - Connections to unexpected external IPs
# - Internal zone crossing attempts not matching permit rules

NIS2 requires incident reporting within 24 hours. This is an organizational process, not a technical control — but logs from the gateway provide the evidence needed to determine what happened and when.

Malware protection

# ICAP antivirus — gateway malware scanning
icap_enable on
icap_service av_service reqmod_precache bypass=0 icap://127.0.0.1:1344/squid_clamav
adaptation_service_set request_services av_service
adaptation_access request_services allow all

bypass=0 means: if the ICAP service is unavailable, deny the request rather than allowing unscanned content through. This is the correct setting for a compliance posture.

What a network appliance does NOT cover for compliance

Critical controls outside the network layer:

Encryption at rest: implement at the OS level (LUKS, BitLocker) or database level
MFA: implement at the application layer (identity provider, TOTP)
Data breach notification (72h GDPR / 24h NIS2): organizational process, documented procedures
Business continuity: backup testing, recovery time objectives, documented procedures
Supply chain security: vendor risk assessments, contractual requirements

A gateway UTM satisfies the network security technical controls. The compliance posture requires these additional layers on top.

CacheGuard as implementation

CacheGuard implements the gateway-layer technical controls above — zone firewall, IPsec VPN, gateway antivirus (ClamAV via ICAP with bypass=0), URL filtering, SSL inspection, WAF (ModSecurity + OWASP CRS), and traffic logging — in a single pre-integrated appliance.

→ https://www.cacheguard.com/network-security-compliance-gdpr-nis2/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

pfSense vs Integrated UTM Appliance: Plugin Dependency Graphs, Update Risk, and When Each Architecture Wins

ZeroTrust Architect — Tue, 19 May 2026 09:01:11 +0000

pfSense and OPNsense are the default homelab firewall recommendation. The recommendation is often correct — and sometimes not. The decision depends on understanding the architectural trade-off between the platform model and the integrated appliance model. Here is the technical picture.

The platform model's dependency graph

Reaching full UTM functionality on pfSense/OPNsense requires assembling a plugin stack. Each plugin introduces a dependency node:

pfSense/OPNsense (FreeBSD base)
├── Squid package (web proxy)
│   ├── c-icap (ICAP connector)
│   │   └── ClamAV (antivirus engine)
│   └── ssl-bump (TLS inspection)
│       └── CA certificate (PKI management)
├── SquidGuard or pfBlockerNG (URL filtering)
│   └── Category blocklists (external URLs)
├── Suricata or Snort (IDS/IPS)
│   └── Rule sources (ET, Snort VRT)
└── ModSecurity (WAF — limited integration path)

Each arrow represents a compatibility surface. When the FreeBSD base updates (pfSense 2.x → 2.x+1), each package must also update. If a package maintainer is behind, you have three options:

Skip the FreeBSD update (accumulate security debt)
Update and break the package (lose functionality)
Wait for the package to catch up (delays on your timeline)

The c-icap → ClamAV boundary is particularly fragile. ClamAV major versions (0.103 → 0.104 → 1.x) changed API interfaces that broke c-icap compatibility. The result: after a ClamAV update, the antivirus silently stops scanning traffic — Squid receives no ICAP error, just an empty response, and continues delivering unscanned content.

Detection requires actively monitoring ICAP responses:

# Verify ICAP connectivity and ClamAV health
echo -e "OPTIONS icap://127.0.0.1:1344/squid_clamav ICAP/1.0\r\nHost: 127.0.0.1\r\n\r\n" | nc 127.0.0.1 1344

A healthy response: ICAP/1.0 200 OK. Silent failure: connection refused or no response — but Squid is not told, and content keeps flowing unscanned.

Packet filtering: FreeBSD pf vs Linux nftables

pfSense/OPNsense uses OpenBSD's pf. Last-match-wins semantics, stateful firewall, excellent NAT support:

# pf rule syntax
pass out on em0 proto { tcp, udp } from any to any
block in on em0 proto tcp from <blocklist>

Linux (CacheGuard, custom LFS) uses nftables (or iptables). First-match-wins with explicit jumps, better performance at scale via sets and maps:

# nftables equivalent
nft add rule inet filter input tcp dport { 80, 443 } accept
nft add rule inet filter input ip saddr @blocklist drop

At homelab traffic volumes (< 1 Gbps), neither has a measurable performance advantage. The syntactic differences matter more in practice than the performance characteristics.

The integrated appliance model

An integrated appliance OS ships all UTM components from a single versioned release. The dependency graph collapses:

CacheGuard-OS (custom LFS-based Linux)
└── All components version-locked at release time:
    Squid + ClamAV + c-icap + ModSecurity + StrongSwan + iproute2
    ↑
    Tested together before release. No inter-component compatibility surface.

When CacheGuard updates, the Squid → c-icap → ClamAV chain has been verified by the release process. There is no scenario where ClamAV updates independently and silently breaks ICAP.

Trade-off: you cannot substitute components. If you want a different proxy engine, a custom Suricata ruleset at the config level, or per-packet access to the BSD network stack, the integrated model is a constraint, not a feature.

When to choose which

Choose pfSense/OPNsense if:

Learning network security configuration is the explicit goal (plugin assembly = education)
You need advanced routing (BGP, OSPF, MPLS simulation)
You require IPS with custom Suricata/Snort rules
Your lab simulates enterprise BSD network environments

Choose integrated appliance (CacheGuard) if:

The security layer is infrastructure for other lab work, not the lab work itself
You want a working Squid+ClamAV+WAF stack without integration debugging
You prefer a single update operation over coordinated multi-package updates
You are running a self-hosted homelab with production-like security requirements

Both run on identical x86 hardware. Both are free. Both support multiple network interfaces and VLAN trunking.

→ https://www.cacheguard.com/homelab-firewall/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Full-Tunnel IPsec VPN for Remote Workers: StrongSwan Config, Split vs Full Tunnel, and Gateway Security Stack

ZeroTrust Architect — Tue, 19 May 2026 09:00:19 +0000

Most remote work VPN deployments use split tunneling: only traffic destined for internal corporate IP ranges goes through the VPN tunnel; direct internet traffic bypasses it. This is the wrong default for security. Here is why, and how to configure full-tunnel mode correctly.

Split tunnel vs full tunnel: the security difference

Split tunnel:

Remote device → [VPN tunnel] → Internal resources (192.168.1.0/24)
Remote device → [Direct internet] → Web browsing (no gateway inspection)

Full tunnel:

Remote device → [VPN tunnel] → Gateway → Web browsing (gateway inspection)
Remote device → [VPN tunnel] → Gateway → Internal resources

In split-tunnel mode, a remote worker's web browsing bypasses the office gateway entirely. Gateway antivirus, URL filtering, and traffic logging do not apply. The worker's laptop connects to the office for file access and connects directly to the internet for everything else — with only endpoint security between them and web-borne threats.

Full-tunnel mode routes all traffic through the gateway. The remote worker gets the same gateway-level protections as an on-site employee.

StrongSwan IKEv2 configuration for full tunnel

# /etc/ipsec.conf
conn remote-workers
    keyexchange=ikev2
    left=%any
    leftid=@vpn.example.com
    leftcert=server.crt
    leftsendcert=always
    leftsubnet=0.0.0.0/0    # ← Full tunnel: route ALL traffic through VPN
    leftfirewall=yes

    right=%any
    rightauth=pubkey
    rightsourceip=10.8.0.0/24   # Virtual IP pool for remote workers
    rightdns=10.8.0.1           # Internal DNS resolver

    ike=aes256-sha256-ecp256!
    esp=aes256-sha256!
    dpdaction=restart
    dpddelay=30s
    auto=add

The critical line is leftsubnet=0.0.0.0/0. This tells IKEv2 to install a default route through the tunnel on the client — all traffic, not just traffic to internal subnets, routes through the VPN.

Traffic selectors for full tunnel

In IKEv2, traffic selectors (TS) define which traffic flows through the SA. For full tunnel:

TSi (initiator): 0.0.0.0/0 (all traffic from client)
TSr (responder): 0.0.0.0/0 (to anywhere)

The client installs:

default via 10.8.0.1 dev tun0   # All internet traffic → VPN tunnel
10.8.0.0/24 via tun0            # VPN subnet direct
192.168.1.0/24 via tun0         # Internal LAN

Gateway forwarding for VPN traffic

The gateway must forward VPN client traffic to the internet and apply the same inspection stack as local clients:

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT VPN traffic to external interface
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

# Redirect VPN client HTTP through proxy (same as LAN clients)
iptables -t nat -A PREROUTING -s 10.8.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128

# VPN clients subject to same FORWARD rules as LAN clients
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT

Client profile generation

For iOS/macOS (native IKEv2):

<!-- mobileconfig excerpt -->
<key>VPNType</key>
<string>IKEv2</string>
<key>RemoteAddress</key>
<string>vpn.example.com</string>
<key>RemoteIdentifier</key>
<string>vpn.example.com</string>
<key>LocalIdentifier</key>
<string>worker@example.com</string>
<key>PayloadCertificateUUID</key>
<string><!-- UUID of client cert payload --></string>
<!-- IPv4 routing: send all traffic through VPN -->
<key>IPv4</key>
<dict>
    <key>OverridePrimary</key>
    <integer>1</integer>   <!-- Full tunnel -->
</dict>

For Windows:

Add-VpnConnection -Name "Work VPN" `
  -ServerAddress "vpn.example.com" `
  -TunnelType IKEv2 `
  -AuthenticationMethod MachineCertificate `
  -SplitTunneling $false    # ← Full tunnel: route all traffic

What the remote worker gets

With full-tunnel mode and a properly configured gateway:

Web traffic scanned by gateway antivirus (same as office)
URL filtering applied (same categories and policies as office)
Traffic logged at gateway (same visibility as office)
Internal resources accessible as if on-site

The home network becomes a transport layer. Everything meaningful happens at the gateway.

CacheGuard implements this: IKEv2 VPN with StrongSwan in full-tunnel mode, integrated with the gateway antivirus, URL filtering, and logging stack. Client profiles generated for all major platforms through the web interface.

→ https://www.cacheguard.com/network-security-for-remote-workers/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Enforcing Social Media Blocks at the Proxy Layer: Mandatory Proxy, LDAP Group Policies, and Time-Based ACLs

ZeroTrust Architect — Tue, 19 May 2026 08:59:44 +0000

DNS-based social media blocking fails against DoH-enabled browsers and manual DNS overrides. The reliable approach is enforcement at the proxy layer with mandatory routing. Here is the full technical implementation.

Why DNS filtering cannot reliably block social media

DNS filtering returns NXDOMAIN for blocked domains. Bypass vectors:

Manual DNS override: set 8.8.8.8 on the device → DNS queries bypass your resolver
DNS over HTTPS (DoH): Firefox, Chrome, and Windows 11 can use DoH by default, encrypting DNS queries and sending them to a third-party resolver (Cloudflare, Google) that ignores your blocklist
DNS over TLS (DoT): same bypass mechanism as DoH

Result: on a modern device fleet, DNS-based filtering may already be partially ineffective without any deliberate bypass attempt.

Proxy-layer enforcement architecture

[Client] → [Squid proxy] → [URL filter] → [Internet]
                ↑
    iptables REDIRECT intercepts all HTTP/HTTPS
    (device cannot bypass — traffic physically routed through proxy)

Step 1: Make proxy mandatory with iptables

# Redirect all HTTP traffic to Squid transparent proxy port
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
  ! -d 192.168.1.1 -j REDIRECT --to-port 3128

# Block any HTTPS traffic that doesn't originate from the proxy process (UID 13 = proxy)
# This forces all HTTPS through explicit proxy (CONNECT method)
iptables -A OUTPUT -p tcp --dport 443 -m owner ! --uid-owner 13 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -j DROP

The second rule drops any HTTPS traffic from internal clients that attempts to reach port 443 directly, without going through the proxy. The only path to port 443 on the internet is through Squid's CONNECT handling.

Step 2: Category-based social media blocking in Squid

# /etc/squid/squid.conf

# External URL category database integration
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf

# /etc/squidguard/squidGuard.conf

dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

dest social_networks {
    domainlist social/domains
    urllist    social/urls
}

dest anonymizers {
    domainlist anonymizers/domains
}

# Time-based rule: block during business hours
time workhours {
    M T W H F 09:00-18:00
}

acl {
    default workhours {
        pass !social_networks !anonymizers all
        redirect http://192.168.1.1/blocked.html
    }
    default {
        pass all
    }
}

Step 3: LDAP group-based policies

Different rules for different user groups — marketing team gets social media access, everyone else does not:

# /etc/squidguard/squidGuard.conf — with LDAP group integration

ldapbinddn cn=squidguard,dc=example,dc=com
ldapbindpass secret
ldapprotocol 3
ldapbasedn dc=example,dc=com

src marketing {
    ldapusersearch (&(sAMAccountName=%s)(memberOf=CN=Marketing,OU=Groups,DC=example,DC=com))
}

acl {
    marketing {
        pass all    # Marketing team: unrestricted
    }
    default workhours {
        pass !social_networks !anonymizers all
        redirect http://192.168.1.1/blocked.html
    }
    default {
        pass all
    }
}

Step 4: Block CONNECT to social media domains (HTTPS)

For HTTPS requests, the browser sends a CONNECT request to the proxy before the TLS handshake. Squid evaluates ACLs against the CONNECT target:

acl social_ssl ssl::server_name_regex -i \
    facebook\.com \
    instagram\.com \
    tiktok\.com \
    twitter\.com \
    x\.com \
    linkedin\.com

http_access deny CONNECT social_ssl

Note: category databases handle this more comprehensively than a manual domain list — new social platforms are covered automatically.

Step 5: Block anonymizer/redirector categories

Prevent bypass via web-based proxy services:

acl anonymizers_ssl ssl::server_name_regex -i "/etc/squid/anonymizer_domains.txt"
http_access deny CONNECT anonymizers_ssl

Verification

# Test that direct HTTPS to facebook.com is blocked
curl -v --connect-timeout 5 https://www.facebook.com
# Expected: connection refused or timeout (iptables FORWARD DROP)

# Test that proxy correctly blocks social media
curl -v -x http://192.168.1.1:3128 https://www.facebook.com
# Expected: 403 Forbidden from Squid

CacheGuard implements all of this — mandatory proxy enforcement, category-based blocking, time-of-day rules, and LDAP/AD group policies — through its integrated UTM web interface without manual iptables and SquidGuard configuration.

→ https://www.cacheguard.com/block-social-media-at-work/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Reducing Office Bandwidth With Squid Caching, HTB QoS, and Category Filtering: A Technical Walkthrough

ZeroTrust Architect — Tue, 19 May 2026 08:59:15 +0000

Three techniques reduce office internet bandwidth consumption: web caching (reduce traffic volume), QoS (prioritize what reaches the connection), and content filtering (eliminate unnecessary traffic). Here is the technical implementation of each.

Web caching: Squid configuration and cache hit mechanics

Squid is the standard open-source proxy cache. Cache hit rate — the proportion of requests served from cache — determines actual bandwidth savings.

# /etc/squid/squid.conf — basic caching configuration
cache_mem 512 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs /var/spool/squid 20000 16 256
maximum_object_size 200 MB
minimum_object_size 0 KB

# Cache freshness
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

What drives cache hit rate

The Cache-Control response header determines cacheability:

Cache-Control: max-age=86400      # Cacheable for 24 hours → cache hit on repeat request
Cache-Control: no-store           # Never cached → always fetches from origin
Cache-Control: private            # Browser cache only, not proxy → always fetches

In practice, most SaaS application responses are Cache-Control: no-store or private. Static assets (CSS, JS, images, fonts, software packages) are typically cacheable. Realistic cache hit rates in an office environment: 15-40% of requests by count, but static assets are small — actual bandwidth savings may be 10-25% of bytes transferred.

HTTPS and the SSL inspection requirement

HTTPS traffic is not cacheable without SSL inspection. The proxy cannot read Cache-Control headers in an encrypted response. Enabling ssl-bump (TLS MITM) makes HTTPS content cacheable and dramatically increases hit rates:

# ssl-bump for HTTPS caching
http_port 3128 ssl-bump cert=/etc/squid/ca.pem key=/etc/squid/ca.key
ssl_bump stare all
ssl_bump bump all

# Exempt domains that use certificate pinning
acl no_ssl_bump ssl::server_name_regex -i apple.com google-update.com
ssl_bump splice no_ssl_bump

QoS: HTB + SFQ with tc

HTB (Hierarchical Token Bucket) guarantees bandwidth minimums and allows borrowing from idle classes. SFQ (Stochastic Fairness Queuing) provides per-flow fairness within each class.

# Attach HTB root qdisc to WAN interface
tc qdisc add dev eth0 root handle 1: htb default 30

# Total bandwidth: 100Mbit
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

# Class 1:10 — Real-time (VoIP, video calls): 20Mbit guaranteed, burst to 100Mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20mbit ceil 100mbit prio 1

# Class 1:20 — Business traffic: 70Mbit guaranteed
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 70mbit ceil 100mbit prio 2

# Class 1:30 — Bulk/background: 10Mbit guaranteed, capped at 30Mbit
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 10mbit ceil 30mbit prio 3

# Add SFQ to each leaf class for per-flow fairness
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

# Classify traffic: DSCP EF (VoIP/video) → high priority class
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \
  match ip tos 0xb8 0xfc flowid 1:10

# Classify HTTP/HTTPS to business class
tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 \
  match ip dport 443 0xffff flowid 1:20

# Everything else → bulk class (default 30)

Content filtering: eliminate non-work bandwidth entirely

Category-based URL filtering removes streaming, file-sharing, and social media traffic during business hours — not throttled, eliminated:

# SquidGuard integration for category-based filtering
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf

# /etc/squidguard/squidGuard.conf
dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

dest streaming {
    domainlist streaming/domains
    urllist streaming/urls
}

dest social {
    domainlist social/domains
}

acl {
    # Apply during business hours
    default {
        pass !streaming !social all
        redirect http://gateway/blocked.html
    }
}

Time-based rules restrict blocking to business hours; outside those hours all traffic is permitted.

Combined effect

On a typical 30-person office network:

Web caching (with SSL inspection): 15-30% of bytes served locally
QoS: no bandwidth saved, but VoIP/video call quality maintained under load
Content filtering (streaming blocked 9-18h): 20-40% reduction in peak-hour bytes

The sequence matters: cache first (reduce volume), shape second (manage what remains), filter third (eliminate unnecessary load).

CacheGuard ships Squid, HTB+SFQ QoS, and URL filtering pre-integrated in a single appliance OS, configured through a browser-based interface.

→ https://www.cacheguard.com/reduce-internet-bandwidth-usage-office/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

BYOD Network Security Without MDM: Zone Isolation, MAC Filtering, and Gateway-Level Controls

ZeroTrust Architect — Tue, 19 May 2026 08:58:38 +0000

MDM (Mobile Device Management) solves BYOD security by managing the device. Network-level controls solve it by managing the network around the device. The two approaches have different coverage profiles and different deployment requirements. Here is the technical comparison.

What MDM provides (and what it requires)

MDM enrolls devices into a management platform and can enforce:

Certificate-based Wi-Fi authentication (802.1X/EAP-TLS)
Remote wipe on lost/stolen devices
App installation restrictions and containerization
OS version compliance enforcement
VPN profile distribution and always-on enforcement
Full-disk encryption verification

Requirements: enrollment agent on each device (accepted by the user), MDM server infrastructure (on-premises or cloud), ongoing management as devices change, and employee acceptance of management scope.

For organizations that can meet these requirements, MDM provides the most comprehensive BYOD control. For those that cannot — typically SMEs without dedicated IT staff — the operational overhead is prohibitive and enrollment rates below 100% leave unmanaged devices with no controls at all.

What network-level controls provide without MDM

A zone-based network security appliance at the gateway applies controls to every device that connects, regardless of whether it is enrolled in anything.

VLAN isolation for BYOD devices

Place BYOD devices on a dedicated VLAN, isolated from internal servers and sensitive resources:

# BYOD VLAN (ID 30) on gateway
ip link add link eth1 name eth1.30 type vlan id 30
ip addr add 192.168.30.1/24 dev eth1.30
ip link set eth1.30 up

# Block BYOD from reaching internal LAN by default
iptables -I FORWARD -i eth1.30 -o eth1 -j DROP

# Allow BYOD internet access
iptables -A FORWARD -i eth1.30 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -o eth1.30 -j ACCEPT

Permit only specific internal resources that BYOD devices legitimately need:

# Allow BYOD to reach internal web application only (192.168.1.50:443)
iptables -A FORWARD -i eth1.30 -d 192.168.1.50 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth1.30 -d 192.168.1.50 -m state --state ESTABLISHED,RELATED -j ACCEPT

Gateway antivirus — independent of device endpoint security

Route BYOD web traffic through a proxy with ICAP antivirus scanning. Personal devices may or may not have current endpoint AV — the gateway layer is independent of whatever is or is not on the device.

# Redirect BYOD HTTP to transparent proxy
iptables -t nat -A PREROUTING -i eth1.30 -p tcp --dport 80 -j REDIRECT --to-port 3128

# For HTTPS: require explicit proxy configuration or ssl-bump for transparent interception

URL filtering — policy enforcement without device configuration

A Squid ACL applies URL category filtering to all BYOD traffic without any configuration on the devices:

# Block malware and phishing categories for BYOD VLAN
acl byod_vlan src 192.168.30.0/24
acl blocked_categories dstdom_regex -i "/etc/squid/malware_domains.txt"
http_access deny byod_vlan blocked_categories
http_access allow byod_vlan

Traffic visibility without endpoint agents

Log forwarded traffic from the BYOD VLAN for anomaly detection:

iptables -A FORWARD -i eth1.30 -j LOG --log-prefix "BYOD-FORWARD: "

This gives visibility into what unmanaged personal devices are doing on your network without any software on those devices.

The coverage gap: what network controls cannot do

Control	MDM	Network-level
Remote wipe	✅	❌
App restriction	✅	❌
Disk encryption enforcement	✅	❌
OS version enforcement	✅	❌
Network isolation	✅ (via 802.1X)	✅ (VLAN)
Gateway antivirus	❌	✅
URL filtering	✅ (via VPN)	✅
Traffic logging	✅	✅
Works on non-enrolled devices	❌	✅

Network-level controls are the right baseline for organizations that cannot deploy MDM. They do not replace MDM for organizations that need remote wipe or app containerization.

CacheGuard as implementation

CacheGuard implements BYOD zone isolation, gateway antivirus, URL filtering, and traffic logging through its zone-based UTM architecture — without per-device configuration or enrollment.

→ https://www.cacheguard.com/byod-security-for-small-business/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

IoT Network Isolation: Zone Segmentation, Egress Filtering, and Why Your Smart TV Needs Its Own VLAN

ZeroTrust Architect — Tue, 19 May 2026 08:58:00 +0000

IoT devices cannot protect themselves. They cannot run endpoint security software, enforce their own firewall policies, or detect behavioral anomalies. The only security layer that reliably covers them is one that operates at the network level, independently of what the device can do. Here is how to implement that technically.

The threat model for IoT devices

IoT compromise typically follows one of two paths: exploitation of a known vulnerability in the device's firmware (often never patched by the manufacturer), or brute-force of default or weak credentials via internet-exposed management interfaces.

Once compromised, the device is typically used for:

Botnet participation (DDoS, port scanning, spam relay)
Lateral movement to other devices on the same network segment
Data exfiltration if the device has access to sensitive internal resources
Persistent backdoor installation for long-term access

The key insight: the damage from a compromised IoT device is almost entirely determined by what else it can reach on the network. A compromised camera that can only reach its manufacturer's cloud service causes minimal harm. The same camera with unrestricted access to your file server is a serious breach.

Step 1: VLAN segmentation for IoT isolation

Place IoT devices on a dedicated VLAN, isolated from the internal LAN. The gateway enforces zone policy between VLANs.

# Create IoT VLAN (ID 20) on Linux gateway
ip link add link eth1 name eth1.20 type vlan id 20
ip addr add 192.168.20.1/24 dev eth1.20
ip link set eth1.20 up

# Internal LAN on eth1 (untagged, 192.168.1.0/24)
# IoT VLAN on eth1.20 (tagged, 192.168.20.0/24)

On your managed switch, configure ports connected to IoT devices as access ports on VLAN 20. Ports connected to computers and servers remain on the native VLAN.

Step 2: Default-deny between IoT zone and internal LAN

By default, block all traffic from the IoT VLAN to the internal LAN:

# Drop all forwarded traffic from IoT VLAN to internal LAN
iptables -I FORWARD -i eth1.20 -o eth1 -j DROP

# Allow IoT to reach internet (via external interface eth0)
iptables -A FORWARD -i eth1.20 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -o eth1.20 -j ACCEPT

If specific IoT devices need to reach specific internal resources (e.g., a printer that the internal network needs to reach), add explicit permit rules:

# Allow internal LAN to initiate connections to IoT printer only
iptables -A FORWARD -i eth1 -o eth1.20 -d 192.168.20.10 -p tcp --dport 9100 -j ACCEPT
iptables -A FORWARD -i eth1.20 -s 192.168.20.10 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Step 3: Egress filtering — restrict outbound destinations

Even within the IoT zone, restrict what external destinations each device type can reach. A smart TV should reach streaming service CDNs and its manufacturer's cloud — nothing else.

# Allow specific destination ranges for smart TV (192.168.20.5)
# Block everything else from that device
iptables -A FORWARD -i eth1.20 -s 192.168.20.5 -d 0.0.0.0/0 -j DROP
iptables -I FORWARD -i eth1.20 -s 192.168.20.5 -d 52.0.0.0/8 -j ACCEPT   # AWS (streaming CDNs)
iptables -I FORWARD -i eth1.20 -s 192.168.20.5 -d 17.0.0.0/8 -j ACCEPT   # Apple

For broader category-based egress filtering (blocking known malicious IPs, C2 infrastructure, anonymizers) across the entire IoT VLAN, a URL filtering proxy in the traffic path is more maintainable than per-IP iptables rules.

Step 4: Gateway antivirus via ICAP

To scan traffic from IoT devices for malware (particularly relevant for devices that download firmware updates), route IoT web traffic through a Squid proxy with ICAP-based ClamAV scanning:

# squid.conf — transparent proxy for IoT VLAN
http_port 3128 intercept

# ICAP antivirus
icap_enable on
icap_service av_service reqmod_precache bypass=1 icap://127.0.0.1:1344/squid_clamav
adaptation_service_set av_service_set av_service
adaptation_access av_service_set allow all

Redirect IoT VLAN HTTP traffic to the proxy:

iptables -t nat -A PREROUTING -i eth1.20 -p tcp --dport 80 -j REDIRECT --to-port 3128

For HTTPS (dominant in modern IoT), transparent interception requires SSL inspection (ssl-bump). Without it, HTTPS traffic from IoT devices is tunneled uninspected.

Step 5: Traffic logging for anomaly detection

Log connection attempts from the IoT VLAN to destinations outside permitted ranges:

# Log dropped IoT traffic for anomaly detection
iptables -A FORWARD -i eth1.20 -j LOG --log-prefix "IoT-FORWARD-DROP: " --log-level 4
iptables -A FORWARD -i eth1.20 -j DROP

Unusual patterns — a camera suddenly connecting to dozens of external IPs it has never contacted before, or an IoT device attempting connections to internal LAN ranges — are detectable in these logs before they escalate.

CacheGuard as a pre-integrated implementation

CacheGuard ships all of the above pre-integrated: zone-based firewall (external, internal/web with rweb VLAN, auxiliary/IoT zones), Squid transparent proxy with ICAP-based ClamAV, URL category filtering for egress control, and traffic logging — without manual iptables, Squid, and c-icap assembly.

→ https://www.cacheguard.com/secure-iot-devices-on-your-network/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Network-Level Parental Controls: Enforcing Web Filtering With a Proxy, Firewall Rules, and an Always-On VPN

ZeroTrust Architect — Tue, 19 May 2026 08:57:19 +0000

Device-level parental controls — Screen Time, Family Link, router DNS filtering — share a common architectural weakness: they can all be bypassed by routing traffic around the enforcement point. This guide covers a network-level approach that closes those gaps technically.

Why DNS-based filtering fails first

Most home router parental controls work at the DNS layer. The router intercepts DNS queries and returns NXDOMAIN or a block page IP for blacklisted domains. The bypass is trivial:

# Child changes DNS on their device
networksetup -setdnsservers Wi-Fi 8.8.8.8    # macOS
# or simply sets 1.1.1.1 in Android/iOS network settings

No DNS query hits the router. The filter never sees the request. DNS filtering provides zero protection against a user who controls their own DNS resolver.

The proxy interception model

A forward proxy operating at the HTTP application layer is bypass-resistant by a different mechanism. Traffic must physically pass through the proxy to reach the internet — there is no DNS-level workaround because the proxy intercepts at Layer 7, not Layer 3.

In explicit proxy mode, client devices are configured to send all HTTP and HTTPS requests to the proxy. HTTPS connections use the HTTP CONNECT method:

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443

The proxy sees the full destination URL in plaintext before any TLS handshake — enabling URL category filtering on HTTPS traffic without SSL decryption. If the destination matches a blocked category, the proxy returns:

HTTP/1.1 403 Forbidden

No content is delivered. No TLS session is established.

Making the proxy mandatory with a firewall rule

Explicit proxy mode relies on client configuration — and a determined child can simply remove the proxy settings from their device. The fix is a firewall rule that makes bypassing the proxy impossible:

# Block all outbound HTTPS traffic that does NOT originate from the proxy process
# On the gateway, assuming proxy runs as user 'proxy' (UID 13 on Debian)
iptables -t nat -A OUTPUT -p tcp --dport 443 -m owner ! --uid-owner 13 -j REDIRECT --to-port 3128
iptables -A FORWARD -p tcp --dport 443 -j DROP

The second rule drops any HTTPS traffic forwarded from internal clients that attempts to bypass the proxy. The client gets a connection timeout. The only path to port 443 on the internet is through the proxy — which applies the content filter.

With Squid as the proxy engine, transparent interception for HTTP is straightforward:

# Redirect internal HTTP traffic to Squid transparent port
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

For HTTPS in transparent mode, SNI-based filtering is possible but limited to hostname-level blocking. For full URL-path filtering on HTTPS, explicit mode with the CONNECT method is required.

Blocking anonymizer and redirector categories

Web-based proxy and anonymizer services — sites that let users route traffic through external servers — bypass local filtering regardless of proxy enforcement, because the destination URL appears to be a legitimate website.

The mitigation is category-based blocking. Most URL category databases include an anonymizer or proxy category. In Squid with SquidGuard:

# squidguard.conf
dest anonymizers {
    domainlist anonymizers/domains
    urllist anonymizers/urls
}

acl {
    default {
        pass !anonymizers all
        redirect http://gateway/blocked.html
    }
}

This blocks access to known anonymizer domains before the child can use them to route around the content filter.

Extending filtering to mobile devices outside the home

Home gateway filtering only applies when devices are on the home network. When a child's smartphone switches to mobile data or a friend's hotspot, the gateway is bypassed entirely.

The solution is an IPsec VPN server on the home gateway. Client devices connect to the VPN using IKEv2 with the gateway's certificate, routing all traffic through the home network — and through the web proxy — regardless of the underlying connection.

StrongSwan server configuration (relevant excerpt):

conn parental-vpn
    keyexchange=ikev2
    left=%any
    leftid=@home.example.com
    leftcert=gateway-cert.pem
    leftsubnet=0.0.0.0/0      # Route all client traffic through gateway
    right=%any
    rightsourceip=10.9.0.0/24  # Virtual IPs for VPN clients
    rightdns=10.9.0.1
    ike=aes256-sha256-ecp256!
    esp=aes256-sha256!
    auto=add

The leftsubnet=0.0.0.0/0 directive routes all client internet traffic through the VPN tunnel — not just traffic destined for the home network. Once the VPN client connects, all outbound traffic hits the gateway proxy and is filtered identically to home network traffic.

Enforcing always-on VPN on client devices:

On iOS, a configuration profile with OnDemandEnabled=1 and OnDemandRules set to activate on any network connection enforces the VPN without user interaction. The profile can be locked via Mobile Device Management or restricted using Screen Time's VPN settings control.

On Android, Settings → Network → VPN → [profile] → Always-on VPN with Block connections without VPN enabled drops all traffic if the VPN is not active — no internet access without the tunnel.

URL blacklist management

The content filter requires a category database mapping URLs to content categories. Options range from free community-maintained lists to commercially updated subscription databases.

For a home deployment, the choice matters primarily on two dimensions: coverage (how many URLs are categorized, particularly for adult content) and update frequency (how quickly newly registered adult/malicious domains are added).

Free lists are adequate for blocking well-established categories but lag significantly on newly registered domains — a common technique used to evade filters. A subscription database with daily or hourly updates provides meaningfully better coverage for the adult content category specifically.

CacheGuard as a complete implementation

CacheGuard is a free, open-source network security appliance (LFS-based Linux) that ships all of the above pre-integrated:

Squid-based web proxy with URL filtering (explicit and transparent modes)
IPsec VPN server (StrongSwan, IKEv2) with client profile generation for iOS, macOS, Android, Windows, Linux
Zone-based stateful firewall with built-in rules for mandatory proxy enforcement
SSL mediation (Squid ssl-bump) for full HTTPS content inspection
Optional URL blacklist subscription with regularly updated category databases
Browser-based management interface — no CLI required for standard configuration

It installs from a single ISO on any x86 machine or VM. The firewall rules enforcing mandatory proxy use and blocking direct HTTPS forwarding are configurable through the web interface without writing iptables commands manually.

For parents who are comfortable with basic network concepts but do not want to assemble Squid, StrongSwan, iptables, and a PKI from scratch, it eliminates the integration overhead while remaining fully open source and free.

→ https://www.cacheguard.com/parental-controls-home-network/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Host-Based vs Network Firewall: Why Windows Firewall and Windows Defender Are Not Enough on Their Own

ZeroTrust Architect — Sun, 17 May 2026 10:10:23 +0000

Most Windows networks rely on two built-in security tools: Windows Firewall (Microsoft Defender Firewall) and Windows Defender. Both are enabled by default, both are maintained by Microsoft, and both are useful. Neither is a network firewall.

Understanding why that distinction matters requires looking at where each tool operates in the security stack — and what attack surface they share.

Host-based vs network-level security: the architectural difference

Windows Firewall is a host-based stateful packet filter. It runs inside the Windows kernel via the Windows Filtering Platform (WFP). It applies rules to traffic arriving at or leaving the specific machine it runs on. It has no visibility into traffic between other devices on the same network segment.

Windows Defender is an endpoint antivirus and EDR solution. It scans files and processes on the machine it runs on. It operates after content has been delivered to the host — it is a post-arrival scanner, not a network-level interceptor.

Both tools share the same attack surface: the Windows kernel, the Windows userspace, and the Windows security subsystem. A privilege escalation exploit, a kernel vulnerability, or a malicious driver that compromises the OS can potentially disable or circumvent both simultaneously — because both live inside the environment being attacked.

[Windows machine]
  ├── Windows Kernel (WFP)
  │     └── Windows Firewall rules ← same attack surface
  └── Windows Defender service   ← same attack surface

What neither tool covers

Other devices on the LAN: Windows Firewall protects the machine it runs on. Printers, NAS devices, IoT sensors, smart TVs, mobile phones, and macOS/Linux machines on the same network segment receive no protection from it. Each device is responsible for its own defenses — if it has any.

Network-level traffic interception: Windows Firewall can allow or deny connections based on IP, port, and application. It cannot act as a proxy — it does not intercept, inspect, or modify traffic flows between internal machines and the internet. It has no concept of a web proxy CONNECT chain, no gateway antivirus scanning, and no URL filtering at the network level.

DoS flood protection at the perimeter: Windows implements SynAttackProtect at the TCP/IP stack level — a self-defense mechanism that adjusts SYN-ACK retransmission behavior when the local machine detects it is under a SYN flood. This protects that one machine's TCP stack. It does not rate-limit or absorb flood traffic before it reaches other devices on the LAN. In a network with no perimeter appliance, each device must defend itself individually.

The Defense in Depth problem: heterogeneous layers

NIST defines Defense in Depth as "layering heterogeneous security technologies in the common attack vectors to ensure that attacks missed by one technology are caught by another."

The operative word is heterogeneous. Two security tools that share an OS, a kernel, and an attack surface are not two independent layers — they are the same layer with two names. Compromising the shared substrate compromises both.

A Linux-based network appliance sitting at the perimeter provides genuine architectural independence:

[Internet]
     |
[Linux network appliance]   ← independent OS, independent kernel
     |                          no shared attack surface with Windows
[LAN switch]
     |
[Windows machines]
  ├── Windows Firewall     ← last line of defense
  └── Windows Defender     ← last line of defense

An attacker who achieves kernel-level code execution on a Windows machine has no leverage over the Linux appliance. Different syscall interface, different process model, different binary format, different network stack implementation. The independence is architectural, not cosmetic.

What a network appliance adds at each layer

Perimeter firewall (zone-based): The appliance enforces a default-deny policy on all unsolicited inbound connections from the external zone to the internal LAN — covering every device behind it regardless of OS. This is not per-machine configuration — it is a single policy applied at the chokepoint.

Web proxy (HTTP CONNECT chain): Internal machines route web traffic through the proxy rather than connecting directly to upstream servers. In explicit proxy mode, HTTPS connections use the HTTP CONNECT method — the proxy sees the full destination URL in plaintext before the TLS handshake, enabling URL filtering without SSL decryption.

Gateway antivirus: Traffic passing through the proxy is scanned by an antivirus engine (ClamAV in the case of CacheGuard) before delivery to any device. This is a pre-arrival scanner, operating at a different point in the traffic flow than Windows Defender and on a completely independent codebase.

Perimeter DoS protection: The appliance rate-limits SYN floods, RST floods, and UDP floods at the network boundary using iptables rate-limiting rules — absorbing and dropping flood traffic before it reaches the LAN switch and propagates to individual devices.

# Conceptual iptables rate-limiting for SYN flood at perimeter
iptables -A FORWARD -p tcp --syn -m limit --limit 100/s --limit-burst 150 -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP

CacheGuard as a concrete implementation

CacheGuard is a free, open-source network security appliance built on a custom Linux distribution (LFS-based) that has been in active development since 2002. It implements all of the above in a single integrated OS image:

Zone-based stateful firewall (external, internal/web, vpnipsec, auxiliary zones)
Web proxy with URL filtering (Squid + category databases)
Gateway antivirus (ClamAV via ICAP)
SSL mediation (Squid ssl-bump)
IPsec VPN (StrongSwan, IKEv2)
QoS (HTB + SFQ via iproute2)
Web caching (Squid)
Built-in DoS protection (SYN flood, RST flood, UDP flood, bogon filtering, brute force protection)

It installs on any x86 machine or VM. Configuration is through a browser-based interface — no CLI required for standard deployments.

The correct mental model is not "CacheGuard instead of Windows Firewall" but "CacheGuard at the network boundary + Windows Firewall on each endpoint." Two independent layers, two different OS stacks, two different interception points. This is what Defense in Depth actually looks like in a small network.

→ https://www.cacheguard.com/is-windows-firewall-enough/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.