Comparisons

Honest comparisons help you decide. The Gateway is the right tool for some jobs and the wrong tool for others.

At a glance

Capability	The Gateway	pfSense / OPNsense	Tailscale alone	Commercial VPN client	Pi-hole alone
Per-device routing policies	✅	manual rules	❌	❌	❌
Reference-counted fail-closed kill-switch	✅	manual rules	❌	partial	❌
Per-connection traffic splitting	✅	❌	❌	❌	❌
Censorship-resistant bridges	✅	❌	❌	❌	❌
Mesh between gateways	✅ (TS / HS)	manual VPN	✅	❌	❌
Config federation (push/pull)	✅	❌	❌	❌	❌
Recursive DNS + per-device filter	✅	with packages	❌	❌	✅
Open source	❌	✅	partial	varies	✅
Linux-only	yes	FreeBSD / Linux	multi-OS	multi-OS	Linux
Has a coherent control plane	✅	✅	✅	per-OS	✅

vs pfSense / OPNsense

Both are excellent BSD-based firewalls. They give you full pf/iptables-level control, a mature web UI for the firewall surface, and a healthy package ecosystem.

Where they’re a better fit than The Gateway:

• You want a general-purpose firewall, not specifically a programmable gateway.
• You need FreeBSD-only features (CARP, ZFS, etc.).
• You need an open-source license for compliance.
• You want a deep package ecosystem (Snort, Suricata, etc.).

Where The Gateway is a better fit:

• You want per-device routing without hand-crafting pf rules per VPN tunnel per device.
• You want a reference-counted kill-switch that survives daemon restarts without leak windows. pfSense’s kill-switch is a manually-maintained set of float rules; overlapping rules can leave gaps.
• You want traffic splitting across multiple VPN exits with privacy levels — there’s no first-class equivalent in pf.
• You want policy push/pull between two or more gateways out of the box.

If you already run pfSense or OPNsense and it works, you probably don’t need to switch. If you’re starting from scratch and your goal is privacy-first routing, The Gateway will save you weeks of pf wrangling.

vs Tailscale (or Headscale) alone

Tailscale is a mesh control plane. The Gateway uses it (or its self-hosted Headscale equivalent) for inter-node connectivity.

Where Tailscale alone is enough:

• You want a flat overlay between your devices.
• You don’t need per-device routing decisions at a LAN level — just point-to-point access.
• You don’t need fail-closed protection from a leaky tunnel — Tailscale doesn’t promise that.
• You don’t need a DNS plane with filtering.

Where you need The Gateway too:

• You want fail-closed behaviour at the LAN level (laptop won’t reach the internet if the tunnel is down).
• You want selective domain routing (Telegram via a bridge; everything else direct).
• You want traffic splitting for jurisdictional or anti-correlation reasons.
• You want federation of policy across multiple sites with explicit roles.

Common deployment: Tailscale / Headscale for connectivity, The Gateway riding on top for policy.

vs a commercial VPN client (Mullvad / Proton / NordVPN / etc.)

Commercial VPN clients install on each device and route that device’s traffic through their provider.

Where the commercial client is enough:

• You have one device.
• You’re OK with provider-specific kill-switch quality (which varies — most are not reference-counted, and some leak on tunnel cycle).
• You’re OK with the provider’s exit list as your only egress.
• You don’t want to operate a network appliance.

Where The Gateway is a better fit:

• You have multiple devices — phone, laptop, TV, IoT, guest. A laptop VPN client only protects the laptop.
• You want per-device decisions: TV streams direct, laptop through a tunnel, IoT only to a DNS allowlist.
• You want multiple providers simultaneously for jurisdictional diversity. The splitting engine accepts any mix of WireGuard / OpenVPN.
• You want a bridge in front of the VPN for DPI-resistant transport in censored environments.
• You want central policy managed in one place rather than per-device app configuration.

The Gateway doesn’t replace your VPN provider — it sits between your devices and the provider. You still pay the provider; you just get a programmable layer on top.

vs Pi-hole alone

Pi-hole is a DNS sinkhole with a web UI. The Gateway’s DNS plane covers everything Pi-hole does (plus per-device rules, custom zones, ECS stripping, DoH/DoT block, leak prevention) — but the DNS plane is only one of eleven subsystems.

Where Pi-hole alone is enough:

• You only want ad/tracker blocking on your LAN.
• You don’t need routing, firewall, or VPN management.
• You want the Pi-hole community’s blocklist ecosystem (which is excellent).

Where The Gateway is a better fit:

• You want DNS plus routing plus firewall plus VPN with one control plane.
• You want per-device DNS rules that respect the same device_group taxonomy as your routing policies.
• You want DNS leak prevention that catches devices ignoring DHCP.

A nice middle ground: The Gateway can back its resolver onto a Pi-hole if you already run one and want to keep using its blocklist UI.

vs SaaS network gateways (Cloudflare One, Twingate, etc.)

SaaS gateways tunnel your traffic to a vendor-operated control plane.

Where SaaS is enough:

• You don’t want to operate hardware.
• Your threat model is fine with the SaaS vendor seeing all your traffic.
• You want managed zero-trust posture for an organisation.

Where The Gateway is a better fit:

• You want on-premise ownership — no vendor terminates your traffic.
• You want air-gappable operation — the daemon works without the WAN.
• You want privacy-first posture, not corporate zero-trust posture (different concerns).
• You’re a household or small org that doesn’t want a per-seat SaaS bill.

The two address overlapping but distinct problems. SaaS gateways are for enterprises that want a managed zero-trust posture and accept the vendor in their data path. The Gateway is for operators who want privacy-first programmable routing without a vendor in the loop.

What you give up to use The Gateway

To be honest about the trade-offs:

• It’s private / proprietary, not open source. If a fully open stack is a requirement, this is a hard stop.
• Linux only. No Windows, no macOS, no FreeBSD.
• You operate the box. No managed offering.
• Smaller community than pfSense / Tailscale / Pi-hole. Less Stack Overflow surface, no third-party package ecosystem.
• Newer. Mature firewalls have a decade of edge-case fixes. The Gateway is maturing; we lean heavily on the reconciler to make up for it.

Related

• FAQ → Comparisons — the short version of the above.
• Threat model — what The Gateway protects against, in detail.
• Use cases — concrete deployments that demonstrate the differences.