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

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

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

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*      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 netw 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 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
							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 dst 172.16.0.0/24 via tunnel interface ToLocal

- also on remote FGT, use port2 for firewall policies

- at the end of the ex, check from client1 ping 172.30.0.2 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*      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
C       192.168.0.0/24 is directly connected, port3
S       192.168.2.0/24 [10/0] via 10.10.100.2, vlink0

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

[ pages 100→104 ]

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

- as for local there is used also static ip (no more dialup client), we need to also add a default route to 172.30.0.0/24 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 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=2 ttl=62 time=3.89 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=62 time=2.64 ms

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

[ 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 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 all 3 scenarios:

a. ToRemote UP + ping 172.30.0.2 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 172.30.0.2 from client1 + check packets. Check from Dashboard that tunnel backup is UP

c. ToRemote UP + ToRemoteBackup UP + ping 172.30.0.2 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.