12.1 Policy-Based Branch Office VPN (BOVPN)

12.1 Policy-Based Branch Office VPN (BOVPN)

Quick Answer: A policy-based Branch Office VPN (BOVPN) in WatchGuard Fireware establishes an encrypted, authenticated IPsec tunnel connecting geographically dispersed networks across the public Internet. Fireware separates VPN architecture into Gateways (which govern Phase 1 Internet Key Exchange [IKE] peering, endpoint IP addresses, Diffie-Hellman groups, and Pre-Shared Keys) and Tunnels (which govern Phase 2 IPsec data proposals, Encapsulating Security Payload [ESP], Perfect Forward Secrecy [PFS], and local/remote subnet pairs). By default, Fireware auto-generates permissive BOVPN-Allow.in and BOVPN-Allow.out policies, which administrators should disable or supplement with custom packet filters and application proxies to inspect and restrict inter-site traffic.

---

Site-to-Site IPsec VPN Fundamentals

Branch Office Virtual Private Networks (BOVPN) are the primary mechanism used by distributed organizations to interconnect remote branch offices, retail storefronts, satellite campuses, and centralized data centers across untrusted public WAN infrastructure. Rather than leasing costly, rigid point-to-point telecommunication circuits (such as private MPLS or dark fiber), an IPsec-based BOVPN leverages commodity broadband connections to construct a cryptographically secured overlay network.

The Internet Protocol Security (IPsec) protocol suite guarantees four foundational security services across the public WAN:

1. Data Confidentiality: Protects sensitive payloads from eavesdropping through robust symmetric encryption algorithms, primarily Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) or Galois/Counter Mode (GCM).
2. Data Integrity: Ensures that transmitted packets cannot be altered or tampered with in transit by utilizing cryptographic hash message authentication codes (HMAC), including SHA-2 (SHA-256, SHA-384, SHA-512).
3. Origin Authentication: Verifies the cryptographic identity of the remote gateway before establishing communication channels, relying on Pre-Shared Keys (PSK) or public key infrastructure (PKI) X.509 digital certificates.
4. Anti-Replay Protection: Prevents malicious actors from intercepting and re-transmitting captured valid packets across the tunnel by maintaining a sliding window of unique, monotonically increasing packet sequence numbers.

In WatchGuard Fireware OS, site-to-site VPNs are implemented either as traditional policy-based BOVPNs (where traffic is selected for encryption based on security policies matching specific source and destination IP subnets) or as BOVPN Virtual Interfaces (BOVPN VIF) (route-based VPNs using logical interfaces). Understanding policy-based architecture is essential for configuring, maintaining, and troubleshooting enterprise hybrid WAN topologies.

---

The Two-Tier Architecture: Gateways vs. Tunnels in Fireware

A hallmark of WatchGuard Fireware's VPN engine is its modular, two-tier separation between the control plane configuration (BOVPN Gateway) and the data plane configuration (BOVPN Tunnel). This distinction corresponds directly to the two distinct phases of IPsec negotiation.

+-----------------------------------------------------------------------------------+
|                             FIREWARE BOVPN ARCHITECTURE                            |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ BOVPN GATEWAY (Phase 1 / IKE SA) ]                                             |
|  ├── Local Gateway Endpoint (Local External IP / Interface)                       |
|  ├── Remote Gateway Endpoint (Remote Public IP / FQDN)                            |
|  ├── Protocol Version: IKEv1 (Main / Aggressive) or IKEv2                         |
|  ├── Phase 1 Transform: DH Group (14/19/20), Cipher (AES-256), Hash (SHA-256)   |
|  ├── Authentication Credential: Pre-Shared Key (PSK) or Digital Certificate       |
|  └── Operational Controls: Dead Peer Detection (DPD), NAT-T                       |
|                                    │                                              |
|                                    ▼ Binds to Gateway                             |
|  [ BOVPN TUNNEL (Phase 2 / Child SA / Quick Mode) ]                               |
|  ├── Tunnel Route 1: Local Subnet (10.0.1.0/24) <──> Remote Subnet (10.0.20.0/24) |
|  ├── Tunnel Route 2: Local Subnet (10.0.2.0/24) <──> Remote Subnet (10.0.20.0/24) |
|  ├── Phase 2 Proposal: ESP (AES-256 / SHA-256), SA Lifetime (8 Hours)             |
|  └── Perfect Forward Secrecy (PFS): Enabled (Diffie-Hellman Group Match)          |
|                                                                                   |
+-----------------------------------------------------------------------------------+

