BOVPN Virtual Interface Examples
When you configure a branch office VPN as a virtual interface, the Firebox sends a packet through the tunnel based on the outgoing interface for the packet. The BOVPN virtual interface is in the routing table, and the decision about whether to send traffic through the VPN tunnel is affected by static and dynamic routes and by SD-WAN routing. This provides flexibility in how you can configure the Firebox to use a BOVPN tunnel.
Because a BOVPN virtual interface is considered another interface in the configuration, it provides many flexible configuration and routing options. This topic includes these configuration options:
- BOVPN virtual interface to a cloud-managed Firebox
- SD-WAN routing (with metric-based failover)
- SD-WAN routing (no failover)
- Failover and failback based on routing table metrics
- Dynamic routing
- Third-party integrations
- Microsoft Azure active-standby failover
- Microsoft Azure active-active failover
If either endpoint is behind a NAT device, we recommend that you configure virtual IP addresses. For more information about virtual IP addresses, go to Configure BOVPN Virtual Interface IP Addresses.
In Fireware v12.3 or higher, SD-WAN replaces policy-based routing. In Fireware v12.2.1 or earlier, to route traffic to a different external interface, you must use policy-based routing. When you upgrade to Fireware v12.3 or higher, policy-based routing without failover is converted to an SD-WAN action with a single interface. Policy-based routing with failover is converted to an SD-WAN action with multiple interfaces. In Policy Manager, the policy-based routing setting is still available for backwards compatibility with older Fireware OS versions. For more information about policy-based routing, go to Configure Policy-Based Routing in Fireware v12.2.1 or lower in the WatchGuard Knowledge Base.
BOVPN Virtual Interface to a Cloud-Managed Firebox
To configure a BOVPN to a cloud-managed Firebox, add a BOVPN virtual interface with these settings:
- Remote Endpoint Type — Select Cloud VPN or Third-Party Gateway.
- Phase 1 Settings — In the phase 1 settings, select IKEv2.
Configure all other settings to be the same as the VPN settings on the cloud-managed Firebox.
- Remote gateway — Specify the external domain name or IP address of the cloud-managed Firebox.
- Credential method — Select one of two options:
- Pre-shared Key — Specify the pre-shared key configured in the cloud-managed Firebox BOVPN settings.
- Certificate — Specify an IPSec Firebox certificate used for tunnel authentication.
- Virtual IP addresses — The virtual IP addresses specified in the cloud-managed Firebox BOVPN settings.
- Phase 1 settings — Configure the remote endpoint to use IKEv2, and specify the authentication, encryption, SA Life, and key expiration settings specified in the cloud-managed Firebox BOVPN settings.
- Phase 2 settings — Configure the remote endpoint to use ESP (Encapsulating Security Payload), and specify the authentication, encryption, and key expiration settings specified in the cloud-managed Firebox BOVPN configuration.
- Network resources — Configure the remote endpoint to route traffic through the VPN to the Firebox network resources.
From the VPN configuration of the cloud-managed Firebox, you can view a guide that shows the VPN settings to configure.
For information about how to configure the VPN on the cloud-managed Firebox and view the BOVPN Guide, go to Configure a BOVPN to a Locally-Managed Firebox or Third-Party VPN Endpoint.
BOVPN Virtual Interface with SD-WAN Routing (Metric-Based Failover)
Objective
You want to make sure users experience high quality of service for latency-sensitive traffic such as VoIP calls. You can accomplish this with SD-WAN routing that uses performance metrics for BOVPN virtual interface failover.
Configuration Summary
Go to SD-WAN Failover from an MPLS Link to a BOVPN Virtual Interface Tunnel and Configure SD-WAN.
BOVPN Virtual Interface with SD-WAN Routing (No Failover)
Objective
One site (Site A) has a single external interface and two branch office VPN gateways to another site (Site B) that has two external interfaces. The two network connections at Site B have different quality or cost. The objective is to send latency-sensitive traffic, such as VoIP, through the tunnel over the network with the lowest latency, and send all other traffic, such as FTP, through the other tunnel route.
SD-WAN replaces policy-based routing. For information about how SD-WAN works, go to About SD-WAN.
Configuration Summary
On the Site A device:
- Configure a BOVPN virtual interface between Site A and the Site B external interface that uses the low-latency link. On the VPN Route tab, you do not have to add routes. The first BOVPN virtual interface is bvpn1. Make sure to select the Start Phase 1 tunnel when it is inactive check box in the BOVPN virtual interface configuration.
- Configure another BOVPN virtual interface between Site A and the second External interface at Site B. The second BOVPN virtual interface is bvpn2. You can add routes for other traffic.
- Edit the SIP policy for VoIP traffic.
- In the From list, add the network address of the local network where traffic handled by this policy originates.
- In the To list, add the network address of the trusted or optional network at the remote site where traffic handled by this policy is routed.
- Select or add an SD-WAN action that uses the BOVPN virtual interface with a lower latency.
- For all other traffic, you can define either static routes or dynamic routes, and use the other BOVPN virtual interface that has higher latency.
On the Site B device:
- Configure a BOVPN virtual interface between the first External interface at Site B and Site A. On the VPN Route tab, you do not have to add routes. This is bvpn1 and is the low-latency link in this example. Make sure that the Start Phase 1 tunnel when it is inactive check box is selected.
- Configure a BOVPN virtual interface between Site A and the second External interface at Site B. This is bvpn2. You can add routes for other traffic.
- Edit the SIP policy for VoIP traffic.
- In the From list, add the network address of the local network where traffic handled by this policy originates.
- In the To list, add the network address of the trusted or optional network at the remote site where traffic handled by this policy is routed.
- Select or add an SD-WAN action that uses the BOVPN virtual interface with a lower latency.
- For all other traffic, you can define either static routes or dynamic routes, and use the other BOVPN virtual interface that has higher latency.
How It works
The two BOVPN virtual interfaces each make a connection between the two sites. The source and destination addresses are specified by the policy, which is the SIP policy in this example. Although the routes are not defined in the BOVPN virtual interface settings, the SIP policy uses SD-WAN routing to redirect traffic through the tunnel that has the lower latency connection. This encrypts the packets and sends the traffic through the tunnel.
You must configure a reverse route at Site B. For example, if a SIP connection originates at Site A and goes to Site B through the tunnel, the response traffic is sent through the same tunnel through which it was received only if a route to Site A exists at Site B.
This configuration example does not provide failover to the other tunnel. However, you can use SD-WAN to configure failover between BOVPN virtual interfaces based on loss, latency, and jitter metrics. Go to About SD-WAN and Configure SD-WAN.
Failover and Failback Based on Routing Table Metrics
Objective
For two sites that are connected with an MPLS link, enable traffic to automatically fail over and fail back to a secondary branch office VPN connection over an IP network.
Configuration Summary
- Configure the external interfaces for the primary connection between the two sites over the MPLS network. The primary connection must use dynamic routing, or must be configured as a BOVPN virtual interface. This is required so the primary route either gets a higher distance or is removed from the routing table when the primary connection is not available.
- Configure a BOVPN virtual interface for the secondary link between the two sites.
- Add a BOVPN virtual interface static route and set a high distance (for example, 200) for the route.
For a detailed configuration example, go to BOVPN Virtual Interface with Metric-Based Failover.
In Fireware v12.9 or higher, the Distance setting replaces the Metric setting.
How It works
With this configuration, there are two routes between the two sites:
- A route over the MPLS network
- Another static route through the BOVPN virtual interface
When two routes are available, the final decision about which path a packet takes is based on which route has higher priority (a lower distance) than the other. Because the BOVPN virtual interface route has a high distance, the Firebox uses the primary route through the MPLS link when it is available. If the MPLS link is not available, the primary route is either removed from the routing table, or it is assigned a higher distance than the route for the secondary BOVPN virtual interface. The Firebox then uses the route for the secondary BOVPN virtual interface because it has the lowest route distance. When the MPLS route is available again, the Firebox automatically fails back to use that route because it has a lower distance.
You could use a similar configuration to enable automatic failover and failback between two BOVPN virtual interfaces. To enable automatic failover and failback, create two BOVPN virtual interfaces, with a static route for each, and set the distance for the preferred BOVPN route lower than the distance for the backup BOVPN route.
BOVPN Virtual Interface with Dynamic Routing
Objective
Enable two sites to dynamically exchange information about multiple local networks through a secure VPN tunnel. With this configuration, you do not have to manually add and maintain explicitly configured routes between all the private networks at each site.
To configure dynamic routing with BGP to Microsoft Azure, you must use Microsoft PowerShell. Dynamic routing with OSPF to a Microsoft Azure virtual network is not supported. For more information, go to BOVPN Virtual Interface for Dynamic Routing to Microsoft Azure.
Dynamic routing with OSPF to an Amazon Web Services virtual network is not supported. For more information, go to BOVPN Virtual Interface for Dynamic Routing to Amazon Web Services (AWS).
Configuration summary
- Configure a branch office VPN between the two sites as a BOVPN virtual interface. On the VPN Routes tab, configure virtual IP addresses. Make sure to select the Start Phase 1 tunnel when it is inactive check box.
- Enable dynamic routing between the two sites. In the dynamic routing configuration, use the virtual IP addresses as the peer network IP addresses.
- For OSPF, use the network command, and configure the peer virtual IP address with a /32 netmask.
For example, network <peer_virtual_ip>/32 area 0.0.0.0 - For BGP, use the neighbor command, and the peer virtual IP address.
For example, neighbor <peer_virtual_ip> remote-as 65535
- For OSPF, use the network command, and configure the peer virtual IP address with a /32 netmask.
- Use dynamic routing commands to configure which local networks each device propagates routes for. To control the dynamic routes, you can use the Interface Cost for OSPF, or the Local Preference for BGP. For OSPF, the lower the Interface Cost, the more preferred the route. For BGP, the higher the Local Preference, the more preferred the route.
For detailed BOVPN configuration examples with dynamic routing, go to:
- BOVPN Virtual Interface with Dynamic Routing
- BOVPN Virtual Interface for Dynamic Routing to Cisco
- BOVPN Virtual Interface for Dynamic Routing to Microsoft Azure
- BOVPN Virtual Interface for Dynamic Routing to Amazon Web Services (AWS)
How It works
The BOVPN virtual interface makes a connection between the two sites. Each site propagates routes for the local networks, based on the dynamic routing configuration. The dynamic routing protocol enables each of the gateways to automatically learn the routes to the local networks behind the gateway at the other end of the BOVPN tunnel. The dynamic routing protocol you choose specifies whether the routes are preferred based on Interface Cost, Local Preference, or both.
Third-Party Integrations
To configure a BOVPN virtual interface connection from a Firebox to a third-party endpoint, go to:
Microsoft Azure
- BOVPN Virtual Interface for Dynamic Routing to Microsoft Azure
- BOVPN Virtual Interface for Static Routing to Microsoft Azure
Amazon AWS
- BOVPN Virtual Interface for Dynamic Routing to Amazon Web Services (AWS)
- BOVPN Virtual Interface for Static Routing to Amazon Web Services (AWS)
Cisco
- BOVPN Virtual Interface for Dynamic Routing to Cisco
- BOVPN Virtual Interface to Cisco ISR
- BOVPN Virtual Interface to Cisco ASA
Other third-party endpoints
BOVPN Virtual Interface with Microsoft Azure Active-Standby Failover
Objective
Enable VPN traffic to automatically fail over to a standby tunnel.
Configuration Summary
- Configure one Azure VPN gateway in active-standby mode. The Azure VPN configuration includes one public IP address, an active tunnel, and a standby tunnel.
For Azure configuration information, go to VPN Gateway Design in the Microsoft documentation. - Configure a Firebox BOVPN virtual interface with one gateway endpoint that connects to the public Azure IP address.
How It works
If the active tunnel fails, Microsoft Azure automatically fails over traffic to the standby tunnel.
BOVPN Virtual Interface with Microsoft Azure Active-Active Failover
Objective
Enable redundancy and load balancing for VPN traffic. Microsoft recommends active-active mode for higher throughput.
Configuration Summary
- Configure one Azure VPN gateway in active-active mode. The Azure VPN configuration includes two public IP addresses and two active tunnels.
For Azure configuration information, go to VPN Gateway Design in the Microsoft documentation. - Configure two Firebox BOVPN virtual interfaces.
- In the configuration for one of the BOVPN virtual interfaces, configure a gateway endpoint that connects to one of the public Azure IP addresses.
- In the configuration for the other BOVPN virtual interface, configure a gateway endpoint that connects to the other public Azure IP addresses.
How It works
- BGP ECMP routing provides load balancing and redundancy.
- Return traffic from Azure might use a different tunnel.
Configure policy-based routing in Fireware v12.2.1 or lower in the WatchGuard Knowledge Base