Lab 8. Fortigate Site-to-site VPN



After a period of time, we finally managed to open a new branch in a different city that is also using a FortiGate device for network protection. We just need to create an IPsec tunnel to mutual connect branches using different configurations (dialup user vs. static ip, aggresive mode vs. main). We are going to start with a single tunnel, then create a backup one (using a secondary network connection).

Lab infra


In the past 2 weeks, we configured a single FGT device (which will be referred from now as Local-FortiGate - you can also rename the node with this name after shutting it down) with 2 VDOMs (root and customer) which is licensed (it may appear in Dashboard with 'Validation Overdue', but you can ignore it as VDOM and IPsec will still work). VDOMs are going to be kept on this FGT and we will require only to use root VDOM as we will use the following interfaces:

As VDOMs are still enabled on the first FGT, you will need the following syntax to access the interfaces config (for example):

FGT81 # config vdom

FGT81 (vdom) # edit root
current vf=root:0

FGT81 (root) # show system interface ?
# see here port1 configuration

- port1: for GUI access from your host and principal tunnel connection with the peer (FGT2 or Remote-FortiGate) - subnet in network

You may see that you cannot access webui via http/https. This is caused by the changing of your public ip address, which means also the internal one (10.12*.*.*) is going to be changed and the added static route by you will be useless. In this case, redo the steps from the previous lab for Licensing, with the exception of 2 and 3 (no need to readd the license and reboot machine).

- port2: used for creating a client network (the branch we need to connect via IPsec tunnel). For this, you can keep client1 from the previous lab and remove client2 from port4 interface (found in customer VDOM). You should have for port2 interface and for client1 (or any other ip given by DHCP server) - subnet in network

- port3: used for creating a backup connection between the 2 FGT devices. For this, we need a new Cloud Network that will connect virtual interfaces and simulates a new ISP connection (same or different) from both sides. You can use here the alias outside_redundant.

Note: the second Cloud will not connect FGT machines to Internet, as the bridge pnet1 that links those 2 virtual interfaces are not connected to an external interface (like eth0).

Firstly shut down FGT and client2, then remove the connection between those two.

Steps for backup connection and ip configuration:

1. Create a new Network > Type Cloud 1

2. Link FGT port3 to Cloud 1

3. Start the device and check the port2 network (as defined above) and for port3 use ip + enable ping (if it is not already enabled) and disable dhcp server

4. Check the ip address assigned for client1 and if the gateway is reachable


For the second FGT (FGT2 or Remote-FortiGate), create a new node with 4 interfaces, 1 vCPU, 2 GB RAM, then connect port1 to Cloud0 (already added to topology), port3 to Cloud1 (already added to topology), and port2 to client2. Start client2 and FGT (Remote-FortiGate), then you will need firstly to change the mac address:

# config sys int
# edit port1
# set macaddr <MAC address> - use here the format: 50:00:00:byte_2_eveng_ip:byte3_eveng_ip+1:byte4_eveng_ip
# end
# exec router restart

Then, repeat all steps from the latest lab regarding Licensing (use for it the secondary license available on moodle) and configure the following interfaces:

- port1: , modify the mac address:

the ip is again taken via dhcp. The static routes should be the same as for FGT1. Example

FGT81_2 # get router info routing-table details 

Routing table for VRF=0
S* [1/0] is a summary, Null
S [10/0] via, port1

- port2: connection with client2 (reuse the one from the latest lab and connect it to port2 of FGT2). Use the network with for port2 and dhcp server configured (with .2 - .254 pool). Enable also http, https, ping for admin access. Then, go to client2, check the ip from eth0 and ping the firewall.

- port3: connection with Cloud1, in the same netw as the first FGT. Use ip address for port3 and enable ping. You can also use here the alias outside_redundant

After finishing the netw configuration on both machines, check the following:

- from eve-ng machine (root:student credentials), see the bridge configuration (pnet1 for Cloud1):

root@SRED:~# brctl show
bridge name	bridge id		STP enabled	interfaces
pnet1		8000.06736dc766dd	no		vunl0_1_2
# ids may differ, but see that there are 2 virtual interfaces attached to bridge pnet1

