Architecture

Overview#

                                ┌──────────────────────────────┐
            ISP A ──────────────┤                              │
                                │   Sovereign Edge Firewall    ├── Zone: Clients
            ISP B ──────────────┤   (active / passive failover) │── Zone: VPN
                                │                              │── Zone: Anonymization
                                │   • Stateful filter           │── Zone: Privacy
                                │   • NAT (per-uplink)          │── Zone: DMZ
                                │   • Transparent SSL offload   │
                                │   • Failover monitor          │
                                └──────────────────────────────┘

The firewall sits at the edge of the network with two parallel internet uplinks. Internally it presents one logical interface to each isolated zone.

Dual-provider high availability#

Two uplinks (e.g. fiber + LTE/5G or two carriers) are connected in parallel. A failover monitor watches link state, gateway reachability, and latency, and switches the default route to the secondary uplink in under five seconds on failure.

Key properties:

• Symmetric ruleset. Both uplinks share the same filter, NAT, and scrub rules. There is no “good path” and “bad path.”
• Dynamic NAT. Source NAT pulls the egress IP from the active interface dynamically — no hardcoded IPs, no stale mappings on failover.
• Selective override. Specific traffic classes can be pinned to the secondary uplink (e.g. an anonymizing proxy pathway, a load-spread for download-heavy services).
• Automatic failback. Once the primary uplink is healthy, the monitor reverts the default route automatically.
• Failover testing. A defined drill (see Operations) verifies that failover works every quarter — not just in theory.

Zone segmentation#

Instead of a flat “inside/outside” topology, the firewall operates on a multi-tier zone model. Lateral movement between zones is blocked by default.

Each zone has its own:

• Filter ruleset — what is allowed in, what is allowed out.
• NAT policy — which egress IP, which uplink preferred.
• Inspection layer — whether HTTPS is intercepted, what is logged.
• Whitelist/blocklist tables — drawn from the daemon outputs (see Abusive HTTP Watch docs).

Transparent security layers#

Endpoints in the client zone receive the following protections without any local configuration:

SSL offloading as antivirus#

This is the most operationally valuable layer. The reasoning:

• Over 90 % of modern web threats — malware downloads, phishing payloads, drive-by exploits — are delivered over TLS.
• Endpoint antivirus (Defender, Bitdefender, …) running on the workstation sees only the encrypted stream. It can only detect the infected file after the device has unpacked it.
• At that point, the device has already executed the early stages of the payload. Containment becomes incident response.

The firewall instead terminates TLS at the gateway, hands the cleartext to an antivirus engine, and only then forwards the content to the endpoint. The endpoint sees an already-scanned stream. Malware is blocked before it reaches the device.

The CA used for the bump is the Sovereign Certificate Authority — clients trust the gateway’s certificates because the internal CA root is installed via standard configuration management.

Content filter#

Ad networks, tracker domains, and known malicious hosts are filtered out before delivery. Reduces page weight, eliminates a class of supply-chain attacks (compromised ad-network JavaScript), and improves privacy.

Tor / anonymization gateway#

The anonymization zone has no direct internet egress at all. All TCP traffic is transparently routed through a local Tor daemon, including DNS queries (via a local resolver that uses Tor’s DNS port). Endpoints in this zone do not need any local Tor client — the network forces the routing.

I2P / privacy gateway#

Same idea as the Tor zone, one layer deeper. Used for workloads where Tor exit-node trust is also a concern.

Operational defaults#

• Default-deny. Every rule allowing traffic is explicit. Spoofing protection, reverse-path validation, and anti-scan heuristics run by default.
• Connection state limits. Hundreds of thousands of parallel sessions supported; per-source caps prevent state-table exhaustion.
• Traffic normalization. TCP reassembly, MSS clamping, and fingerprinting protection are applied to all egress paths — important for mobile uplinks and VPN tunnels.
• Dual stack. IPv4 and IPv6 are first-class, including modern ICMPv6 mechanics (router advertisement, neighbour discovery).

Where the daemon fits#

The companion Abusive HTTP Watch daemon writes a blocklist that the firewall consumes via a table-reload cron. This adds a layer of behavioural blocking on top of the static rules — IPs that demonstrably probe for exploits are dropped at the edge.

What this is not#

• Not a vendor box you can buy. This is a delivery pattern, not a product SKU.
• Not a beginner project. Running this responsibly requires competent operators (or the Support service to provide them).
• Not “set it and forget it.” The token sets, blocklists, and zone rules require maintenance — see Operations.