BOVPN Gateways (Phase 1 Negotiation)

A BOVPN Gateway object establishes and manages the Phase 1 Security Association (SA). Phase 1 is an administrative control channel established between the two firewall hardware endpoints (the local Firebox and the remote peer). The primary objective of Phase 1 is to authenticate the two peering devices, securely negotiate cryptographic keys using the Diffie-Hellman (DH) protocol, and build an encrypted bidirectional tunnel (the IKE SA) through which subsequent Phase 2 negotiations occur.

The Gateway configuration defines:

• Gateway Endpoints: The physical or logical Layer 3 external IP addresses or Fully Qualified Domain Names (FQDN) of both the local Firebox and the remote VPN appliance.
• Authentication Method: The shared secret (Pre-Shared Key) or X.509 certificate used to validate identity.
• Phase 1 Proposals: The accepted combinations of cryptographic ciphers (e.g., AES-256), hashing algorithms (e.g., SHA-256), Diffie-Hellman key groups (e.g., Group 14), and SA expiration lifetimes (default: 24 hours).
• Network Parameters: Dead Peer Detection (DPD) settings and NAT Traversal (NAT-T) behavior.

BOVPN Tunnels (Phase 2 Negotiation & Security Associations)

A BOVPN Tunnel object binds directly to an existing BOVPN Gateway and establishes the Phase 2 Security Associations (often referred to as Quick Mode SAs in IKEv1 or Child SAs in IKEv2). Phase 2 is the data-carrying channel: it negotiates the cryptographic parameters used to protect the actual user data traffic and defines which local and remote subnets are authorized to communicate across the encrypted link.

The Tunnel configuration defines:

• Associated Gateway: The specific Phase 1 BOVPN Gateway through which this tunnel establishes its data SAs.
• Tunnel Routes (Network Pairs / Proxy IDs): The explicit pairings of local IP addresses/subnets and remote IP addresses/subnets that trigger encryption. For example, local network 10.0.1.0/24 communicating with remote network 10.0.20.0/24.
• Phase 2 Proposals: The data encapsulation protocol (Encapsulating Security Payload [ESP] or Authentication Header [AH]), data encryption algorithm (e.g., AES-GCM-256 or AES-CBC-256), and integrity hash.
• Phase 2 Lifetime: The lifespan of the Phase 2 SA before rekeying occurs (default: 8 hours or 28,800 seconds).
• Perfect Forward Secrecy (PFS): An optional but critical setting requiring a fresh Diffie-Hellman key exchange for every Phase 2 rekey.

Gateway vs. Tunnel Configuration Comparison

---

Phase 1 Negotiation Parameters: Protocols, Ciphers & Authentication

Configuring the BOVPN Gateway requires aligning Phase 1 cryptographic transforms between the Firebox and the remote peer. Any discrepancy between local and remote parameters results in immediate Phase 1 failure.

IKEv1 vs. IKEv2 Comparison

WatchGuard Fireware supports both IKEv1 (Internet Key Exchange version 1 - RFC 2409) and IKEv2 (Internet Key Exchange version 2 - RFC 7296). While legacy networks may still operate IKEv1, WatchGuard strongly recommends IKEv2 for modern deployments due to its superior speed, reliability, and security architecture.

