Show page

Differences

This shows you the differences between two versions of the page.

--- sred:lab6 [2020/12/05 00:43]
horia.stoenescu [Setup]
+++ sred:lab6 [2022/11/25 13:43] (current)
horia.stoenescu Updated lab
@@ Line 1: / Line 1: @@
-======= Lab 6. Fortigate Virtual Domains (VDOMs) =======
+======= Lab 7. Fortigate Virtual Domains (VDOMs) =======
 ==== Setup ====
-On the last lab, remember that we used an evaluation license (used for a maximum of 1 vCPU and 2 GB RAM) available for only 15 days (see [[https://docs.fortinet.com/vm/vmware-esxi/fortigate/6.2/vmware-esxi-cookbook/6.2.0/504166/fortigate-vm-evaluation-license|here]] more).
+On the last lab, remember that we used a licensed Forti VM (used for a maximum of 1 vCPU and 2 GB RAM) with Internet access, with a lic that gets invalidated after few minutes.
 <note important>
@@ Line 12: / Line 12: @@
 root@SRED:~# df -h | grep SRED--vg
 /dev/mapper/SRED--vg-root   67G   52G   12G  83% /
-# if you have less than 60G available, delete old labs from eveng webui
+# if you have more than 60G used, delete old labs from eveng webui
 # (for each node you create, there are new qcow2 files using the based ones)
 </code>
@@ Line 18: / Line 18: @@
 As an alternative, you can delete from this path **/opt/unetlab/tmp** the files created for each node, but the first option is the recommended one.
 </note>
 === Licensing ===
-From this lab on, we will need to have a licensed VM. As we have only 1 license available, we will reuse it for all fortigate firewalls using the following steps:
+From this lab on, we will need to have a licensed VM with no access to Internet (to keep the **Valid** status). As we have only 2 licenses available in total (starting with HA lab, we are going to use 2 firewall machines), we need to reuse them for all Fortigate firewalls using the following steps:
-. We will blackhole the default route after the license is marked as VALID, then create a route only for client user ip (which will mostly be the same for all firewalls)
-. Find which private ip have the packages that are received by firewall. Go to cli and check packets:
+. We will blackhole the default route after the license is marked as VALID, then create a route only for client user ip (which will mostly be the same for all firewalls).
+. Find your internal private ip. To do this, go to cli and check the icmp packets:
 <code>
@@ Line 36: / Line 37: @@
 </code>
-See above that source ip address is the internal one **10.128.0.20**, which we will use later to fwd packets via 10.3.255.254 (def gateway).
+On the example from above see that the source ip address is the internal one: **10.128.0.20**, which will be used later to fwd packets via 10.3.255.254 (def gateway). This is just an example, you will have a different address assigned.
-. From the browser, go to **IP_FORTIGATE/ng/system/vm/license** and ask me at this point to upload the license.
+<note>
+An alternative here for taking the assigned internal ip is: go to Globalprotect UI > Settings > Connections tab > Assigned Local IP.
+</note>
+. From the browser, go to **IP_FORTIGATE/ng/system/vm/license** and upload the first license that is found on UPB-Learning course.
-. Wait for the firewall to reboot, then access the machine again via vnc to make sure the mgmt ip was not changed.
+. Wait for the firewall to reboot, then access the machine again via vnc to make sure the mgmt ip was not changed (in case it is changed, the webui interface will hang at reboot until timeout).
 <code>
 FGT60 # show system interface ?
@@ Line 46: / Line 51: @@
 </code>
-. Remeber that this device has an implicit default route to 10.3.255.254 with AD = 4.
+. Remeber that this device has an implicit default route to 10.3.255.254 with AD = 5.
 <code>
 FGT60 # get router info routing-table details
@@ Line 65: / Line 70: @@
 FGT60 (1) # end
-# overwrite now the old default route from fw
+# overwrite now the old default route from fw with AD = 1
 FGT60 # config router static
 FGT60 (static) # edit 2
@@ Line 79: / Line 84: @@
 . At last, go to webui using your browser and start the lab.
+<note tip>
+Make sure to respect this steps in order for licensing. In case your license is not seen as valid and the default route is added, remove it and wait for system log message to appear on stdout: "**registration status changed to 'VALID'**".
+</note>
 ==== Exercises ====
-Find on moodle course the pdf [[https://curs.upb.ro/pluginfile.php/452584/mod_resource/content/1/FortiGate_Infrastructure_6.4_Lab_Guide-Online.pdf|file]] for the Fortinet Exercises. As we will work with VDOMs, go to chapter 3 and start the tasks.
+Find on moodle course the pdf [[https://curs.upb.ro/2022/pluginfile.php/397572/mod_folder/content/0/FortiGate_Infrastructure_6.4_Lab_Guide-Online.pdf|file]] for the Fortinet Exercises. As we will work with VDOMs, go directly to chapter 3 (page 62) and start the tasks.
-The topology that we will use:
+=== Topology setup ===
+Below you can find our topology (a little different from the one found on page 62):
 {{:sred:lab6_topology.png?800|}}
-The difference in our case is that client2 (which needs to be linked with port4 to fw) will not access Internet (as all traffic to def route is sinkholed) and client1 instead (on which we will configure at the end an ad hoc server).
+We are going to reuse the one from the last lab, but with a small change. Shutdown the second client machine and the firewall. Then, delete the existing connection between client2 and firewall and re-attach the client to port4.
-Next, I will give you some tips or different config you need to do:
+The differences in our case are that client2 (which needs to be linked with port4 to firewall, instead of port3 as stated on pdf) will not access the Internet (as all traffic to default route is sinkholed) and client1 will have configured at the end an ad hoc server (for testing the second exercise).
-<note>
+Next, I will give you some tips/changes regarding the differences for configurations:
-In case you already have a configuration for port4, it will be automatically imported to root VDOM and you cannot modify from Network > Interface > port4 the Virtual Domain to customer.
-The solution here is to clear all references to a port (a reference = a configuration like policy rule, dhcp server, interface that is attached to that interface). Go to Global mode > System > VDOM > root > double click to number from Ref. column (number of references for that vdom), then find interface port4 > double click again to Ref. value, then select each subvalue with Ctrl and Delete all Refs.
+=== e1. [5p] New customer in town (pages 63-69) ===
-Example (for port3):
-{{:sred:clear_all_refs2.png?500}}
-Try again to change vdom for port4 to customer.
-</note>
-**Exercise 1**:
- - you can skip from page 63 the config revisions revert
+ - create a new revision as a snapshot (we do not have an already existing one as stated on page 63). Go to admin (from up right corner) > Configuration > Revisions and create a new one (you can call it 'before_vdom_enabled')
- - to enable VDOM on a FGW, you need to go to cli:
+ - to enable VDOM on a FGT, you need to go to cli:
 <code>
 config system global
@@ Line 113: / Line 114: @@
 </code>
-Then, go logout, login again and check the webui.
+Then, logout, login again and check the webui (there should appear 2 default VDOMs: Global and root).
- - instead of port3 for customer VDOM, we will use port4 (the one remained from the last lab not configured). If you already have a machine attached to port3, shutdown the firewall and reattach it to 4.
+<note tip>
+If you enabled VDOM before creating the snapshot, disable it firstly using:
+<code>
+FGT17 # config global
+FGT17 (global) # config sys global
+FGT17 (global) # set vdom-mode no-vdom
+</code>
+Also note that if there are multiple (value >= 2) VDOMs present on the device, then you will need to remove the custom ones (all except root) and after that disable VDOM feature.
+</note>
+ - create the new vdom as stated on pages 64-66
+ - instead of port3 for customer VDOM, we will use port4 (the one remained from the last lab not configured)
+ - configure port 4 using network 192.168.2.0/24 with 192.168.2.1 for gateway, dhcp server with pool 192.168.2.2-192.168.2.254, http + https (enabled for admin access), ping and attach to it the new vdom for customer
+<note>
+**Interface import issues**
+In case you already have a configuration for port4, it will be automatically imported to **root** VDOM and you cannot modify from Network > Interface > port4 the Virtual Domain to **customer**. This issue is seen when you configure firstly the interface, then activate the VDOM.
+The solution here is to clear all references to a port (a reference = a configuration like policy rule, dhcp server, interface that is attached to that interface). Go to Global mode > System > VDOM > root > double click to number from Ref. column (number of references for that vdom), then find interface port4 > double click again to Ref. value, then select each subvalue with Ctrl and Delete all Refs.
+Example (for port3):
+{{:sred:clear_all_refs2.png?500}}
+Try again to change vdom for port4 to customer.
+</note>
- - port 4 is using network 192.168.2.0/24 with 192.168.2.1 for gw (fw), dhcp server with pool 192.168.2.2-192.168.2.254 and http, https, ping enabled for admin access
+ - skip from pages 67-68 the dns configuration
- - to access the firewall using the customer credentials, we will need to access webui from client2: after client2 gets an ip from dhcp server (should be 192.168.2.2), go to Mozilla > https://192.168.2.1 and try to login with customer account
+ - to access the firewall using the customer credentials, we will need to access webui from client2: after client2 gets an ip from dhcp server (it should be 192.168.2.2), go to Mozilla > https://192.168.2.1 and try to login with customer's account credentials
-**Exercise 2**:
+=== e2. [5p] Allow traffic between clients (pages 70-74) ===
  - the mapping are the following: port4 - vlink1 (for customer vdom) and vlink0 - port2 (for root vdom)
@@ Line 127: / Line 157: @@
 {{:sred:lab6_policies.png?800|}}
- - to test the connection from client2 to client1 (we cannot do the ex from page 75), try to ping 172.16.0.2 and create a simple http server:
+ - to test the connection from client2 to client1 (we cannot do the ones from page 75), try to ping 172.16.0.2 and then create a simple http server on client1's machine:
 <code>
 eve@ubuntu:/$ cd /tmp; mkdir test_http; echo "CONFIDENTIAL" > test_http/important_data
@@ Line 139: / Line 169: @@
 CONFIDENTIAL
 </code>
+Try to ping client2's ip from client1. Does it work? Why not? If not, what do you need to add to firewall's configuration?