Lab 9. 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 case you already solved the previous lab (with HA), there is need to stop all nodes, remove all connections, and delete the switches (or keep them for later, but not connected to anything).


In the first 2 Fortinet labs, we configured a single FGT device (which will be referred from now as Local-FortiGate - you can also rename the node after shutting it down) which is licensed (it may appear in Dashboard with 'Validation Overdue', but you can ignore it as IPsec will still work). Revert to a revision without HA configured and check again the mgmt ip.

We will use the following interfaces:

If 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 This is assigned by the dhcp server.

- 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. You should have for port2 the ip 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


Do this just in case you did not solve the last lab (HA):

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

If you have a revision before adding the HA, revert to it. Else, go to cli > config system ha > unset all variables, then end.

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

Configure the following interfaces:

- port1: 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 network as the first FGT. Use ip address for port3 and enable ping. You can also use here the alias outside_redundant

After finishing the network 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 [5p]

[ 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 destination via tunnel interface ToLocal

- also on remote FGT, use port2 for firewall policies

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

FGT81 # 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

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

We are going skip pages 100โ†’104 as there is a bug in this new release, related to editing an already existing custom IPsec tunnel: from remote dialup to static ip address.

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

[ pages 105โ†’115 ]

- we do not have a 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 these 2 scenarios:

a. ToRemote UP + ping from client2 + 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 sub-interface) + ToRemoteBackup UP + ping from client2 + check packets. Check from Dashboard that tunnel backup is UP

sred/lab7.txt ยท Last modified: 2022/12/16 15:37 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