Exercise 1: Creating Firewall

Address Objects and Firewall

Policies
In this exercise, you will configure firewall address objects. You will also configure an IPv4
firewall policy that you will apply firewall address objects to, along with a schedule,
services, and log options. Then, you will test the firewall policy by passing traffic through it
and checking the logs for your traffic.

At its core, FortiGate is a firewall, so almost everything that it does to your traffic is related
to your firewall policies.

Create Firewall Address Objects

By default, FortiGate has many preconfigured, well-known address objects in the factory
default configuration. However, if those objects don’t meet the needs of your organization,
you can configure more.

To create a firewall address object

1. Connect to the Local-FortiGate GUI, and then log in with the username admin and
password password.

2. Click Policy & Objects > Addresses.

3. Click Create New > Address.

4. Configure the following settings:

Field Value

Name LOCAL_SUBNET

Interface any

Type Subnet

IP/Netmask 10.0.1.0/24

5. Click OK.

Create a Firewall Policy

First, you will disable the existing firewall policy. Then, you will create a more specific
firewall policy using the firewall address object that you created in the previous procedure.
You will also select specific services and configure log settings.

To disable an existing firewall policy

1. On the Local-FortiGate GUI, click Policy & Objects > Firewall Policy.

The FortiGate GUI may ask to use the new policy list layout.
Click Cancel to continue using the classic layout. The new
policy list layout is ideal to improve performance when viewing
large list of firewall policies.

2. Expand the port3 → port1 firewall policy section.

3. Right-click the Full_Access firewall policy, and then in the Set Status field,
select Disable.

To create a firewall policy

1. Continuing in the Policy & Objects > Firewall Policy section, click Create New to
add a new firewall policy.

2. Configure the following settings:

Field Value

Name Internet_Access

Incoming Interface port3

Outgoing Interface port1

Source LOCAL_SUBNET

Destination all

Schedule always

Service ALL_ICMP, HTTP, HTTPS, DNS, SSH

Tip: Type the service name in the search box to quickly

find it, and then click the service object to add it to the
policy.

Log Allowed Traffic Select All Sessions.

 Field Value

Generate Logs when <enable>

Session Starts

3. Leave all other settings at the default values, and then click OK to save the
changes.

When you create firewall policies, remember that FortiGate is a

stateful firewall. As a result, you need to create only one firewall
policy that matches the direction of the traffic that initiates the
session.

Test the Firewall Policy and View the

Generated Logs
Now that you have configured the firewall policy, you will test it by passing traffic through it
and viewing the generated logs.

To test and view logs for a firewall policy

1. On the Local-Client VM, open several browser tabs, and then connect to several
external websites, such as:

 www.google.com
 www.cnn.com
 www.bbc.com

2. Return to the browser tab with the Local-FortiGate GUI, and then click Policy &
Objects > Firewall Policy.

3. Right-click the Internet_Access policy, and then click Show matching logs.
 4. Identify the log entries for your internet browsing traffic.

With the current settings, you should have a few log messages that have Accept (Start) in
the Result column. These are the session start logs.

When sessions close, a separate log entry lists the amount of data that was sent and
received.

Enabling Generate Logs when Session Starts in the firewall

policy will generate twice the amount of log messages. You
should use this option only when this level of detail is absolutely
necessary.
 When you click Show Matching Logs in the firewall policy, it
adds the Policy UUID filter in the forward traffic logs.

5. In the Forward Traffic logs, click X to remove the Policy UUID filter.

When you remove the Policy UUID filter, the logs are displayed unfiltered. You will use the
logs in upcoming labs.

Exercise 2: Reordering Firewall

Policies and Firewall Policy Actions
In the applicable interface pair section, FortiGate looks for a matching policy, beginning at
the top. Usually, you should put more specific policies at the top—otherwise, more general
policies will match the traffic first, and more granular policies will never be applied.

