DEV Community: ZeroTrust Architect

IPsec vs TLS VPN: Protocol Mechanics, Port Behaviour, and When Each One Breaks

ZeroTrust Architect — Thu, 07 May 2026 11:58:43 +0000

Both IPsec and TLS VPNs encrypt traffic between endpoints. The difference is where in the protocol stack they operate and what that implies for performance, firewall traversal, and failure modes.

IPsec: network-layer encryption

IPsec operates at OSI Layer 3. It encrypts IP packets entirely, including headers in tunnel mode, and delivers them inside new IP packets. The protocol suite has three components:

IKE (Internet Key Exchange): Handles authentication and SA (Security Association) negotiation. Uses UDP/500 for initial contact, switches to UDP/4500 if NAT is detected (NAT-T).
ESP (Encapsulating Security Payload): Provides encryption and authentication of the payload. IP protocol number 50.
AH (Authentication Header): Authentication only, no encryption. Protocol number 51. Rarely used in modern deployments.

IKE phase negotiation

IKEv2 (RFC 7296) reduces the handshake to two exchanges:

IKE_SA_INIT: Peers negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman key exchange. Result: an IKE SA protecting subsequent messages.

IKE_AUTH: Peers authenticate each other (via certificates or PSK) and establish the first Child SA (the actual IPsec tunnel). Result: an ESP SA ready to carry traffic.

Initiator                    Responder
    |-- IKE_SA_INIT request -->|
    |<- IKE_SA_INIT response --|
    |-- IKE_AUTH request ------>|
    |<- IKE_AUTH response ------|
    |=== ESP tunnel active ====|

NAT traversal

IPsec was designed before NAT was widespread. When a NAT device sits between peers, ESP packets can be mangled (NAT rewrites IP headers but ESP authenticates them, causing verification failure). NAT-T solves this by encapsulating ESP inside UDP/4500, making the payload opaque to NAT devices.

Detection happens during IKE_SA_INIT: if either peer detects a NAT (via NAT-D payload hash comparison), both switch to UDP/4500 for all subsequent communication.

TLS VPN: application-layer tunnelling

TLS VPNs (OpenVPN, SSL VPN) run over TCP or UDP at the application layer. They establish a TLS session first, then tunnel IP traffic through it.

Key difference: TLS uses TCP/443 or UDP/443 by default — the same ports as HTTPS. Firewalls and restrictive networks almost never block port 443, making TLS VPNs significantly more traversal-friendly than IPsec.

The trade-off is performance. TLS over TCP introduces TCP-over-TCP — when the tunnelled TCP connection retransmits, the outer TCP also retransmits, causing retransmit storms under packet loss. TLS over UDP avoids this but is less universally available.

Port and firewall traversal comparison

Protocol	Ports used	Firewall blocked?	NAT behaviour
IKEv2/IPsec	UDP/500, UDP/4500, ESP (IP 50)	Sometimes	Requires NAT-T
IKEv1/IPsec	UDP/500, UDP/4500 or AH/ESP	Sometimes	Requires NAT-T
OpenVPN (UDP)	UDP/1194 (configurable)	Sometimes	Generally fine
TLS VPN	TCP/443 or UDP/443	Rarely	Always fine

When IPsec fails and TLS doesn't

Corporate guest networks, hotel WiFi, and some mobile carriers actively block UDP/500 and UDP/4500, preventing IKEv2 negotiation from completing. ESP (protocol 50) may also be filtered. In these environments, IPsec connections time out silently while TLS-based connections on port 443 succeed.

When to use which

IPsec is the right choice for:

Site-to-site tunnels between fixed endpoints (no port blocking concerns)
Remote access on managed device fleets where client software can be deployed
High-throughput requirements (lower per-packet overhead than TLS)
Environments where all platforms need to use the native OS VPN client (iOS, macOS, Windows, Android all have native IKEv2 clients)

TLS VPN is the right choice for:

Environments with aggressive outbound filtering (hotels, corporate guest networks, restrictive countries)
Clientless access where users connect via a browser
Scenarios where per-user application-level access control is needed (TLS VPNs make per-app policy easier)

CacheGuard implements IPsec VPN using IKEv2 with ESP in tunnel mode, powered by StrongSwan. It supports certificate-based and PSK authentication, generates client profiles for all major platforms, and includes DynDNS integration for deployments without a fixed public IP.

→ https://www.cacheguard.com/ipsec-vs-ssl-vpn/

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

TLS Handshake to Reverse Proxy: How HTTPS Works End-to-End in a Production Network

ZeroTrust Architect — Thu, 07 May 2026 11:56:05 +0000

When a browser connects to https://example.com, a series of cryptographic operations happen before a single byte of application data is exchanged. Understanding this sequence is necessary for debugging TLS issues, configuring reverse proxies correctly, and reasoning about what SSL termination actually changes.

The TLS 1.3 handshake

TLS 1.3 (RFC 8446) reduced the handshake from TLS 1.2's two round trips to one. Here is the full sequence:

Client                                Server
  |                                      |
  |-- ClientHello ---------------------->|  (supported ciphers, key share, SNI)
  |<-- ServerHello ----------------------|  (chosen cipher, key share)
  |<-- {EncryptedExtensions} -----------|
  |<-- {Certificate} -------------------|
  |<-- {CertificateVerify} -------------|
  |<-- {Finished} ----------------------|
  |-- {Finished} ----------------------->|
  |                                      |
  |=== Application data (encrypted) ====|

