Lab 6. Fortigate introduction



After gaining some experience with Cisco Firepower, our company decided to test a firewall product from a different vendor: Fortinet, called FortiGate. It will be used firstly to create simple configs (like the ones did on lab3): create the qemu image path, the node on eve-ng, and deploy the machine, configure the interfaces and policy rules between interfaces.

Lab infra

The FortiOS version of our FortiGate machine (FGT) is 7.2.3 (the latest KVM release as of Nov 2022). You can find qcow2 image located in your home directory, called virtioa.qcow2 (this is based on this qemu images naming conventions).

t0. ssh to the eve-ng machine (use user root and -X flag) - for Windows use PuTTY or MobaXterm:

user: root

password: student

user@host:~# ssh -l root -X 10.3.0.A (where A is your 4th byte in the assigned IPv4 address)

t1. create the directory of the FGT image, using the format fortinet-FGT-vX-buildABCD (where X is the max version, in our case 7 and ABCD is the fortios build, in our case 1262):

root@SRED:~# cdq 
root@SRED:/opt/unetlab/addons/qemu# mkdir fortinet-FGT-v7-build1262

t2. move the qcow2 image (found in your home dir) to this path

root@SRED:~# mv virtioa.qcow2 /opt/unetlab/addons/qemu/fortinet-FGT-v7-build1262

t3. solve the permissions:

root@SRED:~# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

