Lab 7. Fortigate Virtual Domains (VDOMs)

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.

user@host:# ssh -l root $YOUR_EVE_NG_IP
# default passwd is student
root@SRED:~# df -h | grep SRED--vg
/dev/mapper/SRED--vg-root   67G   52G   12G  83% /
# 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)

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

1. Find your internal private ip. To do this, go to cli and check the icmp packets:

FGT60 # diagnose sniffer packet port1 icmp
Using Original Sniffing Mode
interfaces=[port1]
filters=[icmp]
11.597280 10.128.0.20 -> 10.3.0.35: icmp: echo request
11.597395 10.3.0.35 -> 10.128.0.20: icmp: echo reply

# from you host, send an imcp echo-req to the specific port1 ip address

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.

2. From the browser, go to IP_FORTIGATE/ng/system/vm/license and upload the first license that is found on UPB-Learning course.

3. 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).

FGT60 # show system interface ?
# find here port1 ip

4. Remeber that this device has an implicit default route to 10.3.255.254 with AD = 5.

FGT60 # get router info routing-table details 
[...]
S*      0.0.0.0/0 [5/0] via 10.3.255.254, port1

Now, go to cli (via vnc) and create 2 new static routes:

# create a new static route with dest 10.128.0.20
FGT60 # config router static 
FGT60 (static) # edit 1
new entry '1' added
FGT60 (1) # set dst 10.128.0.20 255.255.255.255 
FGT60 (1) # set gateway 10.3.255.254
FGT60 (1) # set distance 10 
FGT60 (1) # set device port1
FGT60 (1) # end

# overwrite now the old default route from fw with AD = 1
FGT60 # config router static
FGT60 (static) # edit 2
new entry '2' added
FGT60 (2) # set dst 0.0.0.0 0.0.0.0
FGT60 (2) # set distance 1
FGT60 (2) # set blackhole enable 
FGT60 (2) # end

# from this point on, all requests to Internet are blackholed (the exception is the packets sent to client ip 10.128.0.20, which traffic originates from remote students).

5. At last, go to webui using your browser and start the lab.

Find on moodle course the pdf file for the Fortinet Exercises. As we will work with VDOMs, go directly to chapter 3 (page 62) and start the tasks.

Below you can find our topology (a little different from the one found on page 62):

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

Next, I will give you some tips/changes regarding the differences for configurations:

- 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 FGT, you need to go to cli:

config system global
    set vdom-mode multi-vdom  # this is a hidden command
end

Then, logout, login again and check the webui (there should appear 2 default VDOMs: Global and root).

FGT17 # config global 
FGT17 (global) # config sys global
FGT17 (global) # set vdom-mode no-vdom

- 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

- 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 (it should be 192.168.2.2), go to Mozilla > https://192.168.2.1 and try to login with customer's account credentials

- the mapping are the following: port4 - vlink1 (for customer vdom) and vlink0 - port2 (for root vdom)

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

eve@ubuntu:/$ cd /tmp; mkdir test_http; echo "CONFIDENTIAL" > test_http/important_data
eve@ubuntu:/$ cd test_http
eve@ubuntu:/$ python -m SimpleHTTPServer 8080

Then, go to client2 and access this resource:

eve@ubuntu:/$ curl 172.16.0.2:8080/important_data
CONFIDENTIAL

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?