After the first round trip, both sides derive the same session keys from their respective key shares (ECDH). The server's certificate is transmitted inside the encrypted portion of the handshake — an improvement over TLS 1.2 where the certificate was sent in plaintext.

Certificate chain validation

The server sends its certificate chain — end-entity cert, optional intermediate(s), root. The client validates:

Signature chain: Each certificate is signed by the issuer above it, terminating at a trusted root CA in the system trust store.
Name matching: The Subject Alternative Name (SAN) or CN matches the hostname in the request.
Validity period: notBefore and notAfter fields are within the current time.
Revocation status: Via OCSP or CRL (if the client checks — many do not by default).

If any check fails, the browser terminates the connection and displays an error. The specific error code (expired, wrong host, untrusted CA) determines the error page shown.

What changes with a reverse proxy

When a reverse proxy sits in front of your backend, SSL termination moves from the backend to the proxy. The client's TLS session terminates at the proxy, not at the application server.

[Browser] <-- TLS --> [Reverse Proxy] <-- HTTP or TLS --> [Backend]

The certificate presented to the browser belongs to the proxy, not the backend. The proxy forwards the request to the backend — either over plain HTTP on a trusted private network or over a new TLS connection using the backend's certificate.

What the backend loses

Without SSL termination at the proxy, the backend receives the client's IP in the TCP source address. With SSL termination, the TCP connection comes from the proxy's IP. The original client IP must be forwarded in an X-Forwarded-For or X-Real-IP header, and the backend must be configured to trust this header only from the proxy's IP range.

X-Forwarded-For: 203.0.113.42
X-Forwarded-Proto: https
X-Real-IP: 203.0.113.42

Backends that naively trust X-Forwarded-For from any source are vulnerable to IP spoofing.

Session persistence in load-balanced deployments

When the reverse proxy load-balances across multiple backends, stateful applications (anything with server-side sessions) require session persistence — routing all requests from the same client to the same backend. This is typically implemented via a session cookie that encodes the backend assignment.

SSL termination vs SSL passthrough

Termination: The proxy decrypts traffic, inspects/transforms it, and forwards. Enables WAF rules, header injection, caching. Requires the proxy to hold the certificate private key.

Passthrough: The proxy forwards the encrypted TCP stream without decryption, based on SNI alone. The backend holds the key. The proxy cannot inspect or modify content.

Re-encryption: The proxy terminates the client TLS session and opens a new TLS session to the backend. End-to-end encryption with proxy visibility. Higher CPU cost.

High availability for the proxy layer

The reverse proxy becomes a single point of failure. HA is typically implemented with VRRP (Virtual Router Redundancy Protocol) — two proxy instances share a virtual IP. The active instance holds the VIP; if it fails, the standby takes over within seconds.

CacheGuard implements reverse proxy SSL termination via Apache mod_proxy, with integrated WAF (ModSecurity + OWASP CRS), load balancing with session persistence, and native HA mode for multi-appliance deployments. Certificate management and PKI operations are handled through the web interface.

→ https://www.cacheguard.com/how-https-works/

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

TLS Interception at the Gateway: Certificate Chains, SNI, and the SSL Pinning Problem

ZeroTrust Architect — Thu, 07 May 2026 11:52:30 +0000

TLS inspection at a forward proxy — sometimes called SSL interception or SSL mediation — is a controlled man-in-the-middle. The proxy terminates the client's TLS session, reads the plaintext, and opens a new TLS session to the upstream server. Understanding the mechanics matters for deployment, debugging, and reasoning about what the proxy can and cannot see.

The certificate generation pipeline

When the proxy intercepts a CONNECT request for www.example.com:443, it must present a certificate for www.example.com to the client — a certificate the client's browser will accept. Generating this on the fly requires:

The proxy fetches the real certificate from www.example.com (or uses cached metadata)
It extracts the Subject Alternative Names and CN from the real cert
It generates a new certificate with matching SANs, signed by the proxy's local CA
It presents this dynamically generated certificate to the client

The client browser validates the chain: generated cert → proxy CA → (trusted if proxy CA is in browser trust store). If the proxy CA is not trusted, the browser throws NET::ERR_CERT_AUTHORITY_INVALID.

CA distribution

The proxy CA must be added to every client's trust store before enabling TLS inspection. Deployment methods:

Windows (domain-joined): Group Policy Object → Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.

# Verify CA is present after GPO application
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*CacheGuard*" }

macOS (MDM): Push CA cert via configuration profile → PayloadType: com.apple.security.root.

Linux (system-wide):

cp proxy-ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

Firefox: Firefox maintains its own trust store independent of the OS. The CA must be added separately via policies (certificates.certs[] in policies.json) or manually.

SNI and the hostname visibility problem

In TLS 1.3, the client sends the server_name extension (SNI) in the ClientHello. The SNI is transmitted in plaintext — the proxy sees it without decryption. This means the proxy knows which hostname the client is connecting to even before the TLS handshake completes, regardless of whether inspection is enabled.

With inspection enabled, the proxy can additionally see:

The full HTTP request line and headers
The request body
The full HTTP response headers and body

Without inspection, the proxy sees only: SNI (hostname), destination IP, port, and approximate traffic volume.

SSL pinning: the hard case

SSL pinning is a client-side mechanism where an application refuses any TLS certificate except a specifically expected one (or one signed by a specifically expected CA). The application ignores the OS trust store.

When the proxy presents its dynamically generated certificate for api.bank.com, a pinned application compares the certificate fingerprint (or CA public key) against its embedded expectation. They do not match. The application refuses to connect.