t4. go to eve-ng WebUI from your browser (http://10.3.0.A) and create a new lab by closing the old one (left > expand > close lab), create a new one (add new lab + add name lab5) and open it.

Create a new node for the FGT:

Right click > Add new object Node > Search for 'Fortinet FortiGate' (if you cannot find it, you need to go back to steps t1,t2, and t3) > select the required image name (it is based on the folder name):

See the configuration (based on these hardware requirements):

- ram 2 GB

- 1 vCPUs (for more than 1 vCPU, the existing license will not be accepted, so stick to only 1)

- 4 ethernet interfaces

- console vnc

Q: why do we need 4 ethernet interfaces?

On FGT machines, interfaces are named portX, where X is a digit from 1+ (in our case port1→port4):

- the first interface, called port1 (you can name it outside - see below how), is the management one and also used for Internet access (remember outside interface - G0/0 on FTD). It has by default a static route to via def gw of ESX vswitch:

FGT81 # 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* [5/0] via, port1
C is directly connected, port1

- the next interfaces are used as traffic ports. In this lab we are going to use only the first 2 for internal clients (inside1 and inside2) and the third one will be kept for the next ones (maybe for an attacker).

t5. As the traffic is forwarded to Internet via the mgmt interface (port1), we are going to need only 1 Network cloud node. Create a new network (Right click > Network) and select type Management(Cloud0). Attach a wire from this Cloud to FGT (select the first interface - port1). Using this, it will take an ip address from the ESX vswitch (via dhcp).

Regarding the license, we will use the same for all forti instances (you can find it on Moodle course page). We want to have for this lab network access, so the license will be invalidated after less than 5 minutes. Don't worry, our required features are still available and starting with the next lab, the default route will be blackholed.

t6. Save forti node and create 2 new ones for Linux devices:

- 1 node with Linux image linux-ubuntu-18.04-client1_machine (keep default config - 1 eth intf also) with name client1. Connect it to interface port2 on FGT

- 1 node with Linux image linux-ubuntu-18.04-client2_machine (keep also default config - 1 eth intf also) with name client2. Connect it to interface port3 on FGT

To create links node - node, simply hover over the node until you see the plug logo and drag it to the correspondent node/network. Create the topology as seen below:

t7. Start all nodes (go to left > expand > More Actions > Start all nodes). Access firstly the FGT machine from vnc/rdp and wait for it to boot (this will take 1,2 minutes).

t8. enter default credentials: user: admin; password: null (which means press enter)

You will need to change the default password after the first login (use password: student).

Regarding the MAC addresses: you MUST change the default one to a custom one for port1 as each machine must have an unique private ip:

Go to cli of forti:

# config sys int
# edit port1
# set macaddr <MAC address> - use here the format: 50:00:00:byte_2_eveng_ip:byte3_eveng_ip:byte4_eveng_ip
# end
# exec router restart

t9. from cli, find the interface ip address:

FGT81 # show system interface ?
# you will see here all ports configuration here, including port1, which needs to be in subnet 
# And based on different MAC addresses assigned, your ip must be unique

t10. for port1, there are by default multiple administrative services are activated (like ping, http, snmp etc.)

Access from your browser the WEBUI of FGT: http://PORT1_IP (identified at t9). It should be available instantly.

t11. Do the WebUI setup:

- download the license from Moodle and upload it. After this, the machine will restart, then check again the ip from cli (it should be the same)

Login again:

- for the hostname, you can use the following format: FGTlast_byte_eve_ng_address (for example: for ip is FGT10)

- select for dashbord Optimal (the newest dashboard available). The second option can be used by users that were used to the old version of WebUI (this can interchanged anytime from the menu).

From cli, check the network connection:

FGT81 # execute ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=116 time=29.5 ms
64 bytes from icmp_seq=1 ttl=116 time=29.3 ms

t12. Configure the rest of 2 interfaces (port2 and port3):

- for port2 use network with .1 ip for forti. Name it inside1 (alias)

- for port3 use network with .1 ip for forti. Name it inside2

For each interface, configure also DHCP servers with range .2 - .254, with default gw the same interface, DNS server the same and activate ping for admin access.

After doing any config, you are not required to deploy/commit anything. Only configure and check.

t13. Go to Linux clients via vnc/rdp, authenticate using credentials eve/eve and obtain the ip address for eth0:

user@host:~# sudo dhclient eth0

Check the ping to def gw.

t14. As expected, clients cannot access anything from Internet, due to default firewall policy: Implicit Deny (which is like 'deny any any' from ACLs). You can enable logging for this rule and try to ping from client1. You will see on log & report > forward traffic, that this will drop anything (with Deny: policy violation).

We need to create for each interface, a rule for letting any traffic outside (from Policy & Objects > Firewall Policy):

- inside1 ↔ outside (any source and any destination, any service) with action ACCEPT

- inside2 ↔ outside (any source and any destination, any service) with action ACCEPT

Try again to access from browser from each client, an Internet resource.


e1. [8p] Full setup

Go through all steps t1→ t14 from tutorial and make sure both clients have internet access.

e2. [1p] Filter ping

Filter for client1 the ping to any destination. The rest of traffic (dns, http, smtp) should not be affected.

e3. [1p] Filter web

We want for client2 to filter access to Configure a web filter object with static URL filter and create a new security rule for filtering traffic to that website.

Check other pages from facebook, like reg or login. Traffic should be blocked and a stock 'page blocked' should be served.

Case study web filtering

Discussion regarding website blocking (remember also e1 from lab5):

1. If you configure on Web Filter the URL (exact match or regex), all traffic to will be blocked, but traffic to won't as no exact match is seen.


user@host:~/# curl -I
HTTP/1.1 403 Forbidden

The client will send get req:

GET / HTTP/1.1

which will match the one configured on web filter.

Let's try now to send a req to

eve@ubuntu:~/# curl -I
HTTP/1.1 301 Moved Permanently

See that now we are receiving a 301 code with the https link (http-https redirection) - which means web filtering is no longer done.

This is the main reason why you should configure url for web filter with subdomain.subdomain.domain.tld, without www.

2. See that for http traffic we are receiving a 'Replacement Message' with a html page from the firewall.

But, when the traffic is via https explicitly sent by client, this page cannot be seen anymore:

eve@ubuntu:~/# curl -I
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 

The reason for this is that traffic is dropped on tls handshake, on Client Hello message (based on extension server_name):

See here diagram for filtering:

sred/lab5.txt · Last modified: 2022/11/18 15:15 by horia.stoenescu
CC Attribution-Share Alike 3.0 Unported Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0