Improve Branch Office VPN (BOVPN) Tunnel Availability
- Unreliable external connection — One or both BOVPN endpoints might have external connections with high latency, high packet fragmentation, and high packet loss, which can make a connection unreliable. These factors have a greater impact on BOVPN traffic than on other common traffic, like HTTP and SMTP. With BOVPN traffic, the encrypted packets must arrive at the destination endpoint, be decrypted, and then reassembled before the unencrypted traffic can be routed to the destination IP address.
- Older WatchGuard endpoint and software — We conduct compatibility tests between new WatchGuard products and older devices by using the latest software available for older devices. With older software, issues might exist that we fixed in more recent software releases.
- Third-party endpoint — Because Fireboxes are based on the IPSec standard, they are compatible with most third-party endpoints. However, some third-party endpoint devices are not IPSec-compliant because of software problems or proprietary settings.
- Low or no traffic — If there is a low volume of traffic through an IPSec tunnel, or if there are long periods of time when no traffic goes through the tunnel, the Firebox and most third-party endpoints intentionally tear down the VPN connection. This is done to avoid brute force attacks between automatic rekeys. When traffic tries to flow through the tunnel again, the tunnel is rebuilt and rekeyed.
If BOVPN availability issues continue after you Upgrade Fireware OS, try these options:
In the IKEv1 settings, you can enable Dead Peer Detection, an industry standard used by most IPSec devices. We recommend that you select Dead Peer Detection if both endpoint devices support it.
When you enable Dead Peer Detection, the Firebox monitors tunnel traffic to identify whether a tunnel is active. If no traffic has been received from the remote peer for the amount of time specified by the Traffic idle timeout value, and a packet is waiting to be sent to the peer, the Firebox sends a query. If there is no response after the number of Max retries, the Firebox tears down the tunnel and renegotiates the Phase 1 connection. For more information about Dead Peer Detection, see RFC 3706.
We recommend that you do not enable IKE Keep-alive, which is an older technology that is less reliable and scalable.
To enable Dead Peer Detection, from Fireware Web UI:
- Select VPN > Branch Office VPN.
- Select the gateway and click Edit.
- Select the Phase 1 Settings tab.
- Select Dead Peer Detection (RFC3706).
To enable Dead Peer Detection, from Policy Manager:
- Select VPN > Branch Office Gateways.
- Select the gateway and click Edit.
- Select the Phase 1 Settings tab.
- Select Dead Peer Detection (RFC3706).
The default BOVPN settings on the Firebox are meant for compatibility with older WatchGuard devices and third-party devices. If the peer endpoint device supports IKEv2 and stronger encryption and authentication settings, we recommend that you change default settings for greater security and performance.
These tables show the default and recommended values for each BOVPN setting.
| BOVPN Settings | Default Values (for compatibility) | Recommended Values (for performance and security) |
|---|---|---|
| Version | IKEv1 | IKEv2 |
| Mode | Main (Select Aggressive if one of the devices has a dynamic external IP address.) |
Not applicable if you select IKEv2 as the version |
| NAT Traversal | Yes | Yes |
| NAT Traversal Keep-alive Interval | 20 seconds | 20 seconds |
| IKE Keep-alive | Disabled | Disabled |
| IKE Keep-alive Message Interval | None | None |
| IKE Keep-alive Max Failures | None | None |
| Dead Peer Detection (RFC3706) | Enabled | Enabled |
| Dead Peer Detection Traffic Idle Timeout | 20 seconds | 20 seconds |
| Dead Peer Detection Max Retries | 5 | 5 |
| Phase 1 Transform Settings | Default Values (for compatibility) | Recommended Values (for performance and security)1 |
|---|---|---|
| Authentication Algorithm | SHA2-256 | Not applicable if you specify AES-GCM as the encryption algorithm |
| Encryption Algorithm | AES (256-bit) | AES-GCM (256-bit)2 |
| SA Life or Negotiation Expiration (hours) | 24 | 24 |
| Diffie-Hellman Group | 14 | 202 |
1. In the Phase 1 settings, you must select the IKEv2 option to see AES-GCM options.
2. Because Phase 1 settings generally do not impact BOVPN performance, we recommend AES-GCM (256-bit) and Diffie-Hellman Group 20 for greater security.
| PHASE 2 Proposal Settings | Default Values (for compatibility) | Recommended Values (for performance and security) |
|---|---|---|
| Type | ESP | ESP |
| Authentication Algorithm | SHA2-256 | Not applicable if you specify AES-GCM as the encryption algorithm |
| Encryption Algorithm | AES (256 bit) | AES-GCM (128-bit) |
| Force Key Expiration | Enable | Enable |
| Phase 2 Key Expiration Time (hours) | 8 | 8 |
| Perfect Forward Secrecy (PFS) | Enabled | Enabled |
| Diffie-Hellman Group | 14 | 19 |
Do not enable the Phase 2 Key Expiration Traffic (kilobytes) setting, which is a default setting in Fireware v11.9.1 or lower. This setting can cause excessive rekeys, high CPU load, and dropped packets, which can destabilize your VPN. The Phase 2 Key Expiration Traffic (kilobytes) setting is not compatible with most third-party devices.
If no traffic goes through an IPSec tunnel for a period of time, a gateway endpoint might decide that the other endpoint is unavailable and tear down the tunnel. The gateway endpoint will not renegotiate the VPN tunnel until traffic is sent through the tunnel again. In the Phase 1 settings, if you specify IKEv2, this process occurs quickly and might not be noticeable.
If you notice dropped packets, verify the version specified in your Phase 1 settings. If you have specified IKEv1 and use the other default Phase 1 and 2 settings, especially default settings from Fireware v11.x or lower, you might notice dropped packets during rekeys.
If you use IKEv1 and legacy default settings, and noticed dropped packets during rekeys, make sure traffic goes through the tunnel at all times.
For example, you could send these types of traffic through the tunnel:
- Continuous ping
- Log messages
- SNMP
- Other monitoring software
Continuous Ping
For a simple solution, you can configure a continuous ping to send traffic through the tunnel to a reliable device, such as a server.
Log Messages
You can configure the Firebox to send log messages through the VPN tunnel to a log server.
If you do not have a log server, you can intentionally configure the Firebox to send log message traffic to a log server that does not exist. This creates a consistent but small amount of traffic sent through the tunnel, which can help reduce the number of tunnel rebuilds and rekeys.
When you specify an IP address for the log server, whether the log server exists or not, follow these guidelines:
- The log server IP address you specify must be an IP address that is included in the remote tunnel route settings.
For more information, go to Add Routes for a Tunnel. - The log server IP address should not be an IP address that is assigned to a real device.
You must also determine which type of logging to use. Different types of logging generate different amounts of traffic:
WatchGuard Dimension
No log data is sent until the Firebox has connected to Dimension. The only types of traffic sent through the tunnel are attempts to connect to Dimension. This can be enough traffic to help tunnel stability with the least impact on other BOVPN traffic.
Syslog
Log data is immediately sent to the syslog server IP address. The volume of log data depends on the traffic that the device handles. Syslog logging usually generates enough traffic that packets always pass through the tunnel. The volume of traffic can occasionally make regular BOVPN traffic slower, but this is not common.
To improve stability and have the least impact on BOVPN traffic, try Dimension first. If this does not improve the stability of the BOVPN tunnel, try syslog logging.
Different options you can try include:
- Configure one endpoint to send Dimension log traffic through the tunnel.
- Configure the other endpoint to send Dimension log traffic through the tunnel.
- Configure both endpoints to send Dimension log traffic through the tunnel.
- Configure one endpoint to send syslog log traffic through the tunnel.
- Configure only the other endpoint to send syslog log traffic through the tunnel.
- Configure both endpoints to send syslog log traffic through the tunnel.
To configure your Firebox to send log data to a WatchGuard Dimension Server through the tunnel, go to Add a Dimension or WSM Log Server.
To configure your Firebox to send syslog data through the tunnel, go to Configure Syslog Server Settings.
SNMP Messages
You can configure your Firebox to send information to an SNMP server. For more information, go to About SNMP.