sequenceDiagram
    autonumber
    participant Local as Local Firebox (Initiator)
    participant Remote as Remote Gateway (Responder)
    
    Note over Local,Remote: Phase 1: IKE SA Negotiation (Control Plane)
    Local->>Remote: IKE_SA_INIT (Proposals, Nonces, DH Public Value)
    Remote-->>Local: IKE_SA_INIT (Accepted Proposal, Responder Nonce, DH Value)
    Note over Local,Remote: Shared Secret Calculated via Diffie-Hellman; Encryption Active
    Local->>Remote: IKE_AUTH (Encrypted: Identity, PSK/Cert Auth, First Child SA Proposal)
    Remote-->>Local: IKE_AUTH (Encrypted: Identity, Auth Verification, Child SA Accepted)
    
    Note over Local,Remote: Phase 2: Child SA Established (Data Plane Active)
    Local->>Remote: ESP Packets (Encrypted User Payload: 10.0.1.0/24 -> 10.0.20.0/24)
    Remote-->>Local: ESP Packets (Encrypted User Payload: 10.0.20.0/24 -> 10.0.1.0/24)

IKEv1 Operational Modes

Under IKEv1, Phase 1 can execute in one of two distinct modes:

• Main Mode: Consists of a 6-packet exchange. The first two packets negotiate security policies and algorithms; the second two exchange Diffie-Hellman public values and nonces; the final two packets exchange identities and authentications in encrypted form. Main Mode provides identity protection (eavesdroppers cannot identify the negotiating peers) but requires static IP addresses on both ends.
• Aggressive Mode: Condenses Phase 1 into a rapid 3-packet exchange. It does not provide identity protection because the peer identity is transmitted in plaintext in the first packet. Aggressive mode is historically used when one endpoint has a dynamic IP address and uses an FQDN identifier, but it is cryptographically vulnerable to offline Pre-Shared Key dictionary attacks.

IKEv2 Advantages

IKEv2 replaces Main and Aggressive modes with a streamlined, standardized 4-packet initial exchange:

1. IKE_SA_INIT (Packets 1 & 2): Negotiates cryptographic algorithms, exchanges nonces, and completes the Diffie-Hellman key exchange, immediately establishing an encrypted control session.
2. IKE_AUTH (Packets 3 & 4): Transmits encrypted identity credentials, validates authentications, and establishes the initial Phase 2 Child SA.
3. MOBIKE (Mobility and Multihoming Protocol): Enables VPN tunnels to survive WAN IP address changes (e.g., when a mobile or backup link shifts IPs) without tearing down the SA.
4. Asymmetric Authentication: Allows one peer to authenticate using a digital certificate while the other peer authenticates using a Pre-Shared Key.
5. Native NAT Traversal: Inherent support for NAT detection without proprietary vendor vendor-ID extensions.

Cryptographic Ciphers, Diffie-Hellman Groups & Lifetimes

When defining the Phase 1 Transform Settings in the Firebox Gateway, administrators must select compatible, secure cryptographic primitives:

• Diffie-Hellman (DH) Groups: Determines the bit-length and mathematical algorithm used to compute the shared master secret over an insecure channel. Fireware supports legacy groups as well as modern elliptic curve groups:
  • Group 14 (2048-bit MODP): The minimum baseline standard recommended for enterprise security.
  • Group 19 (256-bit Elliptic Curve / NIST P-256): Provides higher security than Group 14 with significantly reduced computational overhead and faster handshake execution.
  • Group 20 (384-bit Elliptic Curve / NIST P-384): High-security elliptic curve option for top-tier cryptographic compliance.
  • Deprecated Groups: Group 1 (768-bit), Group 2 (1024-bit), and Group 5 (1536-bit) are cryptographically broken and must never be deployed in production.
