Lab 7. Fortigate Site-to-site VPN

Setup

Story

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

Lab infra

In the past 2 weeks, we configured a single FGT device (which will be referred from now as Local-FortiGate) 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:

- 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

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

Steps for backup connection:

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

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

For the second FGT (FGT2 or Remote-FortiGate), create a new node with 4 interfaces, 1 vCPU, 2 GB RAM, then start it. You will need firstly to change the mac address:

# config sys int
# edit <interface>
# 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, to repeat all steps from the latest lab regarding Licensing 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. 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:

Exercises

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]

- in our case, for local FGT, we have interface port1, with Local Address 172.16.0.0/24 (client1 netw). Also, for firewall policies, use port2 instead of port3, 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.

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

- 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

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

- we do not have a any configuration available for remote FGT, so all configs will be made in mirror: configure firstly the authentication mode to Main, then start doing ex. 3 from 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

- the review from pg. 110 do 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. First packet will fail due to tunnel bringup and the second tunnel will remain DOWN.

b. ToRemote DOWN (manually) + 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.

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