Redundant VPN configurations
This section discusses the options for supporting redundant and partially redundant IPsec VPNs, using routebased approaches.
The following topics are included in this section: Configuration overview
Configuration overview
A FortiGate unit with two interfaces connected to the Internet can be configured to support redundant VPNs to the same remote peer. If the primary connection fails, the FortiGate unit can establish a VPN using the other connection.
Redundant tunnels do not support Tunnel Mode or manual keys. You must use Interface Mode.
A fully-redundant configuration requires redundant connections to the Internet on both peers. The figure below shows an example of this. This is useful to create a reliable connection between two FortiGate units with static IP addresses.
When only one peer has redundant connections, the configuration is partially-redundant. For an example of this, see Configuration overview on page 157. This is useful to provide reliable service from a FortiGate unit with static IP addresses that accepts connections from dialup IPsec VPN clients.
In a fully-redundant VPN configuration with two interfaces on each peer, four distinct paths are possible for VPN traffic from end to end. Each interface on a peer can communicate with both interfaces on the other peer. This ensures that a VPN will be available as long as each peer has one working connection to the Internet.
You configure a VPN and an entry in the routing table for each of the four paths. All of these VPNs are ready to carry data. You set different routing distances for each route and only the shortest distance route is used. If this route fails, the route with the next shortest distance is used.
The redundant configurations described in this chapter use route-based VPNs, otherwise known as virtual IPsec interfaces. This means that the FortiGate unit must operate in NAT mode. You must use auto-keying. A VPN that is created using manual keys cannot be included in a redundant-tunnel configuration.
The configuration described here assumes that your redundant VPNs are essentially equal in cost and capability. When the original VPN returns to service, traffic continues to use the replacement VPN until the replacement VPN fails. If your redundant VPN uses more expensive facilities, you want to use it only as a backup while the main VPN is down. For information on how to do this, see Configuration overview on page 157. 157
Redundant VPN configurations Configuration overview
Example redundant-tunnel configuration
A VPN that is created using manual keys cannot be included in a redundant-tunnel configuration.
General configuration steps
A redundant configuration at each VPN peer includes:
- One Phase 1 configuration (virtual IPsec interface) for each path between the two peers. In a fully-meshed redundant configuration, each network interface on one peer can communicate with each network interface on the remote peer. If both peers have two public interfaces, this means that each peer has four paths, for example.
- One Phase 2 definition for each Phase 1 configuration.
- One static route for each IPsec interface, with different distance values to prioritize the routes.
- Two Accept security policies per IPsec interface, one for each direction of traffic. l Dead peer detection enabled in each Phase 1 definition.
The procedures in this section assume that two separate interfaces to the Internet are available on each VPN peer.
Redundant VPN configurations
Configuring the VPN peers – route-based VPN
VPN peers are configured using Interface Mode for redundant tunnels.
Configure each VPN peer as follows:
- Ensure that the interfaces used in the VPN have static IP addresses.
- Create a Phase 1 configuration for each of the paths between the peers.
- Enable dead peer detection so that one of the other paths is activated if this path fails.
- Enter these settings in particular, and any other VPN settings as required:
Path 1
| Remote Gateway | Select Static IP Address. |
| IP Address | Type the IP address of the primary interface of the remote peer. |
| Local Interface | Select the primary public interface of this peer. |
| Dead Peer Detection | Enable |
Path 2
| Remote Gateway | Select Static IP Address. |
| IP Address | Type the IP address of the secondary interface of the remote peer. |
| Local Interface | Select the primary public interface of this peer. |
| Dead Peer Detection | Enable |
Path 3
| Remote Gateway | Select Static IP Address. |
| IP Address | Type the IP address of the primary interface of the remote peer. |
| Local Interface | Select the secondary public interface of this peer. |
| Dead Peer Detection | Enable |
Path 4
| Remote Gateway | Select Static IP Address. |
| IP Address | Type the IP address of the secondary interface of the remote peer. |
| Local Interface | Select the secondary public interface of this peer. |
| Dead Peer Detection | Enable |
For more information, see Phase 1 parameters on page 52.
Redundant VPN configurations Configuration overview
- Create a Phase 2 definition for each path. See Phase 2 parameters on page 72. Select the Phase 1 configuration (virtual IPsec interface) that you defined for this path. You can select the name from the Static IP Address part of the list.
- Create a route for each path to the other peer. If there are two ports on each peer, there are four possible paths between the peer devices.
| Destination IP/Mask | The IP address and netmask of the private network behind the remote peer. |
| Device | One of the virtual IPsec interfaces on the local peer. |
| Distance | For each path, enter a different value to prioritize the paths. |
- Define the security policy for the local primary interface. See Defining VPN security policies on page 1. You need to create two policies for each path to enable communication in both directions. Enter these settings in particular:
| Incoming Interface | Select the local interface to the internal (private) network. |
| Source Address | All |
| Outgoing Interface | Select one of the virtual IPsec interfaces you created in Step 2. |
| Destination Address | All |
| Schedule | Always |
| Service | Any |
| Action | ACCEPT |
- Select Create New, leave the Policy Type as Firewall and leave the Policy Subtype as Address, and enter these settings:
| Incoming Interface | Select one of the virtual IPsec interfaces you created in Step 2. |
| Source Address | All |
| Outgoing Interface | Select the local interface to the internal (private) network. |
| Destination Address | All |
| Schedule | Always |
| Service | Any |
| Action | ACCEPT |
- Place the policy in the policy list above any other policies having similar source and destination addresses.
- Repeat this procedure at the remote FortiGate unit.
Redundant VPN configurations
Creating a backup IPsec interface
You can configure a route-based VPN that acts as a backup facility to another VPN. It is used only while your main VPN is out of service. This is desirable when the redundant VPN uses a more expensive facility.
You can configure a backup IPsec interface only in the CLI. The backup feature works only on interfaces with static addresses that have dead peer detection enabled. The monitor option creates a backup VPN for the specified Phase 1 configuration.
In the following example, backup_vpn is a backup for main_vpn.
config vpn ipsec phase1-interface edit main_vpn set dpd on set interface port1 set nattraversal enable set psksecret “hard-to-guess” set remote-gw 192.168.10.8 set type static
end edit backup_vpn set dpd on set interface port2 set monitor main_vpn set nattraversal enable set psksecret “hard-to-guess” set remote-gw 192.168.10.8 set type static end