• Encryption Algorithms: Encrypts Phase 1 control traffic. Fireware supports AES-128, AES-192, and AES-256 (in CBC mode), as well as AES-GCM (which combines encryption and authentication). AES-256 is the standard enterprise recommendation.
• Hash Algorithms: Computes HMAC authentications. Fireware supports SHA-2 (SHA-256, SHA-384, SHA-512). Legacy MD5 and SHA-1 must be avoided due to known collision vulnerabilities.
• Phase 1 SA Lifetime: Fireware defaults to 24 hours (86,400 seconds). When the lifetime expires, the firewalls rekey Phase 1. If set too short, frequent rekeys introduce CPU overhead; if set too long, cryptographic exposure increases.

---

Phase 2 Proposals: ESP vs. AH, PFS & Tunnel Routes

Once the Phase 1 control channel is securely established, the firewalls proceed to Phase 2 to negotiate the data plane SAs governing payload transit.

Encapsulation Protocols: ESP vs. AH

IPsec provides two distinct Layer 3 headers to protect IP packets:

1. Encapsulating Security Payload (ESP - IP Protocol 50): ESP encrypts the entire original IP packet (in Tunnel Mode) and appends an ESP trailer and authentication tag. It provides confidentiality, integrity, origin authentication, and anti-replay protection. ESP is the universal industry standard and the default in Fireware.
2. Authentication Header (AH - IP Protocol 51): AH provides integrity, authentication, and anti-replay protection, but does not provide confidentiality (payloads remain in plaintext). Furthermore, AH calculates its integrity checksum across the outer IP header (including source and destination IP addresses). Because Network Address Translation (NAT) modifies IP headers, any intermediate NAT device alters the packet and invalidates the AH checksum. Consequently, AH cannot traverse NAT routers. Fireware supports AH for legacy regulatory scenarios, but ESP is overwhelmingly preferred.

Perfect Forward Secrecy (PFS)

In standard IPsec Phase 2 rekeying, the encryption keys used for Phase 2 data SAs are derived mathematically from the original master key generated during Phase 1 Diffie-Hellman negotiation. While computationally efficient, this creates a vulnerability: if an adversary captures encrypted traffic and subsequently compromises the Phase 1 master key (or Pre-Shared Key), they can mathematically derive every Phase 2 session key and decrypt all historical data transmissions.

Perfect Forward Secrecy (PFS) eliminates this vulnerability:

• When PFS is enabled, the firewalls execute a brand-new Diffie-Hellman key exchange during every Phase 2 rekey (Quick Mode in IKEv1 or CREATE_CHILD_SA in IKEv2).
• New session keys are completely independent of the Phase 1 master secret and prior session keys.
• Even if an attacker compromises the current session key or the Phase 1 Pre-Shared Key, they cannot decrypt past or future sessions.

[!IMPORTANT] If PFS is enabled on the Firebox, it must also be enabled on the remote peer, and both endpoints must agree on the identical Diffie-Hellman group (e.g., DH Group 14 or Group 19). If one endpoint has PFS enabled and the other has it disabled, Phase 1 will succeed, but Phase 2 negotiation will immediately fail with a No proposal chosen error.

Defining Tunnel Routes (Network Pairs / Proxy IDs)

In a policy-based BOVPN, Fireware identifies which packets belong in the tunnel by matching traffic against configured Tunnel Routes (internally referred to as IPsec Proxy IDs or Traffic Selectors):

• A Tunnel Route defines a directional relationship between a Local IP/Subnet and a Remote IP/Subnet.
• For example, if Site A possesses local trusted network 10.0.1.0/24 and Site B possesses trusted network 10.0.20.0/24, Site A's tunnel route is defined as Local: 10.0.1.0/24 <-> Remote: 10.0.20.0/24.
• On Site B, the configuration must be the exact symmetric mirror image: Local: 10.0.20.0/24 <-> Remote: 10.0.1.0/24.
• Each unique network pair establishes its own independent pair of unidirectional Phase 2 Security Associations (one inbound SA and one outbound SA, identified by unique Security Parameter Indices [SPIs]).
• If Site A has three internal subnets and Site B has two internal subnets, establishing full inter-site mesh connectivity requires configuring six distinct tunnel routes (3 x 2 = 6 Phase 2 SAs).