In this exercise, you will create a new firewall policy with more specific settings, such as the
source, destination, and service, and you will set the action to DENY. Then, you will move
this firewall policy above the existing firewall policies and observe the behavior that
reordering the firewall policies creates.

Create a Firewall Policy

You will create a new firewall policy to match a specific source, destination, and service,
and you will set the action to DENY.

The firewall
address LINUX_ETH1
with
IP/netmask 10.200.1.
254/32 is
preconfigured for you,
and you will use this
address when you
create the firewall
policy.

Take the Expert

 Challenge!
Configure a firewall policy on
the Local-FortiGate GUI using
the following settings:

 Name the firewall

policy Block_Ping.
 Use port3 as the
incoming interface and
port1 as the outgoing
interface.
 Block all ping traffic
from
the 10.0.1.0/24 subnet
destined for
the 10.200.1.254 addre
ss. Use the
preconfigured address
objects LOCAL_SUBN
ET and LINUX_ETH1.
 Enable log violation
traffic.

If you require assistance, or to

verify your work, use the step-
by-step instructions that follow.

After you have performed these

steps, see Test the Reordering
of a Firewall Policy on page 1.

To create a firewall policy

1. Connect to the Local-FortiGate GUI, and then log in with the username admin and
password password.

2. Click Policy & Objects > Firewall Policy, and then click Create New.

3. Configure the following settings:

Field Value

Name Block_Ping

Incoming port3
Interface
 Field Value

Outgoing port1
Interface

Source LOCAL_SUBNET

Destination LINUX_ETH1

Service PING

Tip: Type the

service name in the
search box to
quickly find it, and
then click the
service object to
add it to the policy.

Action DENY

Log <enable>
Violation
Traffic

4. Click OK to save the changes.

Test the Reordering of a Firewall Policy

Now that your configuration is ready, you will test it by moving the Block_Ping firewall
policy above the Internet_Access firewall policy. The objective is to confirm that, after you
reorder the firewall policies, the following occurs:

 Traffic is matched to a more specific firewall policy.

 The policy ID remains the same.

To confirm traffic matches a more granular firewall policy after

reordering the policies
1. On the Local-Client VM, open a terminal.

2. Ping the destination address (LINUX_ETH1) that you configured in

the Block_Ping firewall policy.

ping 10.200.1.254
 Stop and think!

Why are you still able to ping

the destination address, even
though you just configured a
policy to block it?

The ping should still work

because it matches
the ACCEPT policy and not
the DENY policy that you
created. The Block_Ping policy
was never checked because
the traffic matched the policy at
the top (Internet_Access). This
demonstrates the behavior that
FortiGate looks for a matching
policy, beginning at the top.

3. Leave the terminal window open and running.

4. On the Local-FortiGate GUI, click Policy & Objects > Firewall Policy.

On the Firewall
Policy page, if
the ID column is
visible, skip to step
8.

5. Hover over the Name column.

A settings icon appears beside Name.

6. Click the settings icon, scroll down to the Select Columns section, select
the ID column, and then click Apply.
The ID column appears as the last column in the table.

7. Drag the ID column to the left of the Name column, so it becomes the first column
in the table.

Note the current ID values for both the Internet_Access and Block_Ping firewall policies.
 8. In the ID column, drag the Block_Ping firewall policy up, and place it above
the Internet_Access firewall policy.

When you move the Block_Ping policy up, the ID value remains the same.

If the changes that

you made are not
displayed, refresh
the page.
Alternatively, you
can log out of the
FortiGate GUI, and
then log back in.

9. On the Local-Client VM, review the terminal window that is running the continuous
ping.

You should see that the pings now fail.

Stop and think!

Why are the pings failing?

This demonstrates the outcome

of the policy reordering. After
moving the more granular
policy above the general
access policy, the traffic is
matched to the more granular
policy and, based on
the DENY action, the traffic
stops being processed.

10. Close the terminal window.

11. On the Local-FortiGate GUI, click Log & Report > Forward Traffic.
You should see many policy violation logs reporting the blocked ping.

Clear the log filter

