Building a Zero-Trust Network for Branch Offices with SD-WAN

Mar 26, 2026

Hopbox team

Zero-trust has become the default security posture for cloud infrastructure, but most branch office networks still run on implicit trust. A device plugs into the LAN, gets a DHCP lease, and has full lateral access to everything on that subnet. That is the opposite of zero-trust, and it is where most breaches at distributed enterprises actually begin.

This post covers how we implement zero-trust principles at the branch office level using Hopbox SD-WAN appliances running OpenWrt, combining L7 firewalling, IPS, DNS-based filtering, and policy-driven VPN tunnels.

What Zero-Trust Means at a Branch

In a cloud context, zero-trust typically means identity-aware proxies, service mesh mTLS, and per-request authorization. At a branch office, the principles are the same but the implementation is different:

• No implicit trust for LAN traffic. Being on the office network does not grant access to anything by default.
• Microsegmentation. Devices are grouped by role and policy, not just by subnet.
• Continuous verification. Traffic is inspected and filtered at every hop, not just at the WAN edge.
• Least-privilege access. Each segment can only reach the services it needs, nothing more.

Components of a Zero-Trust Branch

A zero-trust branch deployment on Hopbox uses the following components working together:

L7 Firewall

Layer 3/4 rules are not sufficient for zero-trust. An L7 firewall inspects application-layer protocols, allowing you to write rules like “allow HTTPS to api.example.com but block SSH tunnels over port 443.” On OpenWrt, this is achieved using nDPI-based deep packet inspection integrated with nftables.

# Example: L7 classification rule in nftables
chain forward {
    type filter hook forward priority 0; policy drop;

    # Allow DNS to internal resolver only
    iifname "br-guest" udp dport 53 ip daddr 10.0.0.1 accept

    # Allow HTTP/HTTPS but block tunneling protocols detected by DPI
    iifname "br-guest" meta l4proto tcp tcp dport { 80, 443 } \
        @th,0,0 ndpi protocol "http,tls" accept

    # Drop everything else from guest segment
    iifname "br-guest" counter drop
}

IPS/IDS

Intrusion prevention runs inline on the SD-WAN appliance. We use Suricata with a curated ruleset tuned for branch traffic patterns. The IPS engine inspects traffic that the L7 firewall has already permitted, catching exploit attempts, C2 callbacks, and lateral movement indicators.

DNS Filtering

DNS is the first control point. All client DNS queries are intercepted and resolved by the local appliance, which applies category-based filtering and threat intelligence blocklists. Encrypted DNS (DoH/DoT) from clients is blocked at the firewall level to prevent bypass.

# Force all DNS through the local resolver
chain prerouting {
    type nat hook prerouting priority -100;

    # Redirect any DNS query to the local resolver
    iifname "br-lan" udp dport 53 redirect to :53
    iifname "br-lan" tcp dport 53 redirect to :53

    # Block DoH to known providers
    iifname "br-lan" tcp dport 443 ip daddr @doh_providers drop
}

VPN Tunnel Policy

Every branch connects to the hub (or other branches) through WireGuard tunnels. Traffic destined for internal services is routed through the tunnel, while internet-bound traffic can break out locally after passing through the L7 firewall and IPS. Split-tunnel policies are defined centrally and pushed to each appliance.

Microsegmentation at the Branch

Microsegmentation is the foundation of zero-trust at the branch. On a Hopbox appliance, this is implemented using VLANs mapped to firewall zones, with explicit inter-zone policies.

A typical branch has four segments:

Segment	VLAN	Zone	Purpose
Corporate	10	lan_corp	Managed devices with full internal access
Guest	20	lan_guest	Internet-only, no internal access
IoT	30	lan_iot	Printers, cameras, sensors — isolated
Management	40	lan_mgmt	Network gear, appliance admin interfaces

Each zone has an explicit policy. Guest can reach the internet but not corporate. IoT can reach its cloud endpoints but not the LAN. Corporate can reach internal services through the VPN tunnel. Management is accessible only from the NOC over the VPN.

# /etc/config/firewall (OpenWrt UCI format)
config zone
    option name 'lan_iot'
    list network 'iot'
    option input 'DROP'
    option output 'ACCEPT'
    option forward 'DROP'

config rule
    option name 'IoT-to-cloud-allow'
    option src 'lan_iot'
    option dest 'wan'
    option dest_ip '203.0.113.0/24'
    option proto 'tcp'
    option dest_port '443'
    option target 'ACCEPT'

config rule
    option name 'IoT-to-LAN-deny'
    option src 'lan_iot'
    option dest 'lan_corp'
    option target 'REJECT'

Architecture Overview

The data path for a packet from a corporate device accessing an internal application looks like this:

1. Client sends DNS query — intercepted by the local resolver, checked against policy.
2. Client sends HTTPS request — enters the lan_corp zone.
3. L7 firewall inspects the connection, verifies it matches allowed application profiles.
4. IPS engine scans the traffic inline for threats.
5. Packet is routed through the WireGuard tunnel to the hub.
6. Hub-side firewall applies a second layer of policy before forwarding to the application.

Centralized Policy Management

Zero-trust at scale requires centralized policy management. Hopbox appliances pull their configuration from a central controller, which manages:

• Firewall rulesets per branch profile
• DNS filtering categories and custom blocklists
• IPS ruleset versions and tuning
• VPN tunnel topology and routing policy
• VLAN-to-zone mappings

When a policy change is made centrally, it propagates to all appliances within minutes. Configuration is versioned, so rollback is straightforward if a rule causes issues.

Monitoring and Alerting

Zero-trust without visibility is just a restrictive network. Every Hopbox appliance exports:

• Firewall logs — every accept/drop decision, tagged with zone, rule, and L7 classification.
• IPS alerts — Suricata EVE JSON logs, forwarded to the central SIEM.
• DNS query logs — every query and its resolution status (allowed, blocked, redirected).
• Tunnel health metrics — latency, jitter, packet loss per tunnel, per path.

Alerting is configured for anomalies: a spike in blocked DNS queries from a single host, IPS alerts from an internal segment, or a tunnel failover event. These are the early indicators that something in the branch needs attention.

Conclusion

Zero-trust at the branch is not a single product or feature. It is the combination of microsegmentation, L7 inspection, DNS filtering, IPS, and policy-driven VPN routing — all enforced at the edge, on the appliance itself. The branch should be as tightly controlled as any cloud VPC. With OpenWrt as the foundation and centralized management on top, that is achievable at scale without requiring agents on every endpoint.

Tags:

• security
• zero-trust
• sd-wan

Automating 900+ Network Devices with Ansible

Building Custom OpenWrt Images: A Practical Guide