VPN tunnels for WAN backup between FortiGate Cisco devices
This article describes how to create VPN tunnels between a FortiGate firewall and Cisco routers using Virtual Tunnel Interfaces. OSPF is being used for routing. I used an unlicensed instance of FortiGate VM in GNS3 so you can recreate the setup without any financial investment. Links to full configurations are also available at the bottom of the post.
Layer 1 setup
The topology below was built using the following virtual devices:
- FortiGate appliance for GNS3
- IOU L3 15.4.1T
- VPCS for host emulation
- A built-in switch and a cloud object for accessing the FortiGate webui from my lab network.
The topology has 3 sites, all of them connected to a WAN router as well as the internet.
Layer 3 setup
To make things simple, I used /24 on all links:
The following loopback addresses are not shown but present in the config:
- HQ (used for OSPF router-id but not an interface): 172.31.0.1/32
- Branch1: 172.31.1.1/32
- Branch2: 172.31.2.1/32
- WAN: 172.31.255.255/32
- Internet: 150.1.1.1/32
The following VPN tunnels will be created:
Original state
Before setting up the tunnels, both branches are reachable from the HQ through the WAN router. The tunnel subnets (172.29.x.x) are not present. There are default routes on all devices pointing to the internet. Routing tables:
HQ # get router info routing-table all
[...]
S* 0.0.0.0/0 [10/0] via 101.1.1.1, port3
C 101.1.1.0/24 is directly connected, port3
C 172.25.0.0/24 is directly connected, port2
O 172.25.1.0/24 [110/11] via 172.25.0.1, port2, 00:02:53
O 172.25.2.0/24 [110/11] via 172.25.0.1, port2, 00:02:53
C 172.26.1.0/24 is directly connected, port1
O 172.27.1.0/24 [110/21] via 172.25.0.1, port2, 00:02:53
O 172.28.1.0/24 [110/21] via 172.25.0.1, port2, 00:02:53
O 172.31.1.1/32 [110/12] via 172.25.0.1, port2, 00:02:53
O 172.31.2.1/32 [110/12] via 172.25.0.1, port2, 00:02:53
O 172.31.255.255/32 [110/2] via 172.25.0.1, port2, 00:02:53
Branch1#sh ip route
[...]
S* 0.0.0.0/0 [1/0] via 102.2.2.1
102.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 102.2.2.0/24 is directly connected, Ethernet0/1
L 102.2.2.2/32 is directly connected, Ethernet0/1
172.25.0.0/16 is variably subnetted, 4 subnets, 2 masks
O 172.25.0.0/24 [110/20] via 172.25.1.1, 00:18:15, Ethernet0/0
C 172.25.1.0/24 is directly connected, Ethernet0/0
L 172.25.1.2/32 is directly connected, Ethernet0/0
O 172.25.2.0/24 [110/20] via 172.25.1.1, 00:18:15, Ethernet0/0
172.26.0.0/24 is subnetted, 1 subnets
O 172.26.1.0 [110/21] via 172.25.1.1, 00:18:15, Ethernet0/0
172.27.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.27.1.0/24 is directly connected, Ethernet1/0
L 172.27.1.1/32 is directly connected, Ethernet1/0
172.28.0.0/24 is subnetted, 1 subnets
O 172.28.1.0 [110/30] via 172.25.1.1, 00:18:15, Ethernet0/0
172.31.0.0/32 is subnetted, 3 subnets
C 172.31.1.1 is directly connected, Loopback0
O 172.31.2.1 [110/21] via 172.25.1.1, 00:18:15, Ethernet0/0
O 172.31.255.255 [110/11] via 172.25.1.1, 00:18:15, Ethernet0/0
Branch2#sh ip route
[...]
S* 0.0.0.0/0 [1/0] via 103.3.3.1
103.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 103.3.3.0/24 is directly connected, Ethernet0/1
L 103.3.3.2/32 is directly connected, Ethernet0/1
172.25.0.0/16 is variably subnetted, 4 subnets, 2 masks
O 172.25.0.0/24 [110/20] via 172.25.2.1, 01:48:13, Ethernet0/0
O 172.25.1.0/24 [110/20] via 172.25.2.1, 00:19:27, Ethernet0/0
C 172.25.2.0/24 is directly connected, Ethernet0/0
L 172.25.2.2/32 is directly connected, Ethernet0/0
172.26.0.0/24 is subnetted, 1 subnets
O 172.26.1.0 [110/21] via 172.25.2.1, 01:48:03, Ethernet0/0
172.27.0.0/24 is subnetted, 1 subnets
O 172.27.1.0 [110/30] via 172.25.2.1, 00:19:27, Ethernet0/0
172.28.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.28.1.0/24 is directly connected, Ethernet1/0
L 172.28.1.1/32 is directly connected, Ethernet1/0
172.31.0.0/32 is subnetted, 3 subnets
O 172.31.1.1 [110/21] via 172.25.2.1, 00:19:27, Ethernet0/0
C 172.31.2.1 is directly connected, Loopback0
O 172.31.255.255 [110/11] via 172.25.2.1, 01:48:13, Ethernet0/0
Note: the configuration of WAN and Internet routers are not discussed here. WAN provides OSPF routing in a single area 0, Internet connects the the 10x.x.x.x subnets.
Setting up VPN and routing
The WAN backup can be created in 5 steps per device for each branch office:
- Create Phase1 interface
- Create Phase2 interface
- Create VPN interface
- Create policies
- Set up routing
Note: I’m using DES for encryption because other algorithms are available only after installing a license on the FortiGate. In real world scenarios you should use AES (“aes128-sha1” on FortiGate, “esp-aes esp-sha-hmac” on Cisco side).
HQ firewall
The steps here describe the tunnel between HQ and Branch1; HQ-Branch2 is similar.
Creating Phase1 interface
config vpn ipsec phase1-interface
edit "Branch1"
set interface "port3"
set dhgrp 2
set proposal des-sha1
set remote-gw 102.2.2.2
set psksecret pass_Branch1
next
end
Creating Phase2 interface
config vpn ipsec phase2-interface
edit "Branch1-P2-1"
set phase1name "Branch1"
set proposal des-sha1
set dhgrp 2
next
end
Creating VPN interface
config system interface
edit "Branch1"
set vdom "root"
set ip 172.29.1.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 172.29.1.2
set interface "port3"
end
Creating policies
config firewall policy
edit 1
set srcintf "port1"
set dstintf "Branch1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set srcintf "Branch1"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
Set up routing
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 172.26.1.0 255.255.255.0
next
edit 2
set prefix 172.29.1.0 255.255.255.0
next
end
config ospf-interface
edit "Branch1"
set interface "Branch1"
set mtu-ignore enable
set network-type point-to-point
next
end
Branch1 router
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key pass_Branch1 address 0.0.0.0 0.0.0.0
crypto ipsec transform-set HQ_Tset esp-des esp-sha-hmac
crypto ipsec profile HQ
set transform-set HQ_Tset
exit
interface Tunnel0
ip address 172.29.1.2 255.255.255.0
ip ospf mtu-ignore
tunnel source 102.2.2.2
tunnel mode ipsec ipv4
tunnel destination 101.1.1.2
tunnel protection ipsec profile HQ
router ospf 1
network 172.27.1.0 0.0.0.255 area 0
network 172.29.1.0 0.0.0.255 area 0
end
Routing after the tunnels are created
VPN subnets (172.29.{1|2}.0/24) are visible, the remote sites are reachable through the WAN router (cost is 21 compared to the VPN tunnel’s 1001):
HQ # get router info routing-table all […]
S* 0.0.0.0/0 [10/0] via 101.1.1.1, port3
C 101.1.1.0/24 is directly connected, port3
C 172.25.0.0/24 is directly connected, port2
O 172.25.1.0/24 [110/11] via 172.25.0.1, port2, 01:21:19
O 172.25.2.0/24 [110/11] via 172.25.0.1, port2, 01:21:19
C 172.26.1.0/24 is directly connected, port1
O 172.27.1.0/24 [110/21] via 172.25.0.1, port2, 01:21:19
O 172.28.1.0/24 [110/21] via 172.25.0.1, port2, 01:21:19
O 172.29.1.0/24 [110/1011] via 172.25.0.1, port2, 00:24:16
C 172.29.1.1/32 is directly connected, Branch1
C 172.29.1.2/32 is directly connected, Branch1
O 172.29.2.0/24 [110/1011] via 172.25.0.1, port2, 00:23:18
C 172.29.2.1/32 is directly connected, Branch2
C 172.29.2.2/32 is directly connected, Branch2
O 172.31.1.1/32 [110/12] via 172.25.0.1, port2, 01:21:19
O 172.31.2.1/32 [110/12] via 172.25.0.1, port2, 01:21:19
O 172.31.255.255/32 [110/2] via 172.25.0.1, port2, 01:21:19
Failover scenario
Let’s shut down the Branch1 facing interface on WAN:
WAN(config)#int e0/1
WAN(config-if)#shut
WAN(config-if)#
*Apr 12 13:37:56.087: %OSPF-5-ADJCHG: Process 1, Nbr 172.31.1.1 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
WAN(config-if)#
*Apr 12 13:37:58.086: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Apr 12 13:37:59.090: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Now let’s check if HQ is reachable from Branch1:
Branch1#sh ip route 172.26.1.0
Routing entry for 172.26.1.0/24
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 172.29.1.1 on Tunnel0, 00:00:16 ago
Routing Descriptor Blocks:
* 172.29.1.1, from 172.31.0.1, 00:00:16 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
The HQ PC is reachable too: Branch1#ping 172.26.1.96 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.26.1.96, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/13 ms
Failback
Let’s restore the connection between WAN and Branch1:
WAN(config)#int e0/1
WAN(config-if)#no shut
WAN(config-if)#end
WAN#
*Apr 12 13:43:17.442: %SYS-5-CONFIG_I: Configured from console by console
WAN#
*Apr 12 13:43:18.382: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Apr 12 13:43:19.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
WAN#
*Apr 12 13:43:24.091: %OSPF-5-ADJCHG: Process 1, Nbr 172.31.1.1 on Ethernet0/1 from LOADING to FULL, Loading Done
WAN#
Routing entry for HQ site on Branch1:
Branch1#sh ip route 172.26.1.0
Routing entry for 172.26.1.0/24
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 172.25.1.1 on Ethernet0/0, 00:00:41 ago
Routing Descriptor Blocks:
* 172.25.1.1, from 172.31.0.1, 00:00:41 ago, via Ethernet0/0
Route metric is 21, traffic share count is 1
As you can see, HQ is reachable through WAN again with a cost of 21.
Screenshots
For those who are more familiar with FortiGate’s Web GUI, here are the screenshots of the config above:
Note: As you can see, the policy is missing for port2 - port1 (WAN - LAN) connections. This is a limitation of the unlicensed VM, no more than 5 policies are allowed.
Config files
You can download all config files from here.