Lab 2: Firewall Policies and NAT

Sumário
Lab 2: Firewall Policies and NAT .................................................................................................................. 3
Objectives ............................................................................................................................................. 3
Exercise 1: Creating Firewall Address Objects and Firewall Policies ........................................................... 4
Create Firewall Address Objects .......................................................................................................... 4
To create a firewall address object ....................................................................................................... 4
Exercise 2: Reordering Firewall Policies and Firewall Policy Actions ............................................................ 9
Create a Firewall Policy ....................................................................................................................... 9
Exercise 3: Configuring DNAT Settings Using a VIP .................................................................................. 14
Create a VIP ..................................................................................................................................... 14
Create a Firewall Policy ..................................................................................................................... 15
Test the VIP Firewall Policy ................................................................................................................. 17
Test SNAT ......................................................................................................................................... 18
Exercise 4: Using Dynamic NAT With IP Pools ......................................................................................... 20
Create an IP Pool .............................................................................................................................. 20
Edit a Firewall Policy to Use the IP Pool ............................................................................................... 21
Test Dynamic NAT With IP Pools ......................................................................................................... 22

2
Lab 2: Firewall Policies and NAT
In this lab, you will configure firewall policies on Local-FortiGate, and then perform various tests on the Local-
Client VM to confirm that traffic is matching the appropriate firewall policies based on the configuration.

You will also examine how to configure and test a firewall policy for destination network address translation
(DNAT) using a virtual IP (VIP) address, and source network address translation (SNAT) using an IP pool. You will
configure and test SNAT using the central SNAT policy, and DNAT using the DNAT policy and VIPs. You can use
network address translation (NAT) to perform SNAT and DNAT for the traffic passing through FortiGate.

Objectives
• Configure firewall objects and firewall policies

• Configure source and destination matching in firewall policies

• Apply service objects to a firewall policy

• Configure firewall policy logging options

• Reorder firewall policies

• Read and understand logs

• Configure DNAT settings using a VIP

• Configure SNAT settings using overload IP pools

Time to Complete

Estimated: 60 minutes

LAB-2 > Firewall Policies and NAT

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

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

Generate Logs when Session <enable>

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.

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

6
 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
should use this option only when this level of detail is absolutely necessary.

7
 When you click Show Matching Logs in the firewall policy, it adds the Policy UUID filter in the forwar

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.

LAB-2 > Creating Firewall Address Objects and Firewall Policies

8
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 address. Use the preconfigured address
objects LOCAL_SUBNET 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.

9
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 Interface port3

Outgoing Interface port1

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 Violation Traffic <enable>

4. Click OK to save the changes.

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

11
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?

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

LAB-2 > Reordering Firewall Policies and Firewall Policy Actions

13
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-HOST

Interface port1

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

External IP address/range 10.200.1.200

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

Map to IPv4 address/range 10.0.1.10

14
 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 Interface port1

Outgoing Interface port3

Source all

Destination VIP-INTERNAL-HOST

Tip: This is listed under the VIRTUAL

IP/SERVER section.

Service HTTP, HTTPS

15
Field Value

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.

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

17
 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

18
 The diagnose sys session clear CLI command clears all sessions, including the SSH session you creat
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.200, 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.

LAB-2 > Configuring DNAT Settings Using a VIP

19
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 Range 10.200.1.100-10.200.1.100

4. Click OK.

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

IP Pool Configuration Use Dynamic 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:

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

22
 • 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.

LAB-2 > Using Dynamic NAT With IP Pools

23