Partially–redundant route-based VPN example
This example demonstrates how to set up a partially redundant IPsec VPN between a local FortiGate unit and a remote VPN peer that receives a dynamic IP address from an ISP before it connects to the FortiGate unit. For more information about FortiGate dialup-client configurations, see FortiGate dialup-client configurations on page 1716.
When a FortiGate unit has more than one interface to the Internet (see FortiGate_1), you can configure redundant routes. If the primary connection fails, the FortiGate unit can establish a VPN using the redundant connection.
In this case, FortiGate_2 has only one connection to the Internet. If the link to the ISP were to go down, the connection to FortiGate_1 would be lost, and the tunnel would be taken down. The tunnel is said to be partially redundant because FortiGate_2 does not support a redundant connection.
In the configuration example:
- Both FortiGate units operate in NAT mode.
- Two separate interfaces to the Internet (192.168.10.2 and 172.16.20.2) are available on FortiGate_1. Each interface has a static public IP address.
- FortiGate_2 has a single connection to the Internet and obtains a dynamic public IP address (for example, 172.16.30.1) when it connects to the Internet.
- FortiGate_2 forwards IP packets from the SOHO network (10.31.101.0/24) to the corporate network (10.21.101.0/24) behind FortiGate_1 through a partially redundant IPsec VPN. Encrypted packets from FortiGate_2 are addressed to the public interface of FortiGate_1. Encrypted packets from FortiGate_1 are addressed to the public IP address of FortiGate_2.
There are two possible paths for communication between the two units. In this example, these paths, listed in descending priority, are:
- FortiGate_1 WAN 1 to FortiGate_2 WAN 1
- FortiGate_1 WAN 2 to FortiGate_2 WAN 1
For each path, VPN configuration, security policies and routing are defined. By specifying a different routing distance for each path, the paths are prioritized. A VPN tunnel is established on each path, but only the highest priority one is used. If the highest priority path goes down, the traffic is automatically routed over the next highest priority path. You could use dynamic routing, but to keep this example simple, static routing is used.
Example partially redundant route-based configuration
Configuring FortiGate_1
Whenconfiguring FortiGate_1, you must:
- Configure the interfaces involved in the VPN.
- Define the Phase 1 configuration for each of the two possible paths, creating a virtual IPsec interface for each one.
- Define the Phase 2 configuration for each of the two possible paths.
- Configure incoming and outgoing security policies between the internal interface and each of the virtual IPsec interfaces.
To configure the network interfaces
1. Go to Network > Interfaces.
2. Select the Internal interface and select Edit. Enter the following information and select OK:
Addressing mode Manual
IP/Netmask 10.21.101.2/255.255.255.0
3. Select the WAN1 interface and select Edit. Enter the following information and select OK:
Addressing mode Manual
IP/Netmask 192.168.10.2/255.255.255.0
4. Select the WAN2 interface and select Edit. Enter the following information and select OK:
Addressing mode Manual
IP/Netmask 172.16.20.2/255.255.255.0
To configure the IPsec interfaces (Phase 1 configurations)
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter the following information, and select OK:
Name Site_1_A
Remote Gateway Dialup User
Local Interface WAN1
Mode Main
Authentication Method Preshared Key
Pre–shared Key Enter the preshared key.
Peer Options Any peer ID
Advanced
Dead Peer Detection Select
4. Create a new tunnel and enter the following Phase 1 information:
Name Site_1_B
Remote Gateway Dialup User
Local Interface WAN2
Mode Main
Authentication Method Preshared Key
Pre–shared Key Enter the preshared key.
Peer Options Any peer ID
Advanced
Dead Peer Detection Select
To define the Phase 2 configurations for the two VPNs
1. Open the Phase 2 Selectors panel.
2. Enter the following information and select OK:
Name Route_A
Phase 1 Site_1_A
3. Enter the following Phase 2 information for the subsequent route:
Name Route_B
Phase 1 Site_1_B
To configure routes
1. Go to Network > Static Routes.
2. Select Create New, enter the following default gateway information and select OK:
Destination IP/Mask 0.0.0.0/0.0.0.0
Device WAN1
Gateway 192.168.10.1
Distance (Advanced) 10
To configure security policies
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and select OK:
Incoming Interface Internal
Source Address All
Outgoing Interface Site_1_A
Destination Address All
Schedule Always
Service Any
Action ACCEPT
3. Select Create New.
4. Enter the following information, and select OK:
Incoming Interface Internal
Source Address All
Outgoing Interface Site_1_B
Destination Address All
Schedule Always
Service Any
Action ACCEPT
Configuring FortiGate_2
The configuration for FortiGate_2 is similar to that of FortiGate_1. You must
- configure the interface involved in the VPN
- define the Phase 1 configuration for the primary and redundant paths, creating a virtual IPsec interface for each one
- define the Phase 2 configurations for the primary and redundant paths, defining the internal network as the source address so that FortiGate_1 can automatically configure routing
- configure the routes for the two IPsec interfaces, assigning the appropriate priorities
- configure security policies between the internal interface and each of the virtual IPsec interfaces
To configure the network interfaces
1. Go to Network > Interfaces.
2. Select the Internal interface and select Edit. Enter the following information and select OK:
Addressing mode Manual
IP/Netmask 10.31.101.2/255.255.255.0
3. Select the WAN1 interface and select Edit. Set the Addressing mode to DHCP.
To configure the two IPsec interfaces (Phase 1 configurations)
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter the following information, and select OK:
Name Site_2_A
Remote Gateway Static IP Address
IP Address 192.168.10.2
Local Interface WAN1
Mode Main
Authentication Method Preshared Key
Pre–shared Key Enter the preshared key.
Peer Options Any peer ID
Advanced
Dead Peer Detection Select
4. Create a new tunnel and enter the following Phase 1 information:
Name Site_2_B
Remote Gateway Static IP Address
IP Address 172.16.20.2
Local Interface WAN1
Mode Main
Authentication Method Preshared Key
Pre–shared Key Enter the preshared key.
Peer Options Any peer ID
Advanced
Dead Peer Detection Select
To define the Phase 2 configurations for the two VPNs
1. Open the Phase 2 Selectors panel.
2. Enter the following information and select OK:
Name Route_A
Phase 1 Site_2_A
Advanced
Source Address 10.31.101.0/24
3. Enter the following Phase 2 information for the subsequent route:
Name Route_B
Phase 1 Site_2_B
Advanced
Source Address 10.31.101.0/24
To configure routes
1. Go to Network > Static Routes.
2. Select Create New, enter the following information and then select OK:
Destination IP/Mask 10.21.101.0/255.255.255.0
Device Site_2_A
Distance (Advanced) 1
3. Select Create New, enter the following information and then select OK:
Destination IP/Mask 10.21.101.0/255.255.255.0
Device Site_2_B
Distance (Advanced) 2
To configure security policies
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and select OK:
Incoming Interface Internal
Source Address All
Outgoing Interface Site_2_A
Destination Address All
Schedule Always
Service Any
Action ACCEPT
3. Select Create New.
4. Enter the following information, and select OK:
Incoming Interface Internal
Source Address All
Outgoing Interface Site_2_B
Destination Address All
Schedule Always
Service Any
Action ACCEPT
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
Ok, so next-hop router for WAN1 is 192.168.10.1, belonging to ISP1.
The next-hop for WAN2 is not mentioned, but let’s suppose it’s 172.16.20.1, belonging to ISP2.
FortiGate_1 is configured to reach FortiGate_2 (172.16.30.1) via 192.168.10.1. Fine.
Now let’s say this path stops working for any reason, and DPD detects that. What on earth tells FortiGate_1 that it’s supposed to reach 172.16.30.1 via next-hop of WAN2, 172.16.20.1? There’s no entry for that in FortiGate_1’s routing table, and there are no means to update the table.
So how exactly should the traffic be delivered via ISP2?
I usually have health checks that will pull routes if the link goes down. For instance, two routes to network A. One with a higher priority. If the primary fails, the health check pulls that route and it starts using the secondary link.
Thanks, Mike.
How exactly do you configure health checks to manipulate the routing table?
Anyway, I’ve found that if it’s possible to assign two public addresses to the remote gateway, then it’s very easy to configure static routes via different ISPs for different remote addresses, and then define separate IPsec tunnels to each address, utilizing different ports (facing different ISPs) for each. Then you can set up either dynamic routing with the remote gateway or use static routes with different priorities, and this will give you a failover solution without need for special health checks.
I have my health checks do pings. If the device on the other end I’m trying to query fails to respond it yanks the route and goes to the backup. It’s basic but handles my needs very well.