that you applied in
the previous
exercise.

Exercise 3: Configuring DNAT Settings

Using a VIP
VIPs are typically used to translate external, or public, IP addresses to internal, or private,
IP addresses.

In this exercise, you will examine how to configure a VIP for the Local-Client VM. Then, you
will create an egress-to-ingress firewall policy and apply the VIP. This allows internet
connections to the Local-Client VM. You will also verify the DNAT and SNAT behavior
using CLI commands.

Create a VIP
For DNAT on FortiGate, you use a VIP as the destination address field of a firewall policy.

You will configure the VIP to map the Local-Client VM (10.0.1.10) to 10.200.1.200, which is
part of the port1 subnet. To refer to the lab diagram, see Network Topology on page 1.

To create a VIP

1. Connect to the Local-FortiGate GUI, and then log in with the username admin and
password password.

2. Click Policy & Objects > Virtual IPs, and then click Create New.

3. Configure the following settings:

Field Value

Name VIP-
INTERNAL-
Field Value

HOST

Interface port1

This port is
connected to the
internet with IP
address
10.200.1.1/24.

External IP 10.200.1.200
address/range
This IP address
is in the same
range as the
port1 subnet.

Map to IPv4 10.0.1.10

address/range

4. Click OK.
Create a Firewall Policy
You will configure a new firewall policy using the VIP that you just created as the
destination address.

To create a firewall policy

1. On the Local-FortiGate GUI, click Policy & Objects > Firewall Policy.

2. Click Create New.

3. Configure the following settings:

Field Value

Name Web-Server-Access

Incoming port1
Interface

Outgoing port3
Interface

Source all

Destinatio VIP-INTERNAL-
n HOST

Tip: This is listed

under
the VIRTUAL
IP/SERVER sectio
n.

Service HTTP, HTTPS

Tip: In the section

on the right, in the
search box, type the
service name, and
then click the
services to add.

4. In the Firewall/Network Options section, disable NAT.

5. In the Logging Options section, select All Sessions.
 6. Click OK.

Test the VIP Firewall Policy

Now that you have configured a firewall policy with the VIP as the destination, you can test
your VIP by accessing it from the Remote-Client VM, which is behind the Remote-FortiGate
internal network. A Linux machine acts as a router between the two FortiGate devices, and
routes the traffic from the Remote-FortiGate to the Local-FortiGate. For more information,
see Network Topology on page 1.

You will also test how the source address is translated by the VIP when traffic leaves the
Local-Client VM.

To test VIPs (DNAT)

1. On the Remote-Client VM, open a browser, and then browse to the following URL:

http://10.200.1.200

If the VIP operation is successful, a simple web page opens.

 2. On the Local-FortiGate CLI, log in with the username admin and
password password.

3. Enter the following command to check the destination NAT entries in the session
table:

get system session list

The following example shows a sample output:

Local-FortiGate# get system session list

PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT

tcp 3594 10.200.3.1:49478 - 10.200.1.200:80 10.0.1.10:80

You will notice that the destination address 10.200.1.200 is translated to 10.0.1.10, which
is the mapping you configured in the VIP.

The HTTP session

may have been
deleted by the time
you run the get
system session
list command.
You can repeat
steps 1–3 to
generate a new
HTTP connection
and, therefore,
another HTTP
session through
Local-FortiGate.

Test SNAT
As a result of the VIP (which is a static NAT), FortiGate uses the VIP external address as
the NAT IP address when performing SNAT for the internal-to-external direction of the
traffic, provided the matching outgoing firewall policy has NAT enabled. That is, FortiGate
doesn't use the egress interface address.

To test SNAT

1. Return to the Local-FortiGate CLI session, and then enter the following command
to clear any existing sessions:

diagnose sys session clear

The diagnose sys

session clear CLI
command clears all
sessions, including
the SSH session
you created. This
is expected
behavior.

This clears the session to the Local-FortiGate from the Local-Client VM.

2. Close the Local-FortiGate CLI window.

