Differences
This shows you the differences between two versions of the page.
|
sred:lab7 [2021/12/17 17:16] horia.stoenescu [Setup] |
sred:lab7 [2022/12/16 15:37] (current) horia.stoenescu Updated setup |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ======= Lab 8. Fortigate Site-to-site VPN ======= | + | ======= Lab 9. Fortigate Site-to-site VPN ======= |
| ==== Setup ==== | ==== Setup ==== | ||
| Line 7: | Line 7: | ||
| === Lab infra === | === 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). | ||
| == Local-FortiGate == | == Local-FortiGate == | ||
| - | 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: | + | 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. |
| - | - **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** | + | We will use the following interfaces: |
| - | <note> | + | |
| - | 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 [[https://ocw.cs.pub.ro/courses/sred/lab6#licensing|Licensing]], with the exception of 2 and 3 (no need to readd the license and reboot machine). | + | <note warning> |
| - | </note> | + | If VDOMs are still enabled on the first FGT, you will need the following syntax to access the interfaces config (for example): |
| + | <code> | ||
| + | FGT81 # config vdom | ||
| + | |||
| + | FGT81 (vdom) # edit root | ||
| + | current vf=root:0 | ||
| + | |||
| + | FGT81 (root) # show system interface ? | ||
| + | # see here port1 configuration | ||
| + | [...] | ||
| + | </code> | ||
| + | </note> | ||
| + | |||
| + | - **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 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** | + | - **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**. | - **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**. | ||
| Line 24: | Line 39: | ||
| </note> | </note> | ||
| - | Steps for backup connection: | + | 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 | 1. Create a new Network > Type Cloud 1 | ||
| Line 36: | Line 53: | ||
| {{:sred:sred_2020-sred_lab7_ipsec.png?700|}} | {{:sred:sred_2020-sred_lab7_ipsec.png?700|}} | ||
| + | == Remote-FortiGate == | ||
| <note important> | <note important> | ||
| - | As VDOMs are still enabled on the first FGT, you will need the following syntax to access the interfaces config (for example): | + | Do this just in case you did not solve the last lab (HA): |
| - | <code> | + | |
| - | FGT81 # config vdom | + | |
| - | FGT81 (vdom) # edit root | + | 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: |
| - | current vf=root:0 | + | |
| - | + | ||
| - | FGT81 (root) # show system interface ? | + | |
| - | # see here port1 configuration | + | |
| - | [...] | + | |
| - | </code> | + | |
| - | </note> | + | |
| - | + | ||
| - | == Remote-FortiGate == | + | |
| - | 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: | + | |
| <code> | <code> | ||
| # config sys int | # config sys int | ||
| Line 60: | Line 66: | ||
| </code> | </code> | ||
| - | Then, to repeat all steps from the latest lab regarding [[https://ocw.cs.pub.ro/courses/sred/lab6#licensing|Licensing]] and configure the following interfaces: | + | If you have a revision before adding the HA, revert to it. Else, go to cli > config system ha > unset all variables, then end. |
| - | - **port1**: , modify the mac address: | + | Then, repeat all steps from the latest lab regarding [[https://ocw.cs.pub.ro/courses/sred/lab6#licensing|Licensing]] (use for it the secondary license available on moodle) |
| + | </note> | ||
| + | Configure the following interfaces: | ||
| - | the ip is again taken via dhcp. The static routes should be the same as for FGT1. Example | + | - **port1**: the ip is again taken via dhcp. The static routes should be the same as for FGT1. Example |
| <code> | <code> | ||
| FGT81_2 # get router info routing-table details | FGT81_2 # get router info routing-table details | ||
| Line 78: | Line 86: | ||
| - **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. | - **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** | + | - **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** |
| {{:sred:sred_2020-sred_lab7_ipsec2.png?700|}} | {{:sred:sred_2020-sred_lab7_ipsec2.png?700|}} | ||
| - | After finishing the netw configuration on both machines, check the following: | + | 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): | - from eve-ng machine (root:student credentials), see the bridge configuration (pnet1 for Cloud1): | ||
| Line 132: | Line 140: | ||
| ==== Exercises ==== | ==== Exercises ==== | ||
| - | We are going again to use the [[https://curs.upb.ro/pluginfile.php/452584/mod_resource/content/1/FortiGate_Infrastructure_6.4_Lab_Guide-Online.pdf|pdf]] file with Fortinet Exercises - go to Lab 5: IPsec VPN Configuration (page 90). | + | We are going again to use the [[https://curs.upb.ro/2022/pluginfile.php/397572/mod_folder/content/0/FortiGate_Infrastructure_6.4_Lab_Guide-Online.pdf|pdf]] file with Fortinet Exercises - go to Lab 5: IPsec VPN Configuration (page 90). |
| Skip again the configuration revert from the beginning. | Skip again the configuration revert from the beginning. | ||
| - | === Exercise 1 - dialup user + custom ipsec tunnel [3p] === | + | === Exercise 1 - dialup user + custom IPsec tunnel [5p] === |
| - | - 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) | + | [ pages 90->99 ] |
| - | - 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 | + | - 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 | - 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 | + | - at the end of the exercise, check from client1 ping to 172.30.0.2 and routing table |
| <code> | <code> | ||
| - | FGT81 # config vdom | + | FGT81 # get router info routing-table details |
| - | + | ||
| - | 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 | Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP | ||
| O - OSPF, IA - OSPF inter area | O - OSPF, IA - OSPF inter area | ||
| Line 166: | Line 171: | ||
| C 172.16.0.0/24 is directly connected, port2 | C 172.16.0.0/24 is directly connected, port2 | ||
| S 172.30.0.0/24 [15/0] via 10.3.0.74, ToRemote | 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 | ||
| </code> | </code> | ||
| See that there was added a static route via ToRemote to client2's network 172.30.0.0/24. | 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] === | + | <note important> |
| + | 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. | ||
| + | </note> | ||
| - | - on local FGT, use the ip of remote one from port1 (10.3.*.*) and remote subnet 172.30.0.0/24 | + | === Exercise 2 - redundant tunnel + site-to-site vpn [5p] === |
| - | + | ||
| - | - 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): | + | |
| - | <code> | + | |
| - | 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 | + | |
| - | </code> | + | |
| - | === 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 in mirror: configure firstly the authentication mode to Main, then start doing ex. 3 from page 106 | + | - we do not have a configuration available for remote FGT, so all configs will be made on both FGTs (in mirror) |
| - | - 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 | + | - 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. |
| - | - the review from pg. 110 do on both machines (static routes, firewall policies and address group + objects) | + | - 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) |
| - | - in the end, test all 3 scenarios: | + | - do the review from pg. 110 on both machines (static routes, firewall policies and address group + objects) |
| - | 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. | + | - in the end, test these 2 scenarios: |
| - | b. ToRemote DOWN (manually) + ToRemoteBackup UP + ping 172.30.0.2 from client1 + check packets. Check from Dashboard that tunnel backup is UP | + | 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. |
| - | 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. | + | 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 |