Common pinning implementations:

Certificate pinning: Exact certificate fingerprint match
Public key pinning: CA or leaf public key hash match (more flexible — survives certificate renewal if the key doesn't change)
HPKP (deprecated): Browser-level public key pinning via HTTP header

Handling pinned applications at the proxy:

The only correct solution is an exception — the proxy bypasses TLS inspection for pinned destinations, allowing them to connect directly.

# Squid: exempt pinned destinations from ssl-bump
acl ssl_no_bump_domains ssl::server_name_regex -i \
    api.bank.com \
    pin.cloudflare.com \
    apple.com

ssl_bump splice ssl_no_bump_domains
ssl_bump stare all
ssl_bump bump all

Identifying pinned applications requires monitoring your proxy logs for SSL certificate error events after enabling inspection — these are usually pinning failures.

What the proxy cannot see even with inspection

ESNI/ECH (Encrypted Client Hello): Encrypts the SNI itself using a public key published in DNS. The proxy sees only the encrypted outer hello. Full deployment is not yet universal (2026) but growing.
Certificate Transparency logs: CT does not affect proxy visibility, but it means all dynamically generated certificates would appear in CT logs if submitted — they are not (proxy CAs are not CT-logging).
mTLS (mutual TLS): If the upstream requires a client certificate from the actual end device, the proxy cannot satisfy this requirement without the client's private key.

CacheGuard calls this feature SSL mediation. It generates the local CA at installation, provides a download link for the CA cert to push to clients, and maintains a bypass list for pinned domains.

→ https://www.cacheguard.com/ssl-inspection/

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

How HTTPS Works: A Simple Explanation of Secure Web Communication

ZeroTrust Architect — Thu, 07 May 2026 11:27:35 +0000

Every time you visit a website and see a padlock icon in your browser, HTTPS is working behind the scenes to protect your data.

Although it feels instant and invisible, HTTPS relies on a carefully designed security process involving encryption, authentication, and trust verification.

This article explains how HTTPS works in a clear and practical way.

What is HTTPS?

HTTPS (HyperText Transfer Protocol Secure) is the secure version of HTTP.

It encrypts communication between a web browser and a server using TLS (Transport Layer Security), ensuring that data cannot be easily intercepted or modified during transmission. :contentReference[oaicite:0]{index=0}

In simple terms, HTTPS makes sure your connection to a website is private and trustworthy.

Why HTTPS is important

Without HTTPS, data sent over the internet is transmitted in plain text.

This means attackers on the same network could:

read sensitive information
modify data in transit
impersonate websites

HTTPS protects against these risks by providing:

confidentiality (data is encrypted)
integrity (data cannot be tampered with)
authentication (you are connected to the correct server) :contentReference[oaicite:1]{index=1}

How HTTPS works at a high level

When you visit an HTTPS website, your browser and the server perform a sequence of steps:

The browser connects to the server
The server presents a digital certificate
The browser verifies the certificate
Both sides agree on encryption methods
A secure connection is established

Once this process is complete, all communication becomes encrypted.

The role of TLS (the encryption layer)

HTTPS is not a separate protocol from HTTP—it is HTTP running over TLS.

TLS is responsible for:

encrypting data
verifying server identity
ensuring message integrity

This is what actually creates the secure channel between your browser and the website. :contentReference[oaicite:2]{index=2}

The TLS handshake (step-by-step)

The most important part of HTTPS is the TLS handshake.

Here’s what happens:

1. Client Hello

Your browser sends a message to the server listing supported encryption methods.

2. Server Response

The server responds with:

its SSL/TLS certificate
its chosen encryption settings

3. Certificate verification

Your browser checks:

if the certificate is valid
if it is issued by a trusted certificate authority

4. Key exchange

Both sides generate shared encryption keys using public-key cryptography.

5. Secure session begins

All future communication is encrypted using symmetric encryption keys.

From this point on, everything is secure.

How encryption actually protects your data

HTTPS uses a combination of:

Public-key cryptography

Used during the handshake to securely exchange keys.

Symmetric encryption

Used for actual data transfer because it is faster.

This hybrid approach ensures both security and performance.

What data HTTPS protects

HTTPS encrypts nearly everything exchanged between browser and server, including:

URLs and query strings
form submissions
login credentials
cookies
API requests and responses :contentReference[oaicite:3]{index=3}

What HTTPS does NOT protect

HTTPS does not hide everything. For example:

the domain name (e.g. example.com) is still visible
metadata like timing and traffic volume may be observable
compromised endpoints can still leak data

HTTPS protects the transmission, not the endpoint itself.

Why HTTPS is now the default

Today, HTTPS is no longer optional.

Modern browsers:

label HTTP sites as “Not secure”
prioritise HTTPS in search rankings
enforce secure-by-default behaviour in many cases

As a result, most of the web now runs on HTTPS by default.

Conclusion

HTTPS is the foundation of secure communication on the web.

It works by combining encryption, certificates, and a handshake process that establishes trust between your browser and a server.

While invisible to users, it plays a critical role in protecting privacy, preventing tampering, and ensuring the integrity of modern internet communication.

Original article

This post is adapted from the original article published on CacheGuard:

https://www.cacheguard.com/how-https-works/

IPsec vs SSL VPN: What’s the Difference and Which One Should You Use?

ZeroTrust Architect — Thu, 07 May 2026 11:22:47 +0000

When setting up remote access or site-to-site connectivity, two VPN technologies are almost always compared: IPsec and SSL VPN.

Both provide secure encrypted communication over untrusted networks like the internet, but they differ in architecture, performance, and ideal use cases.

This article breaks down the differences in a practical way so you can understand when to use each.

What is IPsec VPN?

IPsec (Internet Protocol Security) is a suite of protocols that secures IP communications by encrypting and authenticating data at the network layer (Layer 3).

It works by protecting entire IP packets between two endpoints, typically forming a secure tunnel between networks or devices. :contentReference[oaicite:0]{index=0}

In simple terms, IPsec makes two networks behave as if they are directly connected over a private link.

What is SSL VPN?

SSL VPN (more accurately TLS-based VPN) operates at a higher layer in the network stack, typically between the transport and application layers.

Instead of tunnelling full networks, it often secures individual sessions or application traffic. :contentReference[oaicite:1]{index=1}

This makes it more flexible for remote access scenarios where users only need access to specific services.

IPsec vs SSL VPN: Key differences

1. OSI layer

IPsec → Layer 3 (Network layer)
SSL VPN → Layer 4–7 (Transport/Application layer) :contentReference[oaicite:2]{index=2}

This is the fundamental architectural difference.

2. Traffic scope

IPsec → encrypts all IP traffic
SSL VPN → encrypts specific applications or sessions

IPsec provides full network connectivity, while SSL VPN is more selective.

3. Client requirements

IPsec → usually requires a VPN client or native OS support
SSL VPN → often browser-based or lightweight client

This makes SSL VPN easier for quick access scenarios.

4. Firewall traversal

IPsec → may be blocked by strict firewalls (uses specific ports/protocols)
SSL VPN → uses HTTPS (port 443), making it easier to pass through restricted networks :contentReference[oaicite:3]{index=3}

This is one of SSL VPN’s biggest advantages.

5. Performance

IPsec → generally higher performance and lower overhead
SSL VPN → slightly higher overhead due to application-layer processing :contentReference[oaicite:4]{index=4}

IPsec is often preferred for full network tunnels and high-throughput environments.

6. Typical use cases

IPsec VPN is best for:

site-to-site VPNs
full network access
enterprise infrastructure connectivity

SSL VPN is best for:

remote user access
BYOD environments
situations where firewall traversal is critical

Security comparison

Both IPsec and SSL VPN are considered secure when properly configured.

However:

IPsec secures the entire network layer tunnel
SSL VPN secures application-level sessions

The actual security level depends more on configuration than protocol choice.

IPsec vs SSL VPN in real-world deployments

In practice:

Enterprises often use IPsec for site-to-site VPNs
SSL VPN is commonly used for remote access users
Many organisations use both together, depending on access needs

This hybrid approach is very common in modern network architectures.

When to choose IPsec

Choose IPsec if you need:

full network connectivity
high performance tunnels
stable site-to-site connections
OS-level integration

When to choose SSL VPN

Choose SSL VPN if you need:

easy remote access for users
access through restrictive networks
minimal client installation
application-specific access

Conclusion

IPsec and SSL VPN are not competing technologies in a strict sense—they solve different networking problems.

IPsec focuses on secure network-to-network communication
SSL VPN focuses on flexible remote user access

In modern environments, they are often used together rather than as replacements for one another.

Original article

This post is adapted from the original article published on CacheGuard:

https://www.cacheguard.com/ipsec-vs-ssl-vpn/

Endian Firewall's Fork Lineage and Feature Gaps: A Technical Assessment

ZeroTrust Architect — Thu, 07 May 2026 11:17:47 +0000

Endian Firewall is a Linux-based UTM with a specific codebase history and a set of architectural limitations that matter when evaluating it as a long-term platform. Here is the technical picture.

The fork lineage

SmoothWall (2000) → GPL Linux firewall distribution
    └── IPCop (2001) → fork of SmoothWall
            └── Endian Firewall (2003) → fork of IPCop

Each fork inherited the parent's codebase and added features on top. This is not inherently a problem — Linux distributions commonly derive from upstream sources. But it means Endian carries code decisions made in 2000 and 2001, and architectural choices made during the SmoothWall era are baked into the foundation.

CacheGuard by contrast was built from LFS (Linux From Scratch) beginning in 2002 — no upstream project's architectural decisions inherited, no legacy code from previous projects.

Feature gap analysis

No WAF

Neither Endian Firewall Community nor Endian UTM (commercial) includes a Web Application Firewall. ModSecurity and the OWASP Core Rule Set are not shipped or integrated.

Impact: Any organisation running web-facing applications — customer portals, APIs, SaaS interfaces — needs WAF protection that Endian cannot provide. The options are to deploy a separate WAF (adding infrastructure complexity) or accept that web application attacks reach the application layer unfiltered.

No reverse proxy / load balancer

Endian does not include a reverse proxy engine. Organisations running multiple backend servers cannot use Endian as the SSL termination and load balancing point.

Impact: Web application deployments that need SSL offloading, load distribution, and application-layer routing must introduce a separate reverse proxy alongside Endian — two management interfaces, two certificate stores, two update targets.

IPS included (but vendor focus is shifting)

Endian includes an IPS (intrusion prevention system) — a capability CacheGuard does not provide. However, Endian's commercial development has shifted toward industrial OT/ICS security use cases, meaning the IPS and other features are increasingly developed for SCADA/industrial environments rather than general SMB use.

If your use case is standard office network security, you are paying for — and implicitly funding the development of — features aligned with a different market segment.

Endian Community vs Endian UTM: the feature tier problem

Endian Community (free) lacks several features present in Endian UTM (paid):

Advanced web content filtering
Email security and anti-spam
Centralised management
Vendor support

This creates a two-tier model where the free version is insufficient for production use but the commercial version requires subscription licensing. For SMBs evaluating open-source options, this is a meaningful distinction.

CacheGuard as technical comparison

CacheGuard ships the full UTM feature set in the free version — no tier above it, no subscription required for security features:

Feature	Endian Community	Endian UTM	CacheGuard
WAF	❌	❌	✅ ModSecurity + OWASP CRS
Reverse proxy	❌	❌	✅ Apache mod_proxy
Load balancer	❌ Basic	✅	✅
SSL inspection	⚠️ Limited	✅	✅
IPS	✅	✅	❌
Email security	✅	✅	❌
Codebase origin	Fork of IPCop	Fork of IPCop	LFS from scratch
Cost	Free	Subscription	Free

→ https://www.cacheguard.com/endian-firewall-alternative/

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

Smoothwall Express in 2026: What "No Major Release Since 2014" Means for a Security Appliance

ZeroTrust Architect — Thu, 07 May 2026 11:15:36 +0000

Smoothwall Express 3.1 was released in 2014. That is 12 years without a major release for a Linux-based security appliance. Let's look at what that means technically.

What "no major release" means for a security appliance

A Linux-based firewall distribution depends on several upstream components that evolve continuously:

Linux kernel: LTS kernels have 6-year support cycles. The kernel shipped with Smoothwall Express 3.1 (based on CentOS 6 era) is several major versions behind current LTS (6.x).
iptables / nftables: iptables has been superseded by nftables in modern distributions. Smoothwall Express uses iptables.
OpenSSL: Multiple major versions have been released since 2014, including TLS 1.3 support (OpenSSL 1.1.1+). Older OpenSSL versions cannot negotiate TLS 1.3 connections.
Squid: Squid 6.x shipped in 2023 with significant security improvements. Smoothwall Express ships an older Squid branch.

The OpenSSL / TLS 1.3 problem in particular

Many modern servers prefer or require TLS 1.3. A proxy running an OpenSSL version that predates TLS 1.3 support will negotiate TLS 1.2 at best — or fail to connect entirely if the upstream server enforces TLS 1.3 minimum.

For a security gateway that is supposed to inspect web traffic, this is a meaningful capability gap: you cannot inspect TLS 1.3 traffic you cannot terminate.

Feature gaps compared to a modern UTM

Smoothwall Express was designed as a simple firewall and proxy. Features that exist in current UTMs but not in Smoothwall Express:

✅ Stateful firewall
✅ Basic web proxy (Squid)
✅ Basic URL filtering
⚠️ Web antivirus (ClamAV, but outdated)
❌ SSL inspection / TLS MITM
❌ Web Application Firewall
❌ Reverse proxy
❌ Load balancer
❌ Multi-WAN with failover
❌ QoS / traffic shaping beyond basics
❌ LDAP/AD integration for per-user filtering
❌ Centralised multi-site management

Smoothwall UTM: the commercial version

Smoothwall Ltd. (now owned by Family Zone Cyber Safety) maintains a separate commercial product — Smoothwall UTM — that has received active development. It includes SSL inspection, AD integration, and modern content filtering. It is priced for the education market and has E-Rate eligibility in the US.

If you need Smoothwall specifically for education-sector compliance (E-Rate, safeguarding requirements), Smoothwall UTM remains relevant. For general SMB use, you are paying education-market pricing for a product optimised for a different use case.

Migration path technical considerations

Moving from Smoothwall Express to a modern UTM:

1. Firewall rule export: Smoothwall rules are stored in flat files, not an exportable standard format. Rules must be manually translated to the target platform's syntax.

2. URL filtering: Smoothwall uses SquidGuard with MESD blocklists. Modern replacements use updated category databases — mapping between category taxonomies requires review.

3. Network topology: Smoothwall uses a red/green/orange/blue zone model. Map these to the equivalent interface/zone model on the target platform before migration.

4. Parallel operation: Run the new appliance in parallel on a test segment for at least a week before cutover. Smoothwall's configuration edge cases may not be immediately apparent.

CacheGuard as a migration target provides LDAP/AD integration for per-user URL filtering, SSL inspection, WAF, and a fully active development cycle — with a kernel and OpenSSL version current as of 2026.

→ https://www.cacheguard.com/smoothwall-alternative/

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

Untangle's Plugin Architecture: Dependency Compatibility and the True Cost of Modular Pricing

ZeroTrust Architect — Thu, 07 May 2026 11:13:12 +0000

Untangle NG Firewall's app-store model separates the core firewall from security features. Understanding the technical implications of this architecture helps evaluate whether the flexibility is worth the cost — and the operational overhead.

Untangle's plugin architecture

Untangle runs on Debian Linux. The core platform provides the packet filtering, network management, and the app framework. Security features ("apps") are installed on top:

Web Filter: URL categorisation and policy enforcement
Virus Blocker: Antivirus scanning via ClamAV or commercial engine
SSL Inspector: TLS inspection / MITM
Application Control: Deep packet inspection for app identification
WAN Failover / Balancer: Multi-WAN management

Each app:

Has its own version, release notes, and update cycle
Is managed through the Untangle Command Center subscription
Requires a license token validated against Untangle's infrastructure
Integrates with the core via Untangle's proprietary UVM (Untangle Virtual Machine) API

Plugin API stability

Untangle's UVM provides a Java-based API layer that apps hook into. Major platform version upgrades (e.g., 16.x → 17.x) may change API interfaces, requiring corresponding updates to all installed apps. If an app is not updated for the new platform version, it stops loading.

This creates the same update coordination problem as plugin-based open-source platforms — with the additional constraint that the compatibility matrix is maintained by Untangle, not the operator.

Feature gaps that no plugin covers

Despite the extensible architecture, two significant features are absent from Untangle's app catalog:

Web Application Firewall: Untangle has no WAF app. HTTP request inspection against attack signatures (SQL injection, XSS, path traversal) is not available at any subscription tier. Organisations running web applications must deploy a separate WAF.

Reverse proxy / load balancer: Not available. SSL offloading and backend load distribution require a separate product.

Cost analysis: Complete bundle vs integrated free alternative

The Untangle Complete bundle includes: Web Filter, Virus Blocker, SSL Inspector, Application Control, WAN Failover, and others.

Approximate pricing (2025):

Complete (up to 12 devices, 3yr): ~$720 ($240/yr)
Complete (up to 100 devices): ~$1,890/yr
Complete (up to 250 devices): ~$3,500/yr

These costs are ongoing — discontinuing the subscription downgrades functionality to the free tier (firewall only).

CacheGuard comparison:

Tier	Untangle	CacheGuard
Firewall	Free	Free
Web antivirus	Paid (Virus Blocker)	Free (ClamAV integrated)
URL filtering	Paid (Web Filter)	Free (Squid + category lists)
SSL inspection	Paid (SSL Inspector)	Free (integrated)
WAF	Not available	Free (ModSecurity + OWASP CRS)
Reverse proxy	Not available	Free (Apache mod_proxy)
Multi-WAN	Paid (WAN Failover)	Free (integrated)
QoS	Paid	Free (HTB + SFQ)
Multi-site management	Paid (Command Center)	Free (CacheGuard Manager)

Features that Untangle has but CacheGuard does not: OpenVPN/SSL VPN, IPS (Intrusion Prevention), Active Directory integration via Directory Connector, application-level traffic identification.

→ https://www.cacheguard.com/untangle-alternative/

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

FortiGate ASIC vs Commodity Hardware: Where Dedicated Processing Matters and Where It Doesn't

ZeroTrust Architect — Thu, 07 May 2026 11:01:31 +0000

FortiGate appliances use dedicated ASICs (Application-Specific Integrated Circuits) for network processing. Understanding what these chips do — and where commodity x86 achieves parity — is necessary for rational sizing decisions.

FortiGate's ASIC architecture

Fortinet uses three custom processor families:

NP (Network Processor): Handles Layer 3/4 forwarding, stateful firewall processing, and IPsec VPN encryption/decryption offload. The NP7 (current generation) processes packets at line rate without CPU involvement, enabling multi-gigabit firewall throughput with near-zero latency.

CP (Content Processor): Handles cryptographic operations and content inspection — SSL/TLS inspection, IPS signature matching, and virus scanning. The CP9 can perform TLS decryption at 20+ Gbps.

SP (Security Processor): Used in higher-end models for application identification and deep packet inspection.

Where ASICs outperform x86

The NP processor advantage is measurable at high throughput:

Traffic type	FortiGate 60F (NP6Lite)	Commodity x86 (2-core)
Firewall throughput	10 Gbps	~3-5 Gbps
IPsec VPN throughput	6.5 Gbps	~1-2 Gbps (AES-NI)
TLS inspection throughput	1 Gbps	~500 Mbps
Firewall latency	~4 μs	~50-200 μs

These numbers matter for enterprise edge deployments handling multi-gigabit WAN links or thousands of concurrent VPN tunnels.

Where x86 achieves parity

For deployments with:

Internet uplinks under 500 Mbps
Under 200 concurrent users
Under 500 concurrent VPN tunnels

Modern x86 with AES-NI (hardware AES acceleration, standard on all Intel/AMD CPUs since ~2010) and multi-core processing reaches equivalent throughput. The NP processor advantage becomes unmeasurable below ~1 Gbps of actual traffic.

# Verify AES-NI availability on Linux
grep -m1 aes /proc/cpuinfo
# Benchmark AES-256-GCM performance
openssl speed -evp aes-256-gcm

A 4-core x86 system running CacheGuard can handle:

1 Gbps+ firewall throughput
500 Mbps+ TLS inspection (limited by SSL handshake rate, not bulk throughput)
Hundreds of concurrent IPsec VPN tunnels

FortiGuard threat intelligence: the non-hardware advantage

Separate from the ASIC processing, FortiGate's operational advantage includes FortiGuard Labs — Fortinet's threat intelligence operation that updates IPS signatures, URL categories, and malware definitions continuously. This is a cloud service, not a hardware feature.

The update frequency and breadth of FortiGuard intelligence is materially better than open-source alternatives (ClamAV signatures, community URL blocklists). For environments facing sophisticated, targeted threats, this is a real operational difference.

For standard SMB threat profiles — commodity malware, phishing, drive-by downloads — ClamAV signatures and maintained URL blocklists (or a subscription category database at ~€5/month) provide adequate coverage.

The hardware lock-in consequence

FortiGate hardware cannot run third-party software. FortiOS is proprietary. If Fortinet changes pricing, deprecates a model, or is acquired, your options are limited to whatever Fortinet offers.

On commodity x86, you run software you control on hardware you can replace from any vendor. The hardware is a commodity; the software can be updated, replaced, or forked.

Sizing guidance

FortiGate is the right choice if:

Internet uplink > 1 Gbps AND TLS inspection is required
Deployment requires FortiGuard intelligence at enterprise update frequency
IPS (intrusion prevention) is a hard compliance requirement
You operate > 500 concurrent VPN tunnels

Commodity x86 with CacheGuard is sufficient if:

Internet uplink < 500 Mbps
Organisation size < 500 users
Standard threat protection (firewall, antivirus, URL filtering, WAF) meets security requirements
Hardware independence and zero licensing cost are operational priorities

→ https://www.cacheguard.com/fortinet-alternative/

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

OPNsense Plugin Compatibility on FreeBSD: What Breaks and Why

ZeroTrust Architect — Thu, 07 May 2026 10:59:11 +0000

OPNsense is a FreeBSD-based firewall. Reaching UTM functionality requires plugins maintained by the OPNsense community and third parties. Here is the technical picture of how those plugins integrate and where compatibility breaks down.

The OPNsense plugin model

OPNsense plugins are FreeBSD packages distributed via the OPNsense repository. They integrate with the core via:

XML configuration merging: Plugins add their configuration schema to OPNsense's central XML config file (/conf/config.xml)
Python backend (configd): Plugins register backend services that the PHP GUI frontend calls via a Unix socket
Service management: Plugins register with OPNsense's service framework for start/stop/restart operations

This is a clean integration model. The problem is that each layer can break independently.

Squid on OPNsense: the proxy stack

The os-squid plugin installs Squid from FreeBSD ports. The OPNsense GUI provides configuration for basic proxy settings. Advanced Squid features (custom ACLs, cache tuning, ssl-bump configuration) require editing Squid's config files directly — OPNsense's GUI does not expose them.

URL filtering with SquidGuard or web filtering: The primary URL filtering option is os-squidguard, which uses SquidGuard for category-based filtering. SquidGuard is a Squid URL redirector that has had limited active development in recent years. Alternatively, os-web-proxy-useracl provides some per-user ACL support.

Version coupling issue: When OPNsense updates its FreeBSD base (e.g., 13.x → 14.x), the Squid port in FreeBSD repositories may lag or have breaking changes. The OPNsense team maintains their package repository to address this, but update lag between base OS releases and plugin availability is a recurring operational concern.

ClamAV integration: the ICAP chain

ClamAV does not integrate directly with Squid. The integration path:

Squid → ICAP protocol → c-icap daemon → ClamAV daemon

On OPNsense, this requires:

os-clamav: installs ClamAV
Manual c-icap configuration (no official OPNsense c-icap plugin — community approaches vary)
Squid ICAP configuration via custom options in the GUI's "Advanced" field

This is the most fragile point in the UTM stack. The c-icap → ClamAV boundary has version sensitivity: ClamAV API changes between major versions may require c-icap updates. If c-icap is not maintained for the installed ClamAV version, antivirus scanning silently fails — Squid returns 200 to ICAP requests that return errors, treating them as "scan passed."

Detecting silent ICAP failure:

# Check ICAP response on OPNsense
echo "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 returns ICAP/1.0 200 OK. An error or no response means antivirus is not scanning traffic despite Squid believing it is.

ModSecurity: the absent plugin

OPNsense does not have an officially maintained ModSecurity plugin. Community attempts exist but are not in the official repository and have inconsistent maintenance status. WAF capability on OPNsense essentially requires running a separate Apache or Nginx instance outside the OPNsense management framework.

SSL inspection: ssl-bump complexity

OPNsense's Squid plugin supports ssl-bump (TLS interception) via the GUI, but the CA certificate management — generating the proxy CA, distributing it to clients — is manual. There is no integrated PKI in OPNsense for this purpose.

The ssl-bump configuration in Squid requires careful step ordering to handle different certificate scenarios (valid cert, expired cert, self-signed cert, pinned cert) correctly. Misconfiguration causes either security gaps (blocking too little) or browsing failures (blocking too much).

The integrated alternative

CacheGuard eliminates each of these integration points: Squid, ClamAV, the ICAP chain, ssl-bump, ModSecurity, and the PKI are all pre-integrated and version-locked in a single LFS-based OS image. There is no c-icap compatibility to manage, no FreeBSD package lag to track, no separate CA management step.

The trade-off: you cannot customise individual components. If your requirements fit the standard UTM feature set, this trades flexibility for operational reliability.

→ https://www.cacheguard.com/opnsense-alternative/

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

FreeBSD vs Linux Network Stack for Security Appliances: Kernel Differences That Matter Operationally

ZeroTrust Architect — Thu, 07 May 2026 10:56:29 +0000

pfSense runs on FreeBSD. CacheGuard runs on a custom Linux distribution. The OS choice has practical implications for packet filtering architecture, hardware support, and third-party integration.

Packet filtering: pf vs nftables / iptables

FreeBSD / pfSense: Uses pf (Packet Filter), originally from OpenBSD. pf uses a declarative rule syntax evaluated top-to-bottom with a "last matching rule wins" model:

# pf syntax
pass out on em0 proto tcp from any to any port 443
block in on em0 proto tcp from <blocklist> to any

pf has native support for traffic normalisation, scrubbing, and stateful tracking. Its rule model is elegant for network engineers familiar with OpenBSD tooling.

Linux / CacheGuard: Uses nftables (or iptables). nftables uses a chain-and-table model with explicit jumps:

# nftables syntax
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input ip saddr @blocklist drop

nftables provides better performance than legacy iptables through native sets and maps, and is the current standard in Linux networking. iptables remains supported but is a compatibility layer over nftables in modern kernels.

Performance: Both pf and nftables can saturate 10Gbps+ links on modern hardware for stateful forwarding. At lower traffic volumes (typical SMB), performance differences are not operationally significant.

NAT implementation

pfSense: NAT is part of the pf ruleset. Source NAT, destination NAT, and 1:1 NAT are configured via pf rules or the pfSense GUI which generates pf rules.

Linux: NAT uses the netfilter connection tracking subsystem (conntrack). SNAT, DNAT, and MASQUERADE are iptables/nftables targets in the nat table. The conntrack table tracks connection state for NAT translation.

Both approaches handle standard NAT scenarios equivalently. Linux conntrack has a configurable table size limit — relevant for high-connection-count environments (default 65536 entries, tunable via net.netfilter.nf_conntrack_max).

Hardware driver coverage

FreeBSD and Linux have different driver ecosystems. For network interface cards specifically:

Intel NICs (e1000, igb, ixgbe, i40e): Well-supported on both
Realtek NICs: Better Linux support; FreeBSD support has historically lagged for newer chipsets
Broadcom NICs: Both have support, Linux generally broader
SR-IOV / DPDK: Linux ecosystem is more mature for virtualised and high-performance networking

For new hardware purchases, both platforms support mainstream server NICs equivalently. For repurposed consumer hardware with Realtek NICs, Linux has a historical edge.

Package ecosystem and update model

pfSense: FreeBSD packages via pkg, plus pfSense-specific packages via the pfSense package manager. Package updates are managed separately from the base OS update. Version locking between base OS and packages is the operator's responsibility.

CacheGuard (LFS-based): No package manager — all components are compiled and integrated at build time. Updates are whole-system updates tested against the full component set. No per-package version management, no pkg commands.

This is the fundamental operational difference: pfSense gives you control over each component's version; CacheGuard removes that surface area entirely and manages it centrally. Neither is universally better — the right choice depends on whether you want per-component control or coordinated stability.

→ https://www.cacheguard.com/pfsense-alternative/

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

Sophos XGS Feature Architecture: What Requires Proprietary Hardware and What Doesn't

ZeroTrust Architect — Thu, 07 May 2026 10:51:43 +0000

Sophos XGS hardware uses the "Xstream" architecture — dedicated processing components for specific functions. Understanding which features depend on this hardware and which are software functions helps identify where open-source alternatives have parity and where they do not.

The Xstream architecture

XGS appliances include dedicated processing for:

Xstream Flow Processor: Offloads TLS inspection from the main CPU using hardware acceleration. Enables high-throughput SSL decryption without impacting general forwarding performance.
Xstream Deep Packet Inspection engine: Dedicated ASIC for signature-based IPS, application identification, and traffic classification.
SophosLabs threat intelligence integration: Cloud-connected, continuously updated threat feeds including malware signatures, IP reputation, and behavioral indicators.
Sandstorm sandboxing: Uploads suspicious files to Sophos' cloud sandbox for dynamic behavioral analysis.
Synchronized Security / Security Heartbeat: A proprietary protocol between XGS appliances and Sophos endpoint agents. The firewall receives real-time endpoint health signals and can automatically quarantine compromised hosts.

These are not software features — they depend on the XGS hardware platform and Sophos' cloud infrastructure. They cannot be replicated on commodity hardware.

What is software-defined and replicable

The following XGS capabilities are implemented in software and can be matched by open-source alternatives on commodity hardware:

XGS capability	Open-source equivalent
Stateful firewall + NAT	iptables / nftables
IPsec VPN (IKEv2)	StrongSwan
Web proxy + URL filtering	Squid + category databases
SSL inspection	Squid ssl-bump
Gateway antivirus	ClamAV via ICAP
WAF	ModSecurity + OWASP CRS
Reverse proxy + load balancer	Apache mod_proxy
Multi-WAN failover	iproute2 + routing rules
QoS / traffic shaping	tc + HTB + SFQ
Web caching	Squid caching
Multi-site management	On-premises management plane

For an SMB running a 20–200 user network, the software-defined capabilities cover the vast majority of day-to-day security needs. The hardware-accelerated features (Xstream SSL offload, deep learning detection, cloud sandboxing) deliver measurable value at enterprise traffic volumes and threat sophistication levels — but represent diminishing returns for smaller deployments.

Licensing model: what stops working on expiry

Sophos XGS requires annual subscription licensing for:

Xstream Protection (IPS, app control, threat intelligence)
Web Protection (URL filtering, web antivirus)
Email Protection
Enhanced Support

Without an active subscription:

IPS signatures stop updating → protection degrades over time
URL category database stops updating → filtering becomes stale
Firmware updates are no longer provided
The appliance continues functioning with its last configuration

Unlike Meraki, Sophos appliances do not brick on license expiry — they degrade rather than shut down. But a Sophos XGS running on expired signatures is security theatre, not security.

The open-source parity zone

For sub-500-user deployments where Security Heartbeat integration is not relevant, where cloud sandboxing is not a compliance requirement, and where high-throughput SSL inspection does not require hardware acceleration, commodity hardware running CacheGuard covers the functional security requirements at zero licensing cost.

CacheGuard does not provide: deep learning threat detection, cloud sandboxing, Security Heartbeat endpoint integration, or email security. If these are hard requirements, XGS is the right platform. If they are nice-to-haves, the annual licensing cost becomes harder to justify.

→ https://www.cacheguard.com/sophos-alternative/

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