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).

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:

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 10.3.0.0/16. 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 172.16.0.1 and for client1 172.16.0.2 (or any other ip given by DHCP server) - subnet in network 172.16.0.0/24

- 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.

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 10.0.0.1/30 + 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

# 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

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*      0.0.0.0/0 [1/0] is a summary, Null
[...]
S       10.128.0.20/32 [10/0] via 10.3.255.254, port1

- port2: connection with client2 (reuse the one from the latest lab and connect it to port2 of FGT2). Use the network 172.30.0.0/24 with 172.30.0.1 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 10.0.0.2/30 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
							vunl0_2_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 10.3.0.74
PING 10.3.0.74 (10.3.0.74): 56 data bytes
64 bytes from 10.3.0.74: icmp_seq=0 ttl=255 time=1.0 ms
64 bytes from 10.3.0.74: icmp_seq=1 ttl=255 time=1.2 ms
^C
--- 10.3.0.74 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 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=1.8 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=1.2 ms
^C

# remote
FGT81_2 # exec ping 10.3.0.34
PING 10.3.0.34 (10.3.0.34): 56 data bytes
64 bytes from 10.3.0.34: icmp_seq=0 ttl=255 time=1.5 ms
64 bytes from 10.3.0.34: icmp_seq=1 ttl=255 time=0.8 ms
^C
FGT81_2 # exec ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 10.0.0.1: 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.

[ pages 90→99 ]

- in our case, for local FGT, we have interface port1, with Local Address 172.16.0.0/24 (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 172.30.0.0/24 and remote network 172.16.0.0/24 (each branch subnet is specified). Also, for static route, use destination 172.16.0.0/24 via tunnel interface ToLocal

- also on remote FGT, use port2 for firewall policies

- at the end of the exercise, check from client1 ping to 172.30.0.2 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*      0.0.0.0/0 [5/0] via 10.3.255.254, port1
C       10.3.0.0/16 is directly connected, port1
C       10.10.100.0/30 is directly connected, vlink0
S       10.128.0.0/24 [10/0] via 10.3.255.254, port1
C       172.16.0.0/24 is directly connected, port2
S       172.30.0.0/24 [15/0] via 10.3.0.74, ToRemote

See that there was added a static route via ToRemote to client2's network 172.30.0.0/24.

[ 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 172.16.0.2 - 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 (10.0.0.1 - local or 10.0.0.2 - remote) with the already known local/remote subnets (172.16.0.0/24 for the first one and 172.30.0.0/24 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 172.16.0.2 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 172.16.0.2 from client2 + check packets. Check from Dashboard that tunnel backup is UP