3. On the Local-Client VM, open a few browser tabs, and then connect to a few
websites, such as:

 www.fortinet.com
 www.yahoo.com
 www.bbc.com

4. On the Local-FortiGate CLI, log in with the username admin and

password password.

5. Enter the following command to view the session information:

get system session list

The following example shows a sample output:

 The outgoing
connections from
the Local-Client
VM are now
translated with the
VIP
address 10.200.1.2
00, instead of the
firewall egress
interface IP address
(10.200.1.1).

This is a behavior for SNAT when using a static NAT VIP. That is, when you enable NAT in
a policy, the external address of a static NAT VIP takes precedence over the destination
interface IP address, if the source address of the connections matches the VIP internal
address.

6. Close the Local-FortiGate CLI window.

7. Close all browser tabs except the Local-FortiGate GUI.

Exercise 4: Using Dynamic NAT

With IP Pools
IP pools are used to translate the source address to an address from that pool, rather than
the egress interface address.

Currently, Local-FortiGate translates the source IP address of all traffic generated from the
Local-Client VM to 10.200.1.200 because the internal address of the VIP matches the
address of Local-Client, and the VIP is a static NAT VIP.

In this exercise, you will examine how to create an IP pool, apply it to the ingress-to-egress
firewall policy, and verify the SNAT address using CLI commands.

Create an IP Pool
You will create an IP pool from the range of public IP addresses available on the egress
port (port1).

To create an IP pool
1. Connect to the Local-FortiGate GUI, and then log in with the username admin and
password password.

2. Click Policy & Objects > IP Pools.

3. Click Create New, and then configure the following settings:

 Field Value

Name INTERNAL-HOST-
EXT-IP

External IP 10.200.1.100-
Range 10.200.1.100

4. Click OK.

Edit a Firewall Policy to Use the IP Pool

You will apply the IP pool to change the behavior from static NAT to dynamic NAT on the
ingress-to-egress firewall policy.

To edit the firewall policy

1. On the Local-FortiGate GUI, click Policy & Objects > Firewall Policy.

2. Right-click the Full_Access firewall policy.

3. Click Set Status > Enable.

4. Right-click the firewall policy again, and then click Edit.

5. In the Firewall/Network Options section, configure the following settings:

Field Value

NAT <enable>
 Field Value

IP Pool Use Dynamic

Configuration IP Pool

6. Click the + sign that appeared when you clicked Use Dynamic IP Pool, and then in
the section on the right, click INTERNAL-HOST-EXT-IP.

Your configuration will look similar to the following example:

7. Click OK.

Test Dynamic NAT With IP Pools

Now that your configuration is ready, you can test dynamic NAT with IP pools by browsing
to a few external sites on the internet. If successful, you will see that the Local-Client VM IP
address (10.0.1.10) is translated to the IP pool address of 10.200.1.100.

To test dynamic NAT with IP pools

 1. On the Local-FortiGate CLI, log in with the username admin and
password password.

2. Enter the following commands to clear sessions sourced from 10.0.1.10:

diagnose sys session filter clear

diagnose sys session filter src 10.0.1.10

diagnose sys session clear

You built the filter to

match sessions
sourced
from 10.0.1.10.
This way, when you
run the diagnose
sys session
clear CLI
command, it clears
only the sessions
sourced
from 10.0.1.10. As
a result, your SSH
session is not
disconnected. This
is why it is
important to build
the session filter
before using
the session
clear command.

3. On the Local-Client VM, open a few browser tabs, and then connect to a few
websites, such as:

 www.fortinet.com
 www.yahoo.com
 www.bbc.com

4. On the Local-FortiGate CLI, enter the following command to verify the SNAT
address that the sessions are using:

get system session list

The following image shows a sample output:

Notice that the SNAT address is now 10.200.1.100, as configured in the IP pool, and the
IP pool has overridden the static NAT VIP.

5. Close the Local-FortiGate CLI window.

6. Close all browser tabs except the Local-FortiGate GUI.