This shows you the differences between two versions of the page.
sred:lab6 [2021/12/10 21:22] horia.stoenescu [Exercises] |
sred:lab6 [2022/11/25 13:43] (current) horia.stoenescu Updated lab |
||
---|---|---|---|
Line 2: | Line 2: | ||
==== Setup ==== | ==== 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> | <note important> | ||
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. | 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> | </note> | ||
- | |||
=== Licensing === | === Licensing === | ||
- | From this lab on, we will need to have a licensed VM. 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: | + | 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: |
0. 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). | 0. 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). | ||
Line 85: | Line 84: | ||
5. At last, go to webui using your browser and start the lab. | 5. 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 ==== | ==== Exercises ==== | ||
- | Find on moodle course the pdf [[https://curs.upb.ro/2021/pluginfile.php/430773/mod_resource/content/1/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. | + | 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. |
- | ** Topology setup **: | + | === Topology setup === |
- | Below you can find our topology (different a little from the one found on page 62): | + | Below you can find our topology (a little different from the one found on page 62): |
{{:sred:lab6_topology.png?800|}} | {{:sred:lab6_topology.png?800|}} | ||
- | We are going to reuse our topology 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. | + | 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. |
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). | 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). | ||
- | Next, I will give you some tips regarding the differences for configurations: | + | Next, I will give you some tips/changes regarding the differences for configurations: |
- | **Exercise 1 (pages 63-69) [5p]**: | + | === e1. [5p] New customer in town (pages 63-69) === |
- 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') | - 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> | <code> | ||
config system global | config system global | ||
Line 113: | Line 115: | ||
Then, logout, login again and check the webui (there should appear 2 default VDOMs: Global and root). | Then, logout, login again and check the webui (there should appear 2 default VDOMs: Global and root). | ||
+ | |||
+ | <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 | - create the new vdom as stated on pages 64-66 | ||
Line 138: | Line 151: | ||
- 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 | - 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 (pages 70-74) [5p]**: | + | === 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) | - the mapping are the following: port4 - vlink1 (for customer vdom) and vlink0 - port2 (for root vdom) | ||
Line 144: | Line 157: | ||
{{:sred:lab6_policies.png?800|}} | {{:sred:lab6_policies.png?800|}} | ||
- | - to test the connection from client2 to client1 (we cannot do the ones 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> | <code> | ||
eve@ubuntu:/$ cd /tmp; mkdir test_http; echo "CONFIDENTIAL" > test_http/important_data | eve@ubuntu:/$ cd /tmp; mkdir test_http; echo "CONFIDENTIAL" > test_http/important_data |