---

Auto-Generated vs. Custom BOVPN Policies

When an administrator saves a new BOVPN Tunnel configuration in Fireware (via Policy Manager or the Fireware Web UI), the firewall must decide which firewall policies permit or deny the decrypted traffic passing between the network interfaces.

The Behavior of BOVPN-Allow.in and BOVPN-Allow.out

By default, Fireware enables the global setting Add BOVPN policies automatically (or creates automatic tunnel policies). When enabled, Fireware automatically injects two hidden, system-managed packet filter policies into the policy list:

1. BOVPN-Allow.in: Permitted traffic arriving inbound through any active BOVPN tunnel destined for local internal networks (Source: Any-BOVPN, Destination: Firebox, Any-Trusted, Any-Optional).
2. BOVPN-Allow.out: Permitted traffic originating from internal networks destined to cross any active BOVPN tunnel (Source: Any-Trusted, Any-Optional, Destination: Any-BOVPN).

+-----------------------------------------------------------------------------------+
|                         DEFAULT BOVPN POLICY BEHAVIOR                             |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ Site A: Trusted 10.0.1.0/24 ]                                                  |
|        │                                                                          |
|        ├──> Traverses [ BOVPN-Allow.out ] ──> Service: ANY (Permits All Ports!)   |
|        │                                                                          |
|  [ Encrypted Across WAN Tunnel ]                                                  |
|        │                                                                          |
|        └──> Arrives at Site B ───────────────> Traverses [ BOVPN-Allow.in ]       |
|                                                └──> Service: ANY (No Inspection!) |
|                                                                                   |
|  RISK: Unrestricted lateral movement (Worms, Ransomware, NetBIOS, SMB, RDP)      |
+-----------------------------------------------------------------------------------+

Security Risks of Auto-Generated Policies

While BOVPN-Allow.in and BOVPN-Allow.out simplify initial deployment and guarantee immediate connectivity, they present severe security hazards in enterprise environments:

• Any Service Allowed: Both policies permit the Any service filter. All TCP, UDP, and ICMP ports are wide open between sites. If a workstation at a remote branch is infected with ransomware or a network worm, the malware can freely propagate over SMB (TCP 445), NetBIOS, or RDP across the tunnel to headquarters servers without restriction.
• Bypasses Deep Content Security: Because BOVPN-Allow rules are basic packet filters, traffic traversing the tunnel is not subjected to application proxy inspection. Subscription security services—such as Gateway AntiVirus (GAV), Intrusion Prevention Service (IPS), and Application Control—do not inspect the inter-site traffic by default.

Securing the Tunnel: Restricting Traffic with Custom Policies

To establish a Zero Trust, least-privilege security posture across the corporate WAN, network administrators must replace or restrict the auto-generated policies:

1. Disable Auto-Generated Policies: In the BOVPN Tunnel settings or global VPN settings, uncheck Add BOVPN policies automatically (or disable the auto-generated policies for that specific tunnel).
2. Create Granular Packet Filters: Define specific packet filter policies that permit only necessary administrative ports between designated IP addresses (e.g., allowing DNS queries from branch domain controllers to headquarters, or restricting RDP access strictly to administrative jump boxes).
3. Deploy Proxy Policies with Security Subscriptions: Construct explicit proxy policies (such as HTTPS-proxy, HTTP-proxy, and CIFS-proxy) applied to the Any-BOVPN alias or specific branch subnets. This ensures that files transferred over SMB/CIFS or web services across the VPN are actively scanned by Gateway AntiVirus and inspected by IPS engines.
4. Apply User-Based and Group-Based Policies: Leverage Firebox Single Sign-On (SSO) or Active Directory integration to restrict tunnel access based on authenticated user credentials rather than open subnet ranges.