- check ping via port1 and port3 work from both endpoints:

# from root vdom on fgt local
FGT81 (root) # exec ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=1.0 ms
64 bytes from icmp_seq=1 ttl=255 time=1.2 ms
--- ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.0/1.1/1.2 ms

FGT81 (root) # exec ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=1.8 ms
64 bytes from icmp_seq=1 ttl=255 time=1.2 ms

# remote
FGT81_2 # exec ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=1.5 ms
64 bytes from icmp_seq=1 ttl=255 time=0.8 ms
FGT81_2 # exec ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from icmp_seq=1 ttl=255 time=0.8 ms

In the end, this is the topology we are going to use:


We are going again to use the pdf file with Fortinet Exercises - go to Lab 5: IPsec VPN Configuration (page 90).

Skip again the configuration revert from the beginning.

Exercise 1 - dialup user + custom ipsec tunnel [3p]

[ pages 90โ†’99 ]

- in our case, for local FGT, we have interface port1, with Local Address (client1 network). Also, for firewall policies, use port2 instead of port3, and use ALL for source and dest ips (no need to really create address objects)

- on remote FGT, configure VPN tunnel with static ip address of local FGT port1, local network and remote network (each branch subnet is specified). Also, for static route, use dst via tunnel interface ToLocal

- also on remote FGT, use port2 for firewall policies

- at the end of the ex, check from client1 ping and routing table

FGT81 # config vdom 

FGT81 (vdom) # edit root 
current vf=root:0

FGT81 (root) # get router info routing-table details 
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

Routing table for VRF=0
S* [5/0] via, port1
C is directly connected, port1
C is directly connected, vlink0
S [10/0] via, port1
C is directly connected, port2
S [15/0] via, ToRemote
C is directly connected, port3
S [10/0] via, vlink0

See that there was added a static route via ToRemote to client2's network

Exercise 2 - static ip on both ends [2p]

[ pages 100โ†’104 ]

- on local FGT, use the ip of remote one from port1 (10.3.*.*) and remote subnet

- as for local there is used also static ip (no more dialup client), we need to also add a default route to via tunnel ToRemote

- in the end, test ping from both clients (tunnels should bring up after the first icmp echo is sent):

root@ubuntu:/home/eve/Desktop# ping -c 3
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=2 ttl=62 time=3.89 ms
64 bytes from icmp_seq=3 ttl=62 time=2.64 ms

--- ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2004ms
rtt min/avg/max/mdev = 2.647/3.269/3.891/0.622 ms

Exercise 3 - redundant tunnel + site-to-site vpn [5p]

[ pages 105โ†’115 ]

- we do not have a any configuration available for remote FGT, so all configs will be made on both FGTs (in mirror)

- configure firstly the authentication mode to Main (ID protection) on remote FGT (VPN > IPSec Tunnels > ToLocal > Authentication), then try to ping from client2 - it should fail with 'Destination Net Unreachable'. See also that the tunnels on both machines are down. After this, start doing ex.3 by going to page 106.

- create on each FGT a new ipsec tunnel: for 'Site-to-site' vpn config on both FGTs, use peer ips from port3 ( - local or - remote) with the already known local/remote subnets ( for the first one and for the second one)

- do the review from pg. 110 on both machines (static routes, firewall policies and address group + objects)

- in the end, test all 3 scenarios:

a. ToRemote UP + ping from client1 + check packets using diagnose tool from Forti cli. First packet will fail due to tunnel bringup and the second tunnel will remain DOWN.

b. ToRemote DOWN (manually bring down subinterface) + ToRemoteBackup UP + ping from client1 + check packets. Check from Dashboard that tunnel backup is UP

c. ToRemote UP + ToRemoteBackup UP + ping from client1 + check packets. See that even if we already had second tunnel connection UP and the first one DOWN, the first packet is still dropped as the interface ToRemote is enabled and waits for the IPsec tunnel to come up.

sred/lab7.txt ยท Last modified: 2022/01/16 15:16 by horia.stoenescu
CC Attribution-Share Alike 3.0 Unported Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0