Category Archives: FortiOS 6.2

Traffic shaping

Traffic shaping

Interface bandwidth limit

You can limit interface bandwidth for arriving and departing traffic. In some cases, the traffic received on an interfaces could exceed the maximum bandwidth limit defined in the security policy. Rather than waste processing power on packets that will get dropped later in the process, you can configure FortiGate to preemptively drop excess packets when they’re received at the source interface. A similar command is available to the outgoing interface.

The following diagram shows how excess packets going from LAN to WAN1 can be intercepted and dropped at the source interface.

To configure an interface bandwidth limit on the FortiOS GUI:

Go to Interface.
Click interface port1, and click Edit on top menu bar.
Go to the Traffic Shaping section, and set the following options:
1. Enable Inbound Bandwidth and type 200. The default bandwidth unit is kbps.
2. Enable Outbound Bandwidth and type 400.

The default bandwidth unit is kbps.

Click OK.

To configure an interface bandwidth limit on the FortiOS CLI:

On the FortiGate, configure the interface bandwidth limit:

config system interface edit “port1” …..

set inbandwidth 200 set outbandwidth 400 ….. next

end

ToS-based traffic prioritization

This traffic prioritization method puts packets into the following queues based on its Type of Service (ToS) value: l High l Medium l Low

ToS-based traffic prioritization cannot be used to apply bandwidth limits and guarantees, but it can be used to prioritize traffic at per-packet levels.

You can use the following command to configure the default system-wide level of priority:

config system global set traffic-priority-level {high | low | medium}

end

You can also prioritize packets according to the ToS bit value in the packet’s IP header by using the following command: config system tos-based-priority edit <id_int> set tos [0-15]

set priority {high | low | medium}

end

Example

The following configuration shows that packets with ToS bit values of 10 are prioritized as medium and packets with ToS bit values of 20 are prioritized as high. All the other traffic is prioritized as low.

config system global set traffic-priority-level low end

config system tos-based-priority edit 1 set tos 10 set priority medium

next edit 2 set tos 20 set priority high

end

Shared traffic shaper

Shared traffic shaper is used in a firewall shaping policy to indicate the priority and guaranteed and maximum bandwidth for a specified type of traffic use.

The maximum bandwidth indicates the largest amount of traffic allowed when using the policy. You can set the maximum bandwidth to a value between 1 and 16776000 Kbps. The GUI displays an error if any value outside this range is used. If you want to allow unlimited bandwidth, use the CLI to enter a value of 0.

The guaranteed bandwidth ensures that there is a consistent reserved bandwidth available. When setting the guaranteed bandwidth, ensure that the value is significantly less than the interface’s bandwidth capacity. Otherwise, the interface will allow very little or no other traffic to pass through, potentially causing unwanted latency.

In a shared traffic shaper, the administrator can prioritize certain traffic as high, medium, or low. FortiOS provides bandwidth to low priority connections only when high priority connections do not need the bandwidth. For example, you should assign a high traffic priority to a policy for connecting a secure web server that needs to support e-commerce traffic. You should assign less important services a low priority.

When you configure a shared traffic shaper, you can apply bandwidth shaping per policy or for all policies. By default, a shared traffic shaper applies traffic shaping evenly to all policies that use the shared traffic shaper.

When configuring a per-policy traffic shaper, FortiOS applies the traffic shaping rules defined for each security policy individually. For example, if a per-policy traffic shaper is configured with a maximum bandwidth of 1000 Kbps, any security policies that have that traffic shaper enabled get 1000 Kbps of bandwidth each.

If a traffic shaper for all policies is configured with a maximum bandwidth of 1000 Kbps, all policies share the 1000 Kbps on a first-come, first-served basis.

The configuration is as follows:

config firewall shaper traffic-shaper edit “traffic_shaper_name” set per-policy enable

end

The shared traffic shaper selected in the traffic shaping policy affects traffic in the direction defined in the policy. For example, if the source port is LAN and the destination is WAN1, the traffic shaping affects the flow in this direction only, affecting the outbound traffic’s upload speed. You can define the traffic shaper for the policy in the opposite direction (reverse shaper) to affect the inbound traffic’s download speed. In this example, that would be from WAN1 to LAN.

The following example shows how to apply different speeds to different types of service. The example configures two shared traffic shapers to use in two firewall shaping policies. One policy guarantees a speed of 10 Mbps for VoIP traffic.

The other policy guarantees a speed of 1 Mbps for other traffic. In the example, FortiOS communicates with a PC using port10 and the Internet using port9.

To configure shared traffic shapers in the FortiOS GUI:

Create a firewall policy:
1. Go to Policy & Objects > IPv4 Policy. Click Create New.
2. In the Name field, enter Internet Access.
3. From the Incoming Interface dropdown list, select port10.
4. From the Outgoing Interface dropdown list, select port9.
5. For the Source and Destination fields, select all.
6. From the Schedule dropdown list, select always.
7. For the Service field, select ALL.
8. Click OK.
Create the shared traffic shapers:
1. Go to Policy & Objects > Traffic Shapers. Click Create New.
2. In the Name field, enter 10Mbps. This shaper is for VoIP traffic.
3. From the Traffic Priority dropdown list, select High.
4. Enable Max Bandwidth and enter 20000. This equates to 20 Mbps.
5. Enable Guaranteed Bandwidth and enter 10000. This equates to 10 Mbps.
6. Click OK.
7. Repeat the process above to create another traffic shaper named 1Mbps. Set the Traffic Priority to Low, the Max Bandwidth and Guaranteed Bandwidth to 10000.
Create a firewall shaping policy:
1. Go to Policy & Objects > Traffic Shaping Policy. Click Create New.
2. In the Name field, enter VoIP_10Mbps_High. This policy is for VoIP traffic.
3. For the Source and Destination fields, select all.
4. For the Service field, select all VoIP services.
5. For the Outgoing Interface field, select port9.
6. Enable Shared shaper. Select 10Mbps from the dropdown list.
7. Enable Reverse shaper. Select 10Mbps from the dropdown list.
8. Click OK.
9. Repeat the process above to create a firewall shaping policy named Other_1Mbps_Low for other traffic. Set the Source and Destination to all, Service to ALL, Outgoing Interface to port9, and Shared shaper and Reverse shaper to 1Mbps.

To configure shared traffic shapers using the FortiOS CLI:

Create a firewall policy:

config firewall policy edit 1 set name “Internet Access” set srcintf “port10” set dstintf “port9” set srcaddr “all” set dstaddr “all” set action accept

set schedule “always” set service “ALL” set fsso disable set nat enable

end

Create the shared traffic shapers:

config firewall shaper traffic-shaper edit “10Mbps” set guaranteed-bandwidth 10000 set maximum-bandwidth 20000

next edit “1Mbps” set guaranteed-bandwidth 1000 set maximum-bandwidth 10000 set priority low

end

Create a firewall shaping policy:

config firewall shaping-policy edit 1 set name “VOIP_10Mbps_High”

set service “H323” “IRC” “MS-SQL” “MYSQL” “RTSP” “SCCP” “SIP” “SIP-MSNmessenger” set dstintf “port9” set traffic-shaper “10Mbps” set traffic-shaper-reverse “10Mbps”

set srcaddr “all” set dstaddr “all”

next edit 2 set name “Other_1Mbps_Low” set service “ALL” set dstintf “port9” set traffic-shaper “1Mbps” set traffic-shaper-reverse “1Mbps”

set srcaddr “all” set dstaddr “all”

end

To troubleshoot shared traffic shapers:

To check if specific traffic is attached to the correct traffic shaper, run the diagnose firewall iprope list 100015 command. The example output shows the traffic attached to the 10Mbps and 1Mbps shapers:

# diagnose firewall iprope list 100015

policy index=1 uuid_idx=0 action=accept flag (0):

shapers: orig=10Mbps(2/1280000/2560000) cos_fwd=0 cos_rev=0 group=00100015 av=00000000 au=00000000 split=00000000 host=4 chk_client_info=0x0 app_list=0 ips_view=0 misc=0 dd_type=0 dd_mode=0 zone(1): 0 -> zone(1): 38

source(1): 0.0.0.0-255.255.255.255, uuid_idx=0, dest(1): 0.0.0.0-255.255.255.255, uuid_idx=0, service(15):

[6:0x0:0/(1,65535)->(1720,1720)] helper:auto

[6:0x0:0/(1,65535)->(1503,1503)] helper:auto

[17:0x0:0/(1,65535)->(1719,1719)] helper:auto

[6:0x0:0/(1,65535)->(6660,6669)] helper:auto

[6:0x0:0/(1,65535)->(1433,1433)] helper:auto

[6:0x0:0/(1,65535)->(1434,1434)] helper:auto

[6:0x0:0/(1,65535)->(3306,3306)] helper:auto

[6:0x0:0/(1,65535)->(554,554)] helper:auto

[6:0x0:0/(1,65535)->(7070,7070)] helper:auto

[6:0x0:0/(1,65535)->(8554,8554)] helper:auto

[17:0x0:0/(1,65535)->(554,554)] helper:auto

[6:0x0:0/(1,65535)->(2000,2000)] helper:auto

[6:0x0:0/(1,65535)->(5060,5060)] helper:auto

[17:0x0:0/(1,65535)->(5060,5060)] helper:auto [6:0x0:0/(1,65535)->(1863,1863)] helper:auto

policy index=2 uuid_idx=0 action=accept flag (0):

shapers: orig=1Mbps(4/128000/1280000) cos_fwd=0 cos_rev=0 group=00100015 av=00000000 au=00000000 split=00000000 host=4 chk_client_info=0x0 app_list=0 ips_view=0 misc=0 dd_type=0 dd_mode=0 zone(1): 0 -> zone(1): 38

source(1): 0.0.0.0-255.255.255.255, uuid_idx=0, dest(1): 0.0.0.0-255.255.255.255, uuid_idx=0, service(1):

[0:0x0:0/(0,0)->(0,0)] helper:auto

To check if the correct traffic shaper is applied to the session, run the diagnose sys session list command. The example output shows that the 1Mbps shaper is applied to the session:

# dia sys session list

session info: proto=6 proto_state=01 duration=11 expire=3599 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=5

origin-shaper=1Mbps prio=4 guarantee 128000Bps max 1280000Bps traffic 1050Bps drops 0B reply-shaper= per_ip_shaper=

class_id=0 shaping_policy_id=2 ha_id=0 policy_dir=0 tunnel=/ helper=ftp vlan_cos=0/255 state=may_dirty npu npd os mif route_preserve

statistic(bytes/packets/allow_err): org=868/15/1 reply=752/10/1 tuples=2

tx speed(Bps/kbps): 76/0 rx speed(Bps/kbps): 66/0 orgin->sink: org pre->post, reply pre->post dev=39->38/38->39 gwy=172.16.200.55/0.0.0.0 hook=post dir=org act=snat 10.1.100.11:58241->172.16.200.55:21(172.16.200.1:58241) hook=pre dir=reply act=dnat 172.16.200.55:21->172.16.200.1:58241(10.1.100.11:58241) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=4 serial=0003255f tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id = 00000000 dd_type=0 dd_mode=0 npu_state=0x100000

npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000

vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0 no_ofld_reason: offload-denied helper total session 1

To check statuses of shared traffic shapers, run the diagnose firewall shaper traffic-shaper list command. The output should resemble the following: # dia firewall shaper traffic-shaper list

name 10Mbps maximum-bandwidth 2500 KB/sec guaranteed-bandwidth 1250 KB/sec current-bandwidth 0 B/sec priority 2 tos ff packets dropped 0 bytes dropped 0

name 1Mbps maximum-bandwidth 1250 KB/sec guaranteed-bandwidth 125 KB/sec current-bandwidth 0 B/sec priority 4 tos ff packets dropped 0 bytes dropped 0

Per-IP traffic shaper

With per-IP traffic shaping, you can limit each IP address’s behavior to avoid a situation where one user uses all of the available bandwidth. In addition to controlling the maximum bandwidth used per IP address, you can also define the maximum number of concurrent sessions for an IP address. For example, if you apply a per-IP shaper of 1 Mbps to your entire network, FortiOS allocates each user/IP address 1 Mbps of bandwidth. Even if the network consists of a single user, FortiOS allocates them 1 Mbps. If there are ten users, each user gets 1 Mbps of bandwidth, totaling 10 Mbps of outgoing traffic.

For shared shapers, all users share the set guaranteed and maximum bandwidths. For example, if you set a shared shaper for all PCs using an FTP service to 10 Mbps, all users uploading to the FTP server share the 10 Mbps.

Shared shapers affect upload speed. If you want to limit the download speed from the FTP server in the example, you must configure the shared shaper as a reverse shaper. Per-IP shapers apply the speed limit on both upload and download operations.

The following example shows how to apply a per-IP shaper to a traffic shaping policy. This shaper assigns each user a maximum bandwidth of 1 Mbps and allows each user to have a maximum of ten concurrent connections to the FTP server. In the example, FortiOS communicates with users using port10 and the FTP server using port9.

To configure a per-IP shaper in the FortiOS GUI:

Create a firewall policy:
1. Go to Policy & Objects > IPv4 Policy. Click Create New.
2. In the Name field, enter FTP Access.
3. From the Incoming Interface dropdown list, select port10.
4. From the Outgoing Interface dropdown list, select port9.
5. For the Source and Destination fields, select all and FTP_Server, respectively.
6. From the Schedule dropdown list, select always.
7. For the Service field, select ALL.
8. Click OK.
Create the per-IP traffic shaper:
Go to Policy & Objects > Traffic Shapers. Click Create New.
For Type, select Per-IP.
In the Name field, enter FTP_Max_1M. This shaper is for VoIP traffic.
Enable Max Bandwidth and enter 1000. This equates to 1 Mbps.
Enable Max Concurrent Connections and enter 10. This means that each user can have up to ten concurrent connections to the FTP server.
Click OK.
Create a firewall shaping policy:
Go to Policy & Objects > Traffic Shaping Policy. Click Create New.
In the Name field, enter FTP speed 1M.
For the Source fields, select the users that need to access the FTP server.
For the Destination field, select FTP_Server.
For the Service field, select ALL.
For the Outgoing Interface field, select port9.
Enable Per-IP shaper. Select FTP_Max_1M from the dropdown list.
Click OK.

To configure a per-IP traffic shaper using the FortiOS CLI:

Create a firewall policy:

config firewall policy edit 1 set name “FTP Access” set srcintf “port10” set dstintf “port9” set srcaddr “all” set dstaddr “FTP_Server” set action accept set schedule “always” set service “ALL” set fsso disable set nat enable

end

Create the per-IP traffic shaper:

config firewall shaper per-ip-shaper edit “FTP_Max_1M” set max-bandwidth 1000 set max-concurrent-session 10

end

Create a firewall shaping policy:

config firewall shaping-policy edit 1 set name “FTP speed 1M” set service “ALL” set dstintf “port9”

set per-ip-shaper “FTP_Max_1M” set srcaddr “PC1” “WinPC” “PC2” set dstaddr “FTP_Server”

end

To troubleshoot per-IP traffic shapers:

To check if specific traffic is attached to the correct traffic shaper, run the diagnose firewall iprope list 100015 command. The example output shows the traffic attached to the FTP_Max_1M shaper:

# diagnose firewall iprope list 100015

policy index=3 uuid_idx=0 action=accept flag (0): shapers: per-ip=FTP_Max_1M cos_fwd=0 cos_rev=0 group=00100015 av=00000000 au=00000000 split=00000000 host=2 chk_client_info=0x0 app_list=0 ips_view=0 misc=0 dd_type=0 dd_mode=0 zone(1): 0 -> zone(1): 38

source(3): 10.1.100.11-10.1.100.11, uuid_idx=30, 10.1.100.143-10.1.100.143, uuid_idx=32,

10.1.100.22-10.1.100.22, uuid_idx=31, dest(1): 172.16.200.55-172.16.200.55, uuid_idx=89, service(1):

[0:0x0:0/(0,65535)->(0,65535)] helper:auto

To check if the correct traffic shaper is applied to the session, run the diagnose sys session list command. The example output shows that the FTP_Max_1M shaper is applied to the session:

# dia sys session list

session info: proto=6 proto_state=01 duration=36 expire=3567 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4

origin-shaper= reply-shaper= per_ip_shaper=FTP_Max_1M

class_id=0 shaping_policy_id=3 ha_id=0 policy_dir=0 tunnel=/ helper=ftp vlan_cos=0/255 state=may_dirty per_ip npu npd mif route_preserve

statistic(bytes/packets/allow_err): org=506/9/1 reply=416/6/1 tuples=2

tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=39->38/38->39 gwy=172.16.200.55/0.0.0.0 hook=post dir=org act=snat 10.1.100.11:58275->172.16.200.55:21(172.16.200.1:58275) hook=pre dir=reply act=dnat 172.16.200.55:21->172.16.200.1:58275(10.1.100.11:58275) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=2 serial=0000211a tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id = 00000000 dd_type=0 dd_mode=0 npu_state=0x100000

npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000

vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0 no_ofld_reason: offload-denied helper

To check statuses of per-IP traffic shapers, run the diagnose firewall shaper per-ip-shaper list command. The output should resemble the following: # diagnose firewall shaper per-ip-shaper list

name FTP_Max_1M maximum-bandwidth 125 KB/sec maximum-concurrent-session 10

tos ff/ff packets dropped 0 bytes dropped 0 addr=10.1.100.11 status: bps=0 ses=3

Type of Service-based prioritization and policy-based traffic shaping

Priority queues

After packet acceptance, FortiOS classifies traffic and may apply Quality of Service techniques such as prioritization and traffic shaping. Traffic shaping consists of a mixture of traffic policing to enforce bandwidth limits and priority queue adjustment to assist packets in achieving the guaranteed rate.

If you have configured prioritization, FortiOS prioritizes egressing packets by distributing them among first in first out queues associated with each possible priority number. Each physical interface has six priority queues. Virtual interfaces use the priority queues of the physical interface to which they are bound.

Each physical interface’s six queues are queue 0 to queue 5, where queue 0 is the highest priority queue. However, you may observe that your traffic uses only a subset of those six queues. For example, some traffic may always use a certain queue number. Queuing may also vary by the packet rate or mixture of services. Some queue numbers may only be used by through traffic for which you have configured traffic shaping in the security policy that applies to that traffic session.

Administrative access traffic always uses queue 0.

Traffic matching firewall policies without traffic shaping may use queue 0, queue 1, or queue 2. The queue is selected based on the priority value you have configured for packets with that Type of Service (ToS) bit value, if you have configured ToS-based priorities.

Traffic matching firewall shaping policies with traffic shaper enabled may use any queue. The queue is selected based on whether the packet rate is currently below the guaranteed bandwidth (queue 0), or above the guaranteed bandwidth. Packets at rates greater than the maximum bandwidth limit are dropped.

Priority types

Packets can be assigned a priority in one of three types:

On entering ingress – for packets flowing through the firewall. l Upon generation – for packets generated by the firewall (including packets generated due to AV proxying).
On passing through a firewall policy – for packets passing through a firewall policy (firewall shaping policy) that has a traffic shaper defined.

ToS priority

The first and second types, ingress priority and priority for generated packets, are controlled via two different CLI settings, as shown below:

config system global set traffic-priority-level {high|medium|low}

end

config system tos-based-priority edit 1 set tos [0-15] -> type of service bit in the IP datagram header with a value between 0 and 15

set priority (high|medium|low)-> priority of this type of service

end

Each priority level is mapped to a value as follows:

ToS priority	Value
High	0
Medium	1
Low	2

Firewall shaping policy priority

In a firewall shaping policy, you can enable traffic shaping. In the shared traffic shaper, you can set the firewall priority to high, medium, or low, as shown below:

config firewall shaper traffic-shaper edit “1” set priority (high|medium|low)

end

Since the priority in a traffic shaper is set to high by default, you must set some traffic at a lower priority to see results. Each priority level is mapped to a value as follows:

Firewall policy priority	Value
High (default)	1
Medium	2
Low	3

Combination of two priority types

To combine the two priority types, the global or ingress ToS-based priority value is combined with the firewall policy priority value:

ToS priority (0, 1, 2) + policy priority (1, 2, 3) = total priority (queue number)

Consider the following scenarios:

If the current packet rate is less than the guaranteed bandwidth, packets use priority queue 0. Packet priority is 0. l If the current packet rate exceeds the maximum bandwidth, excess packets are dropped.
If the current packet rate is greater than the guaranteed bandwidth but less than the maximum bandwidth, FortiOS assigns a priority queue by adding the ToS-based priority and the firewall priority. For example, if you have enabled traffic shaping in the security policy and the security policy’s traffic priority is low (value 3), and the priority normally applied to packets with that ToS bit is medium (value 1), the packets have a total packet priority of 4, and use priority queue 4.

Interface-based traffic shaping profile

Priority Queues

After packet acceptance, FortiGate classifies traffic and might apply Quality of Service (QoS) techniques, such as prioritization and traffic shaping. Traffic shaping consists of a mixture of traffic policing to enforce bandwidth limits and priority queue adjustment to assist packets in achieving the guaranteed rate.

If you have configured prioritization, the FortiGate unit prioritizes egressing packets by distributing them among FIFO (first in, first out) queues associated with each possible priority number. Each physical interface has six priority queues. Virtual interfaces use the priority queues of the physical interface to which they are bound.

Each physical interface’s six queues are queue 0 to queue 5, where queue 0 is the highest priority queue. However, you might observe that your traffic uses only a subset of those six queues. For example, some traffic might always use a certain queue number. Queuing may also vary by the packet rate or mixture of services. Some queue numbers might only be used by through traffic for which you have configured traffic shaping in the security policy that applies to that traffic session.

Administrative access traffic will always use queue 0.
Traffic matching firewall policies without traffic shaping may use queue 0, queue 1, or queue 2. The queue is selected based on the priority value you have configured for packets with that ToS (Type of Service) bit value, if you have configured ToS-based priorities.
Traffic matching firewall shaping policy with traffic shaper enabled may use any queue. The queue is selected based on whether the packet rate is currently below the guaranteed bandwidth (queue 0), or above the guaranteed bandwidth. Packets at rates greater than the maximum bandwidth limit are dropped.
For Example, if the global ToS-based-priority is low (3) and the priority in a traffic-shaper is medium (2), when a packet flows through a policy that refers to the shaper, the packet will be assigned the priority defined by the shaper. In this case, medium (2).

Types of priority

Packets can be assigned a priority in one of three types:

On entering ingress – for packets flowing through the firewall.
Upon generation – for packets generated by the firewall (including packets generated due to AV proxying).
On passing through a firewall policy – for packets passing through a firewall policy(firewall shaping policy) that has a traffic shaper defined.

Type of Service (ToS) priority

The first and second types (ingress priority and priority for generated packets) are controlled via two different CLI settings:

config system global set traffic-priority-level {high|medium|low}

end And

config system tos-based-priority edit 1 set tos [0-15] -> type of service bit in the IP datagram header with a value between 0 and 15

set priority (high|medium|low)-> priority of this type of service

end

Each priority level is mapped to a value like following:

ToS Priority	Value
High	0
Medium	1
Low	2

Firewall shaping policy priority

In a firewall shaping policy, you can enable traffic shaping. In the shared traffic shaper, you can set the firewall priority to high, medium, or low:

config firewall shaper traffic-shaper edit “1” set priority (high|medium|low)

end

Since priority in traffic shaper are set to “high” priority by default, it is necessary to set some traffic at a lower priority to get results. Each priority level is mapped to a value like following:

Firewall Policy Priority	Value
High (default)	1
Medium	2
Low	3

Combination priority

The global or ingress ToS-based priority value is combined with the firewall policy priority value:

Tos priority (0, 1, 2) + policy priority (1, 2, 3) = total priority (queue number) Let’s take a look at some scenarios:

Case 1: If the current packet rate is less than the guaranteed bandwidth, packets use priority queue 0. In other words, packet priority = 0.

Case 2:If the current packet rate exceeds the maximum bandwidth, excess packets are dropped.

Case 3:If the current packet rate is greater than the guaranteed bandwidth, but less than maximum bandwidth, the FortiGate unit assigns a priority queue by adding the ToS-based priority and the firewall priority.

For example, if you have enabled Traffic Shaping in the security policy, and the security policy’s Traffic Priority is Low (value 3), and the priority normally applied to packets with that ToS bit is medium (value 1), then packets have a total packet priority of 4, and use priority queue 4.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Multicast processing and basic Multicast policy

Leave a reply

Multicast processing and basic Multicast policy

You need to add firewall policies to allow packets to pass from one interface to another. Multicast packets require multicast security policies. Similar to firewall policies, in a multicast policy, the administrator specifies the source interface, destination interfaces, the allowed source address ranges, and destination addresses of the multicast traffic. You can also use multicast policies to configure source NAT and destination NAT for multicast packets.

Multicast forwarding in NAT mode

When multicast-forward is enabled, the FortiGate forwards any multicast IP packets in which the TTL is 2 or higher to all interfaces and VLAN interfaces except the receiving interface. The TTL in the IP header is reduced by 1. Even though the multicast packets are forwarded to all interfaces, you must add multicast policies to allow multicast packets through the FortiGate.

If multicast-forward is disabled, then FortiGate unit drops packets that have multicast source or destination addresses.

In NAT mode, there is a per-VDOM configuration to disable forwarding any multicast traffic. This command is only available in NAT mode.

config system settings set multicast-forward <disable|enable(default)>

end

You can also use the multicast-ttl-notchange option so that FortiGate doesn’t increase the TTL value for forwarded multicast packets. Use this option only if packets are expiring before reaching the multicast router.

config system settings

set multicast-ttl-notchange enable end

Multicast processing in TP mode

When multicast-skip-policy is enabled, no check is performed based on multicast policy. A multicast packet received on an interface is flooded unconditionally to all interfaces (except the incoming interface) belonging to the same forwarding domain. Multicast packets are forwarded even when there is no multicast policy or the multicast policy is set to deny. To forward multicast traffic based on multicast policy, multicast-skip-policy must be disabled.

In transparent mode, there is a per-VDOM configuration to skip policy check and forward all multicast traffics. This command is only available in transparent mode.

config system settings set multicast-skip-policy <disable(default)|enable>

end

Sample configuration

To allow RIP2 packets from port1 to port2 using the GUI:

Go to Policy & Object > Multicast Policy.
Click Create New.
For Incoming Interface, select port1.
For Outgoing Interface, select port2.
For Source Address, select 10.0.10/32.
For Destination Address, select RIPv2.
Click OK.

To allow RIP2 packets from port1 to port2 using the CLI:

config firewall address edit “10.10.0.10/32” set subnet 10.10.0.10 255.255.255.255

end

config firewall multicast-address edit “RIPv2” set start-ip 224.0.0.9 set end-ip 224.0.0.9

end

config firewall multicast-policy edit 2 set srcintf “port1” set dstintf “port2” set srcaddr “10.10.0.10/32” set dstaddr “RIPv2”

next end

IPv4/IPv6 access control lists

Access control lists (ACL) in the FortiOS firmware is a granular or more specifically targeted blacklist. ACL drop IPv4 and IPv6 packets at the physical network interface before the packets are analyzed by the CPU. On a busy appliance, this can really improve performance.

ACL is available on FortiGates with NP6-accelerated interfaces. ACL checking is one of the first things that happens to the packet and checking is done by the NP6 processor. The result is very efficient protection that does not use CPU or memory resources.

The following platforms support ACL:

FGT_100D, FGT_100E, FGT_100EF, FGT_101E. l FGT_140D, FGT_140D_POE, FGT_140E, FGT_140E_POE. l FGT_301E, FGT_500E, FGT_501E. l FGT_1200D, FGT_1500D, FGT_1500DT.
FGT_2000E, FGT_2500E. l FGT_3000D, FGT_3100D, FGT_3200D, FGT_3700D. l FGT_3800D, FGT_3810D, FGT_3815D. l FGT_3960E, FGT_3980E.

Limitation

The configuration of ACL allows you to specify which interface the ACL is applied to. You should be aware of a hardware limitation. The ACL is a Layer 2 function and is offloaded to the ISF hardware. Therefore no CPU resources are used in the processing of the ACL. It is handled by the inside switch chip which can do hardware acceleration, which increases the performance of the FortiGate. The drawback is that the ACL function is only supported on switch fabric driven interfaces. It also cannot be applied to hardware switch interfaces or their members. Ports such as WAN1 or WAN2 on some models that use network cards that connect to the CPU through a PCIe bus do support ACL.

Sample configuration

To block all IPv4 and IPv6 Telnet traffic from port2 to Company_Servers using the CLI:

config firewall acl edit 1 set interface “port2” set srcaddr “all” set dstaddr “Company_Servers” set service “TELNET”

end

config firewall acl6 edit 1 set interface “port2” set srcaddr “all”

set dstaddr “Company_Servers_v6” set service “TELNET”

next end

Sample troubleshooting

To check the number of packets drop by an ACL:

# diag firewall acl counter ACL id 1 dropped 0 packets

To clear the packet drop counter:

# diag firewall acl clearcounter Use the same commands for IPv6 ACL.

# dia firewall acl

counter	Show number of packets dropped by ACL.
counter6	Show number of packets dropped by ACL6.
clearcounter	Clear ACL packet counter.
clearcounter6	Clear ACL6 packet counter.

NAT46 policy

Leave a reply

NAT46 policy

NAT46 refers to the mechanism that allows IPv4 addressed hosts to communicate with IPv6 hosts. Without such a mechanism, IPv4 environments cannot connect to IPv6 networks.

Sample topology

In this example, an IPv4 client tries to connect to an IPv6 server. A VIP is configured on FortiGate to map the server IPv6 IP address 2000:172:16:200:55 to an IPv4 address 10.1.100.55. On the other side, an IPv6 IP pool is configured and the source address of packets from client are changed to the defined IPv6 address. In this setup, the client PC can access the server by using IP address 10.1.100.55.

Sample configuration

To enable display for IPv6 and NAT46/NAT64 using the GUI:

Go to System > Feature Visibility.
In the Basic Features section, enable IPv6.
In the Additional Features section, enable NAT46 & NAT64.
Click Apply.

To enable display for IPv6 and NAT46/NAT64 using the CLI:

config system global set gui-ipv6 enable

end config system settings set gui-nat46-64 enable

end

To configure VIP46 using the GUI:

Go to Policy & Object > Virtual IPs.
Click Create New.
For Name, enter vip46_server.
For External IP Address/Range, enter 1.100.55-10.1.100.55.
For Mapped IP Address/Range, enter 2000:172:16:200::55.
Click OK.

To configure VIP46 using the CLI:

config firewall vip46 edit “vip46_server” set extip 10.1.100.55 set mappedip 2000:172:16:200::55

end

To configure IPv6 IP pool using the GUI:

Go to Policy & Object > IP Pools.
Click Create New.
For Name, enter client_expternal.
For External IP Range, enter 2000:172:16:201::11- 2000:172:16:201::20.
Click OK.

To configure IPv6 IP pool using the CLI:

config firewall ippool6 edit “client_external” set startip 2000:172:16:201::11 set endip 2000:172:16:201::20

end

To enable NAT64 and configure address prefix using the CLI:

config system nat64 set status enable set secondary-prefix-status enable config secondary-prefix edit “1” set nat64-prefix 2000:172:16:201::/96

end

To create NAT46 policy using the GUI:

Go to Policy & Object > NAT46 Policy.
Click Create New.
For Incoming Interface, select port10.
For Outgoing Interface, select port9.
For Source Address, select all.
For Destination Address, select vip46_server.
Set IP Pool Configuration to Use Dynamic IP Pool and select the IP pool client_expernal.
Click OK.

To create NAT46 policy using the CLI:

config firewall policy46 edit 1 set srcintf “port10” set dstintf “port9” set srcaddr “all” set dstaddr “vip46_server” set action accept set schedule “always” set service “ALL” set ippool enable set poolname “client_external”

end

Sample troubleshooting

Example to trace flow to see the whole process.

# dia de flow filter saddr 10.1.100.11 # dia de flow show function-name enable show function name

# dia de flow show iprope enable show trace messages about iprope # dia de flow trace start 5

id=20085 trace_id=1 func=print_pkt_detail line=5401 msg=”vd-root:0 received a packet(proto=1, 10.1.100.11:27592->10.1.100.55:2048) from port10. type=8, code=0, id=27592, seq=1.” id=20085 trace_id=1 func=init_ip_session_common line=5561 msg=”allocate a new session-

000003b9″

id=20085 trace_id=1 func=iprope_dnat_check line=4948 msg=”in-[port10], out-[]” id=20085 trace_id=1 func=iprope_dnat_tree_check line=822 msg=”len=1″

id=20085 trace_id=1 func=__iprope_check_one_dnat_policy line=4822 msg=”checking gnum-100000 policy-1″

id=20085 trace_id=1 func=get_vip46_addr line=998 msg=”find DNAT46: IP-2000:172:16:200::55, port-27592″

id=20085 trace_id=1 func=__iprope_check_one_dnat_policy line=4904 msg=”matched policy-1, actt=accept, vip=1, flag=100, sflag=2000000″

id=20085 trace_id=1 func=iprope_dnat_check line=4961 msg=”result: skb_flags-02000000, vid-1, ret-matched, act-accept, flag-00000100″

id=20085 trace_id=1 func=fw_pre_route_handler line=183 msg=”VIP-10.1.100.55:27592, outdevunkown”

id=20085 trace_id=1 func=__ip_session_run_tuple line=3220 msg=”DNAT 10.1.100.55:8-

>10.1.100.55:27592″

id=20085 trace_id=1 func=vf_ip_route_input_common line=2594 msg=”find a route: flag=80000000 gw-10.1.100.55 via root” id=20085 trace_id=1 func=ip4_nat_af_input line=601 msg=”nat64 ipv4 received a packet proto=1″ id=20085 trace_id=1 func=__iprope_check line=2112 msg=”gnum-100012, check-ffffffffa0024ebe” id=20085 trace_id=1 func=__iprope_check_one_policy line=1873 msg=”checked gnum-100012 policy-

1, ret-matched, act-accept”

id=20085 trace_id=1 func=__iprope_user_identity_check line=1677 msg=”ret-matched” id=20085 trace_id=1 func=get_new_addr46 line=1047 msg=”find SNAT46: IP-2000:172:16:201::13

(from IPPOOL), port-27592″

id=20085 trace_id=1 func=__iprope_check_one_policy line=2083 msg=”policy-1 is matched, actaccept”

id=20085 trace_id=1 func=__iprope_check line=2131 msg=”gnum-100012 check result: ret-matched, act-accept, flag-08050500, flag2-00200000″

id=20085 trace_id=1 func=iprope_policy_group_check line=4358 msg=”after check: ret-matched, act-accept, flag-08050500, flag2-00200000″ id=20085 trace_id=1 func=resolve_ip6_tuple line=4389 msg=”allocate a new session-00000081″

NAT64 policy and DNS64 (DNS proxy)

1 Reply

NAT64 policy and DNS64 (DNS proxy)

NAT64 policy translates IPv6 addresses to IPv4 addresses so that a client on an IPv6 network can communicate transparently with a server on an IPv4 network.

NAT64 policy is usually implemented in combination with the DNS proxy called DNS64. DNS64 synthesizes AAAA records from A records and is used to synthesize IPv6 addresses for hosts that only have IPv4 addresses. DNS proxy and DNS64 are interchangeable terms.

Sample topology

In this example, a host on the internal IPv6 network communicates with ControlPC.qa.fortinet.com that only has IPv4 address on the Internet.

The host on the internal network does a DNS lookup for qa.fortinet.com by sending a DNS query for an AAAA record for ControlPC.qa.fortinet.com.
The DNS query is intercepted by the FortiGate DNS proxy. The DNS proxy performs an A-record query for qa.fortinet.com and gets back an RRSet containing a single A record with the IPv4 address 172.16.200.55.
The DNS proxy then synthesizes an AAAA record. The IPv6 address in the AAAA record begins with the configured NAT64 prefix in the upper 96 bits and the received IPv4 address in the lower 32 bits. By default, the resulting IPv6 address is 64:ff9b::172.16.200.55.
The host on the internal network receives the synthetic AAAA record and sends a packet to the destination address 64:ff9b::172.16.200.55.
The packet is routed to the FortiGate internal interface (port10) where it is accepted by the NAT64 security policy.
The FortiGate unit translates the destination address of the packets from IPv6 address

64:ff9b::172.16.200.55 to IPv4 address 172.16.200.55 and translates the source address of the packets to 172.16.200.200 (or another address in the IP pool range) and forwards the packets out the port9 interface to the Internet.

Sample configuration

To enable display for IPv6, NAT46/NAT64, and DNS Database using the GUI:

Go to System > Feature Visibility.
In the Basic Features section, enable IPv6.
In the Additional Features section, enable the following features: l NAT46 & NAT64 l DNS Database
Click Apply.

To enable display for IPv6, NAT46/NAT64, and DNS Database using the CLI:

config system global set gui-ipv6 enable

end

config system settings set gui-nat46-64 enable set gui-dns-database enable

end

To enable DNS proxy on the IPv6 interface using the GUI:

Go to Network > DNS Servers.
In DNS Service on Interface, click Create New.
For Interface, select port10.
Click OK.

To enable DNS proxy on the IPv6 interface using the CLI:

config system dns-server edit “port10” set mode forward-only

end

To configure IPv6 DHCP server using the CLI:

config system dhcp6 server edit 1 set subnet 2001:db8:1::/64 set interface “port10” config ip-range edit 1 set start-ip 2001:db8:1::11 set end-ip 2001:db8:1::20

end

set dns-server1 2001:db8:1::10

end

To enable NAT64 and related settings using the CLI:

Enabling NAT64 with the config system nat64 command means that all IPv6 traffic received by the current VDOM can be subject to NAT64 if the source and destination address matches an NAT64 security policy.

By default, the setting always-synthesize-aaaa-record is enabled. If you disable this setting, the DNS proxy (DNS64) will attempt to find an AAAA records for queries to domain names and therefore resolve the host names to IPv6 addresses. If the DNS proxy cannot find an AAAA record, it synthesizes one by adding the NAT64 prefix to the A record.

nat64-prefix setting is the nat64 prefix. By default, it is 64:ff9b::/96.

config system nat64 set status enable end

To create NAT64 policy using the GUI:

Add an IPv4 firewall address for the external network.
1. Go to Policy & Object > Addresses.
2. Click Create New.
3. For Name, enter external-net4.
4. For IP/Network, enter 200.0/24.
5. For Interface, select
6. Click OK.
Add an IPv6 firewall address for the internal network.
1. Go to Policy & Object > Addresses.
2. Click Create New.
3. Change Category to IPv6 Address.
4. For Name, enter internal-net6.
5. For IPv6 Address, enter 2001:db8:1::/48.
6. Click OK.
Add an IP pool containing the IPv4 address that is used as the source address of the packets exiting port9.
1. Go to Policy & Object > IP Pools.
2. Click Create New.
3. For Name, enter exit-pool4.
4. For External IP Range, enter 16.200.200-172.16.200.210.
5. Click OK.
Add a NAT64 policy that allows connections from the internal IPv6 network to the external IPv4 network.
1. Go to Policy & Object > NAT64 Policy.
2. Click Create New.
3. For Incoming Interface, select port10.
4. For Outgoing Interface, select port9.
5. For Source Address, select internal-net6.
6. For Destination Address, select external-net4.
7. Set IP Pool Configuration to Use Dynamic IP Pool and select the IP pool exit-pool4. Click OK.

To create NAT64 policy using the CLI:

config firewall address edit “external-net4” set associated-interface “port9” set subnet 172.16.200.0 255.255.255.0

end

config firewall address6 edit “internal-net6” set ip6 2001:db8:1::/48

end

config firewall ippool edit “exit-pool4”

set startip 172.16.200.200 set endip 172.16.200.210

end

config firewall policy64 edit 1 set srcintf “port10” set dstintf “port9” set srcaddr “internal-net6” set dstaddr “external-net4” set action accept set schedule “always” set service “ALL” set ippool enable set poolname “exit-pool4”

end

Policy with Internet Service

1 Reply

Policy with Internet Service

Using Internet Service in policy

This recipe shows how to apply a predefined Internet Service entry into a policy.

The Internet Service Database is a comprehensive public IP address database that combines IP address range, IP owner, service port number, and IP security credibility. The data comes from the FortiGuard service system. Information is regularly added to this database, for example, geographic location, IP reputation, popularity & DNS, and so on. All this information helps users define Internet security more effectively.

From FortiOS version 5.6 on, the Internet Service is included in the firewall policy, It can be applied to a policy only as a Destination object. From version 6.0, Internet Services can be applied both as Source and Destination objects in policy. You can also apply Internet Services to shaping policy.

There are three types of Internet Services we can apply to firewall policy:

l Predefined Internet Services. l Custom Internet Services. l Extension Internet Services.

Sample configuration

To apply a predefined Internet Service entry into a policy using the GUI:

Go to Policy & Objects and create a new policy.
In the Source or Destination field, click +.
In the Select Entries pane, click Internet Service.
Locate and click Gmail.
Configure the other fields and then click OK.

To apply a predefined Internet Service entry into a policy using the CLI:

In the CLI, enable the internet-service first and then use its ID to apply the policy.

This example uses Google Gmail and its ID is 65646. Each Internet Service has a unique ID.

config firewall policy edit 9 set name “Internet Service in Policy” set srcintf “wan2” set dstintf “wan1” set srcaddr “all” set internet-service enable set internet-service-id 65646 set action accept set schedule “always” set utm-status enable set av-profile “g-default”

set ssl-ssh-profile “certificate-inspection”

set nat enable

next end

To diagnose an Internet Service entry using the CLI:

diag internet-service id-summary 65646

Version: 0000600096

Timestamp: 201902111802

Total number of IP ranges: 444727

Number of Groups: 7

Group(0), Singularity(20), Number of IP ranges(142740)

Group(1), Singularity(19), Number of IP ranges(1210)

Group(2), Singularity(16), Number of IP ranges(241)

Group(3), Singularity(15), Number of IP ranges(38723)

Group(4), Singularity(10), Number of IP ranges(142586)

Group(5), Singularity(8), Number of IP ranges(5336)

Group(6), Singularity(6), Number of IP ranges(113891)

Internet Service: 65646(Google.Gmail)

Number of IP range: 60

Number of IP numbers: 322845

Singularity: 15

Reputation: 5(Known and verified safe sites such as Gmail, Amazon, eBay, etc.)

Icon Id: 510

Second Level Domain: 53(gmail.com)

Direction: dst

Data source: isdb

Result

Because the IP and services related to Google Gmail on the Internet are included in this Internet Service (65646), all traffic to Google Gmail is forwarded by this policy.

Using custom Internet Service in policy

Even though there are about 1,395 predefined Internet Services entries and a total of 444,727 IP ranges, we sometimes still need to create our own Internet Service entries. FortiOS supports custom Internet Service in a firewall policy.

When creating a custom Internet Service, you must set following elements:

l IP or IP Ranges l Protocol number l Port or Port Ranges l Reputation

You must use CLI to create a custom Internet Service. Custom Internet Service CLI syntax

config firewall internet-service-custom edit <name> set comment <comment> set reputation {1|2|3|4|5} config entry edit <ID #> set protocol <number #> set dst <object_name> config port-range

edit <ID #>

set start-port <number #> set end-port <number #>

end

next end end

end

Sample configuration

To configure a custom Internet Service using the CLI:

config firewall internet-service-custom

edit “test-isdb-1” set comment “Test Custom Internet Service” set reputation 4 config entry

edit 1

set protocol 6

config port-range

edit 1

set start-port 80

set end-port 443

end set dst “10-1-100-0”

next edit 2

set protocol 6 config port-range

edit 1

set start-port 80

set end-port 80

end set dst “172-16-200-0”

end

To apply a custom Internet Service into policy using the CLI:

config firewall policy

edit 1

set name “Internet Service in Policy” set srcintf “wan2” set dstintf “wan1” set srcaddr “all” set internet-service enable set internet-service-id 65646 set internet-service-custom “test-isdb-1” set action accept

set schedule “always” set utm-status enable set av-profile “g-default”

set ssl-ssh-profile “certificate-inspection”

set nat enable

end

Result

In addition to the IP/IP-Ranges and services allowed by Google.Gmail, this policy also allows the traffic which access to 10.1.100.0/24 and TCP/80-443 and 172.16.200.0/24 and TCP/80.

Using extension Internet Service in policy

Extension Internet Service lets you add custom IP_Range(s)+Port_Range(s) to an existing prpedefined Internet Servic, or remove IP_Range(s)+Port_Range(s) from an existing predefined Internet Service entry.

Using an extension type Internet Service is actually editing a predefined type Internet Service entry and add IP_Range (s)+ Port_Range(s) to it.

When creating an extension Internet Service and adding custom IP_Range(s)+Port_Range(s), you must set following elements:

l IP or IP Ranges l Protocol number l Port or Port Ranges

You must use CLI to add custom IP(s)+Port(s) entries into a predefined Internet Service.

You must use GUI to remove entries from a predefined Internet Service. Custom extension Internet Service CLI syntax

config firewall internet-service-extension edit <ID #> set comment <comment> config entry edit <ID #> set protocol <number #> set dst <object_name> config port-range edit <ID #> set start-port <number #> set end-port <number #>

end

end end

Sample configuration

To configure an extension Internet Service using the CLI:

config firewall internet-service-extension edit 65646 set comment “Test Extension Internet Service 65646” config entry edit 1 set protocol 6 config port-range edit 1 set start-port 80 set end-port 443

end

set dst “172-16-200-0”

next edit 2 set protocol 17 config port-range edit 1 set start-port 53 set end-port 53

end

set dst “10-1-100-0”

end

To removing IP(s)+Port(s) entries from an existing Internet Service:

Go to Policy & Objects > Internet Service Database.
Search for Gmail.
Select Gmail and click Edit.
Locate the IP entry you want to remove and click Disable beside that entry.
Click Return.
When you complete the actions in the GUI, the CLI automatically generates the configuration from your GUI actions:

config firewall internet-service-extension edit 65646 set comment “Test Extension Internet Service 65646” config entry

edit 1 set protocol 6 config port-range

edit 1 set start-port 80 set end-port 443

end set dst “172-16-200-0”

next edit 2 set protocol 17 config port-range

edit 1 set start-port 53 set end-port 53

end set dst “10-1-100-0”

end config disable-entry edit 1 set protocol 6 config port-range

edit 1 set start-port 25 set end-port 25

next edit 2 set start-port 80 set end-port 80

next edit 3 set start-port 110 set end-port 110

next edit 4 set start-port 143 set end-port 143

next edit 5 set start-port 443 set end-port 443

next edit 6 set start-port 465 set end-port 465

next edit 7 set start-port 587 set end-port 587

next edit 8 set start-port 993 set end-port 993

next edit 9 set start-port 995 set end-port 995

next edit 10 set start-port 2525 set end-port 2525

end config ip-range edit 1 set start-ip 2.20.183.160 set end-ip 2.20.183.160

end

To apply an extension Internet Service into policy using the CLI:

set ssl-ssh-profile “certificate-inspection”

set nat enable

end

Result

In addition to the IP(s)/IP-Range(s) and services allowed by Google.Gmail, this policy also allows the traffic which accesses 10.1.100.0/24 and UDP/53 and 172.16.200.0/24 and TCP/80-443. At the same time, the traffic which accesses 2.20.183.160 is dropped because this IP+Port(s) is disabled from Google.Gmail.

Policy with destination NAT

Leave a reply

Policy with destination NAT

Static virtual IPs

Usually we use VIP to implement Destination Address Translation. Mapping a specific IP address to another specific IP address is usually referred to as Destination NAT. When the Central NAT Table is not used, FortiOS calls this a Virtual IP Address (VIP). FortiOS uses a DNAT or Virtual IP address to map an external IP address to an IP address. This address does not have to be an individual host, it can also be an address range. This mapping can include all TCP/UDP ports or, if Port Forwarding is enabled, it only refers to the configured ports. Because, the Central NAT table is disabled by default, the term Virtual IP address or VIP is predominantly used.

Virtual IP addresses are typically used to NAT external or public IP addresses to internal or private IP addresses. Using a Virtual IP address between two internal interfaces made up of private IP addresses is possible but there is rarely a reason to do so as the two networks can just use the IP addresses of the networks without the need for any address translation. Using a Virtual IP address for traffic going from the inside to the Internet is even less likely to be a requirement, but it is supported.

Sample configuration

To create a virtual IP using the GUI:

In Policy & Objects > Virtual IPs.
Click Create New and select Virtual IP.
Select a VIP Type.

Select the VIP Type depending on the IP version network on the FortiGate’s external interface and internal interface. l If IPv4 is on both sides of the FortiGate unit, select IPv4. l If IPv6 is on both sides of the FortiGate unit, select IPv6. l If traffic goes from an IPv4 network to an IPv6 network, select NAT46. l If traffic goes from an IPv6 network to an IPv4 network, select NAT64.

Enter a unique name for the virtual IP and fill in the other fields.

To create a virtual IP using the CLI:

config firewall vip edit “Internal_WebServer” set extip 10.1.100.199 set extintf “any” set mappedip “172.16.200.55”

end

To apply a virtual IP to policy using the CLI:

config firewall policy edit 8 set name “Example_Virtual_IP_in_Policy”

set srcintf “wan2” set dstintf “wan1” set srcaddr “all”

set dstaddr “Internal_WebServer” set action accept set schedule “always” set service “ALL” set nat enable

end

Virtual IP with services

Virtual IP with services is a more flexible virtual IP mode. This mode allows users to define services to a single port number mapping.

This recipe shows how to use virtual IP with services enabled. This example has one public external IP address. We map TCP ports 8080, 8081, and 8082 to an internal WebServer TCP port 80. This allows remote connections to communicate with a server behind the firewall.

Sample configuration

To create a virtual IP with services using the GUI:

In Policy & Objects > Virtual IPs.
Click Create New and select Virtual IP.
For VIP Type, select IPv4.
Enter a unique name for the virtual IP and fill in the other fields.
Configure the fields in the Network For example: l Set Interface to any.
- Set External IP Address/Range to 1.100.199.
- Set Mapped IP Address/Range to 16.200.55.
Enable Optional Filters and then enable Services.
In the Services field, click + to display the Services pane.
In the Services pane, select TCP_8080, TCP_8081, and TCP_8082.
Enable Port Forwarding.
Set Map to Port to 80.
Click OK.

To see the results:

Apply the above virtual IP to the Firewall policy.
The results are:
- Access 10.1.100.199:8080 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
- Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
- Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.55:80 in internal network.

To create a virtual IP with services using the CLI:

config firewall vip edit “WebServer_VIP_Services” set service “TCP_8080” “TCP_8081” “TCP_8082” set extip 10.1.100.199 set extintf “any” set portforward enable set mappedip “172.16.200.55” set mappedport 80

end

Virtual IPs with port forwarding

If you need to hide the internal server port number or need to map several internal servers to the same public IP address, enable port-forwarding for Virtual IP.

This recipe shows how to use virtual IPs to configure port forwarding on a FortiGate unit. This example has one public external IP address. We map TCP ports 8080, 8081, and 8082 to different internal WebServers’ TCP port 80. This allows remote connections to communicate with a server behind the firewall.

Sample configuration

To create a virtual IP with port forwarding using the GUI:

In Policy & Objects > Virtual IPs.
Click Create New and select Virtual IP.
For VIP Type, select IPv4.
Enter a unique name for the virtual IP and fill in the other fields.
Configure the fields in the Network For example:
- Set Interface to any.
- Set External IP Address/Range to 1.100.199. l Set Mapped IP Address/Range to 172.16.200.55.
Leave Optional Filters
Enable Port Forwarding.
Configure the fields in the Port Forwarding For example:
- Set Protocol to TCP. l Set External Service Port to 8080 -8080. l Set Map to Port to 80 -80.
Click OK.
Follow the above steps to create two additional virtual IPs.
For one virtual IP:
- Use a different Mapped IP Address/Range, for example, 16.200.56. l Set External Service Port to 8081 -8081. l Use the same Map to Port numbers: 80 -80.

For the other virtual IP:

Use a different Mapped IP Address/Range, for example, 16.200.57. l Set External Service Port to 8082 -8082. l Use the same Map to Port numbers: 80 -80.

Create a Virtual IP Group and put the above three virtual IPs into that group.

To see the results:

Apply the above virtual IP to the Firewall policy.
The results are:
- Access 10.1.100.199:8080 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
- Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.56:80 in internal network.
- Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.57:80 in internal network

Virtual server

This topic shows a special virtual IP type: virtual server, Use this type of VIP to implement server load balancing.

The FortiOS server load balancing contains all the features of a server load balancing solution. You can balance traffic across multiple backend servers based on multiple load balancing schedules including:

Static (failover). l Round robin.
Weighted (to account for different sized servers or based on the health and performance of the server including round trip time and number of connections).

The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL/TLS, and generic TCP/UDP and IP protocols.

Session persistence is supported based on the SSL session ID based on an injected HTTP cookie, or based on the HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade attacks. Server load balancing is supported on most FortiGate devices and includes up to 10,000 virtual servers on high end systems.

Sample topology

SSL/TLS offloading

FortiGate SSL/TLS offloading is designed for the proliferation of SSL/TLS applications. The key exchange and encryption/decryption tasks are offloaded to the FortiGate unit where they are accelerated using FortiASIC technology which provides significantly more performance than a standard server or load balancer. This frees up valuable resources on the server farm to give better response to business operations. Server load balancing offloads most SSL/TLS versions including SSL 3.0, TLS 1.0, and TLS 1.2; and supports full mode or half mode SSL offloading with DH key sizes up to 4096 bits.

FortiGate SSL offloading allows the application payload to be inspected before it reaches your servers. This prevents intrusion attempts, blocks viruses, stops unwanted applications, and prevents data leakage. SSL/TLS content inspection supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.

Virtual server requirements

When creating a new virtual server, you must configure the following options:

Virtual Server Type. l Load Balancing Methods. l Health check monitoring (optional). l Session persistence (optional).
Virtual Server IP (External IP Address).
Virtual Server Port (External Port). l Real Servers (Mapped IP Address & Port).

Virtual server types

Select the protocol to be load balanced by the virtual server. If you select a general protocol such as IP, TCP, or UDP, the virtual server load balances all IP, TCP, or UDP sessions. If you select specific protocols such as HTTP, HTTPS, or SSL, you can apply additional server load balancing features such as Persistence and HTTP Multiplexing.

HTTP	Select HTTP to load balance only HTTP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 80 for HTTP sessions). You can also select HTTP Multiplexing. You can also set Persistence to HTTP Cookie to enable cookie-based persistence.
HTTPS	Select IMAPS to load balance only IMAPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID.
IMAPS	Select IMAPS to load balance only IMAPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID.
POP3S	Select POP3S to load balance only POP3S sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 995 for POP3S sessions). You can also set Persistence to SSL Session ID.
SMTPS	Select SMTPS to load balance only SMTPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 465 for SMTPS sessions). You can also set Persistence to SSL Session ID.
SSL	Select SSL to load balance only SSL sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
TCP	Select TCP to load balance only TCP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
UDP		Select UDP to load balance only UDP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
IP		Select IP to load balance all sessions accepted by the security policy that contains this virtual server.

Load balancing methods

The load balancing method defines how sessions are load balanced to real servers.

All load balancing methods do not send traffic to real servers that are down or not responding. FortiGate can only determine if a real server is not responding by using a health check monitor. You should always add at least one health check monitor to a virtual server or to real servers; otherwise load balancing might try to distribute sessions to real servers that are not functioning.

Static	The traffic load is statically spread evenly across all real servers. Sessions are not assigned according to how busy individual real servers are. This load balancing method provides some persistence because all sessions from the same source address always go to the same real server. Because the distribution is stateless, so if a real server is added, removed, or goes up or down, the distribution is changed and persistence might be lost.
Round Robin	Directs new requests to the next real server. This method treats all real servers as equals regardless of response time or the number of connections. This method does not direct requests to real servers that down or non responsive.
Weighted	Real servers with a higher weight value receive a larger percentage of connections. Set the real server weight when adding a real server.
Least Session	Directs requests to the real server that has the least number of current connections. This method works best in environments where the real servers or other equipment you are load balancing all have similar capabilities. This load balancing method uses the FortiGate session table to track the number of sessions being processed by each real server. The FortiGate unit cannot detect the number of sessions actually being processed by a real server.
Least RTT	Directs sessions to the real server with the lowest round trip time. The round trip time is determined by a ping health check monitor. The default is 0 if no ping health check monitors are added to the virtual server.
First Alive	Directs sessions to the first live real server. This load balancing schedule provides real server failover protection by sending all sessions to the first live real server. If a real server fails, all sessions are sent to the next live real server. Sessions are not distributed to all real servers so all sessions are processed by the first real server only.
HTTP Host	Load balances HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server.

Health check monitoring

In the FortiGate GUI, you can configure health check monitoring so that the FortiGate unit can verify that real servers are able respond to network connection attempts. If a real server responds to connection attempts, the load balancer continues to send sessions to it. If a real server stops responding to connection attempts, the load balancer assumes that the server is down and does not send sessions to it. The health check monitor configuration determines how the load balancer tests real servers. You can use a single health check monitor for multiple load balancing configurations. You can configure TCP, HTTP, and Ping health check monitors. You usually set the health check monitor to use the same protocol as the traffic being load balanced to it. For example, for an HTTP load balancing configuration, you would normally use an HTTP health check monitor.

Session persistence

Use persistence to ensure a user is connected to the same real server every time the user makes an HTTP, HTTPS, or SSL request that is part of the same user session. For example, if you are load balancing HTTP and HTTPS sessions to a collection of eCommerce web servers, when users make a purchase, they will be starting multiple sessions as they navigate the eCommerce site. In most cases, all the sessions started by this user during one eCommerce session should be processed by the same real server. Typically, the HTTP protocol keeps track of these related sessions using cookies. HTTP cookie persistence ensure all sessions that are part of the same user session are processed by the same real server.

When you configure persistence, the FortiGate unit load balances a new session to a real server according to the load balance method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server.

Real servers

Add real servers to a load balancing virtual server to provide information the virtual server requires to send sessions to the server. A real server configuration includes the IP address of the real server and port number the real server receives sessions on. The FortiGate unit sends sessions to the real server’s IP address using the destination port number in the real server configuration.

When configuring a real server, you can also specify the weight (if the load balance method is set to Weighted) and you can limit the maximum number of open connections between the FortiGate unit and the real server. If the maximum number of connections is reached for the real server, the FortiGate unit automatically switches all further connection requests to other real servers until the connection number drops below the limit. Setting Maximum Connections to 0 means that the FortiGate unit does not limit the number of connections to the real server.

Sample of HTTP load balancing to three real web servers

This example describes the steps to configure the load balancing configuration below. In this configuration, a FortiGate unit is load balancing HTTP traffic from the Internet to three HTTP servers on the internal network. HTTP sessions are accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080, and forwarded from the internal interface to the web servers. When forwarded, the destination address of the session is translated to the IP address of one of the web servers.

This load balancing configuration also includes session persistence using HTTP cookies, round-robin load balancing, and TCP health monitoring for the real servers. Ping health monitoring consists of the FortiGate unit using ICMP ping to ensure the web servers can respond to network traffic.

To configure load balancing using the GUI:

Go to Policy & Objects > Health Check.
Create a new Health Check Monitor and set the following fields as an example:
- Set Name to Ping-mon-1.
- Set Type to Ping. l Set Interval to 10 l Set Timeout to 2 seconds. l Set Retry to 3 attempt(s).
Go to Policy & Objects > Virtual Servers.
Create a new Virtual Server and set the following fields as an example:
- Set Name to Vserver-HTTP-1. l In the Network section, set Type to HTTP.
- Set Interface to wan1. l Set Virtual ServerIP to 20.120.121.
- Set Virtual ServerPort to 8080.
- Set Load Balance Method to Round Robin.
- Set Persistence to HTTP Cookie. l Set Health Check to Ping-mon-1. l Do not enable HTTP Multiplexing.
- Do not enable Preserve Client IP.
In the Real Servers section, add the three load balance real servers to the virtual server. For example:
- Add the IP Address 31.101.30, 10.31.101.40, and 10.31.101.50.
- For all IP addresses, set Port to 80. l For all IP addresses, set Max Connections to 0. l For all IP addresses, set Mode to Active.
Add a security policy that includes the load balance virtual server as the destination address.

To see the results:

Traffic accessing 172.20.120.121:8080 is forwarded to the three real servers in turn.
If the access request has an http-cookie, FortiGate forwards the access to the corresponding real server according to the cookie.

Policy with source NAT

3 Replies

Policy with source NAT

Static SNAT

NAT or Network Address Translation is the process that enables a single device such as a router or firewall to act as an agent between the Internet or Public Network and a local or private network. This agent acts in real time to translate the source or destination IP address of a client or server on the network interface. For the source IP translation, this enables a single public address to represent a significantly larger number of private addresses. For the destination IP translation, the firewall can translate a public destination address to a private address. So we don’t have to configure a real public IP address for the server deployed in a private network.

We can subdivide NAT into two types: source NAT (SNAT) and destination NAT (DNAT). This topic is about SNAT, We support three NAT working modes: static SNAT, dynamic SNAT, and central SNAT.

In static SNAT all internal IP addresses are always mapped to the same public IP address. This is a port address translation, Since we have 60416 available port numbers, this one public IP address can handle the conversion of 60,416 internal IP addresses. See example below.

FortiGate firewall configurations commonly use the Outgoing Interface address.

Sample configuration

The following example of static SNAT uses an internal network with subnet 10.1.100.0/24 (vlan20) and an external/ISP network with subnet 172.16.200.0/24 (vlan30).

When the clients in internal network need to access the servers in external network, We need to translate IP addresses from 10.1.100.0/24 to an IP address 172.16.200.0/24, In this example, we implement static SNAT by creating a firewall policy.

To configure static NAT:

In Policy & Objects > IPv4 Policy, click Create New.
Enter the required policy parameters.
Enable NAT and select Use Outgoing Interface Address.
If needed, enable Preserve Source Port.

Enable Preserve Source Port to keep the same source port for services that expect traffic to come from a specific source port.

Disable Preserve Source Port to allow more than one connection through the firewall for that service.

For packets that match this policy, its source IP address is translated to the IP address of the outgoing interface.

Dynamic SNAT

Dynamic SNAT maps the private IP addresses to the first available public address from a pool of addresses. In the

FortiGate firewall, this can be done by using IP pools. IP pools is a mechanism that allows sessions leaving the FortiGate firewall to use NAT. An IP pool defines a single IP address or a range of IP addresses to be used as the source address for the duration of the session. These assigned addresses are used instead of the IP address assigned to that FortiGate interface.

IP pool types

FortiGate uses four types of IPv4 IP pools. This recipe focuses on some of the differences between them.

Overload

This type of IP pool is similar to static SNAT mode. We just need to define an external IP range, This range can contain one or multiple IP addresses, When there is only one IP address, it almost as same as static SNAT – use Outgoing Interface address. When it contains multiple IP addresses, It is equivalent to an extended mode of static SNAT.

For instance, if we define an overload type IP pool with two external IP addresses (172.16.200.1—172.16.200.2), since there are 60,416 available port numbers per IP, this IP pool can handle 60,416*2 internal IP addresses. See example below.

One-to-one

This type of IP pool means that the internal IP address and the external (translated) IP address match one-to-one. The port address translation (PAT) is disabled when using this type of IP pool. For example, if we define a one-to-one type IP pool with two external IP addresses (172.16.200.1-172.16.200.2), this IP pool only can handle two internal IP addresses.

Fixed port range

For the overload and one-to-one IP pool types, we do not need to define the internal IP range. For the fixed port range type of IP pool, we can define both internal IP range and external IP range. Since each external IP address and the number of available port numbers is a specific number, if the number of internal IP addresses is also determined, we can calculate the port range for each address translation combination. So we call this type fixed port range. This type of IP pool is a type of port address translation (PAT).

For instance, if we define one external IP address (172.16.200.1) and ten internal IP addresses (10.1.100.110.1.100.10), we have translation IP+Port combination like following table:

Port block allocation

This type of IP pool is also a type of port address translation (PAT). It gives users a more flexible way to control the way external IPs and ports are allocated. Users need to define Block Size/Block PerUser and external IP range. Block Size means how many ports each Block contains. Block perUser means how many blocks each user (internal IP) can use.

Following is a simple example:

External IP Range: 172.16.200.1—172.16.200.1

Block Size: 128 Block Per User: 8

Result:

Total-PBAs: 472 (60416/128)

Maximum ports can be used per User (Internal IP Address): 1024 (128*8)

How many Internal IP can be handled: 59 (60416/1024 or 472/8)

Sample configuration

To configure Overload IP pool using the GUI:

In Policy & Objects > IP Pools, click Create New.
Select IPv4 Pool and then select Overload.

To configure Overload IP pool using the CLI:

config firewall ippool

edit “Overload-ippool” set startip 172.16.200.1 set endip 172.16.200.1

end

To configure One-to-One IP pool using the GUI:

In Policy & Objects > IP Pools, click Create New.
Select IPv4 Pool and then select One-to-One.

To configure One-to-One IP pool using the CLI:

config firewall ippool

edit “One-to-One-ippool” set type one-to-one set startip 172.16.200.1 set endip 172.16.200.2

end

To configure Fixed Port Range IP pool using the GUI:

In Policy & Objects > IP Pools, click Create New.
Select IPv4 Pool and then select Fixed Port Range.

To configure Fixed Port Range IP pool using the CLI:

config firewall ippool edit “FPR-ippool”

set type fixed-port-range set startip 172.16.200.1 set endip 172.16.200.1 set source-startip 10.1.100.1 set source-endip 10.1.100.10

end

To configure Port Block Allocation IP pool using the GUI:

In Policy & Objects > IP Pools, click Create New.
Select IPv4 Pool and then select Port Block Allocation.

To configure Port Block Allocation IP pool using the CLI:

config firewall ippool edit PBA-ippool set type port-block-allocation set startip 172.16.200.1 set endip 172.16.200.1 set block-size 128 set num-blocks-per-user 8

end

Central SNAT

The central SNAT table enables you to define and control (with more granularity) the address translation performed by FortiGate. With the NAT table, you can define the rules for the source address or address group, and which IP pool the destination address uses.

While similar in functionality to IP pools where a single address is translated to an alternate address from a range of IP addresses, with IP pools there is no control over the translated port. When using the IP pool for source NAT, you can define a fixed port to ensure the source port number is unchanged. If no fixed port is defined, the port translation is randomly chosen by FortiGate. With the central NAT table, you have full control over both the IP address and port translation.

FortiGate reads the NAT rules from the top down until it hits a matching rule for the incoming address. This enables you to create multiple NAT policies that dictate which IP pool is used based on the source address. NAT policies can be rearranged within the policy list. NAT policies are applied to network traffic after a security policy.

The central SNAT table allows you to create, edit, delete, and clone central SNAT entries.

Central SNAT notes

The central NAT feature in not enabled by default.
If central NAT is enabled, the NAT option under IPv4 policies is skipped and SNAT must be done via centralsnat-map. The IPv4 policy list and dialog boxes have messages and redirection links to show this information. l If NGFW mode is policy-based, then it is assumed that central NAT (specifically SNAT) is enabled implicitly.
The option to toggle NAT in central-snat-map policies has been added. Previously it was only shown in NGFW policy-based mode.
In the central SNAT policy dialog box, the port mapping fields for the original port have been updated to accept ranges.
If per VDOM NAT is enabled, NAT is skipped in firewall policy. l The central SNAT window contains a table of all the central SNAT policies.

Sample configuration

To enable or disable central SNAT using the CLI:

config system settings set central-nat [enable | disable]

end

When central NAT is enabled, Policy & Objects displays the Central SNAT section.

To create central SNAT using the GUI:

In Policy & Objects > Central SNAT.

The right pane displays a table of Central SNAT entries.

To create a new entry, click Create New in the right pane. To edit an entry, double-click the policy you want to edit.
To set the Incoming Interface, click + in that field.
In the pane on the right, select an interface to add it. You can select multiple interfaces.
To set the Outgoing Interface, click click + in that field.
In the pane on the right, select an interface to add it. You can select multiple interfaces.
To set the Source Address, click click + in that field.
In the pane on the right, select an address to add it. You can select multiple addresses.
To set the Destination Address, click click + in that field.
In the pane on the right, select an address to add it. You can select multiple addresses.
In NAT > IP Pool Configuration, select either Use Outgoing Interface Address or Use Dynamic IP Pool.

If you select Use Dynamic IP Pool, click + and select which IP pool to use.

Select one of the following Protocol
- ANY. Use any protocol traffic. l TCP. Use TCP traffic only. Protocol number is set to 6. l UDP. Use UDP traffic only. Protocol number is set to 17. l SCTP. Use SCTP traffic only. Protocol number is set to 132.
- Specify. You can specify the traffic filter protocol by setting the protocol number.
If you use the Overload type of IP pool, you can enable Explicit Port Mapping.
1. If you enable Explicit Port Mapping, set the Original Source Port to the start number of the source port range.
2. Set the Translated Port to the start number of the translated port range.
Click OK.

To configure central SNAT using the CLI:

config firewall central-snat-map

edit <policyID number>set status [enable|disable] set orig-addr <valid address object preconfigured on the FortiGate> set srcintf <name of interface on the FortiGate>

set dst-addr <valid address object preconfigured on the FortiGate> set dstintf <name of interface on the FortiGate> set protocol <integer for protocol number> set orig-port <integer for original port number> set nat-port <integer for translated port number> set comments <string>

end

To set NAT to be not available regardless of NGFW mode:

config firewall central-snat-map edit 1 set orig-addr “192-86-1-86” set srcintf “port23” set dst-addr “192-96-1-96” set dstintf “port22” set nat-ippool “pool1” set protocol 17 set orig-port 2896-2897 set nat enable

end

To hide NAT port if NAT IP pool is not set or if NAT is disabled:

end

To change original port to accept range:

config firewall central-snat-map edit 1

set orig-addr “192-86-1-86” set srcintf “port23” set dst-addr “192-96-1-96” set dstintf “port22” set nat-ippool “pool1” set protocol 17 set orig-port 2896-2897 (help text changed to: Original port or port range).

set nat-port 35804-35805

end

Policy views and policy lookup

Leave a reply

Policy views and policy lookup

This topic provides a sample of firewall policy views and firewall policy lookup.

Policy views

In Policy & Objects policy list page, there are two policy views: Interface PairView and By Sequence view.

Interface PairView displays the policies in the order that they are checked for matching traffic, grouped by the pairs of Incoming and Outgoing interfaces. For example, all policies referencing traffic from WAN1 to DMZ are in one section. The policies referencing traffic from DMZ to WAN1 are in another section. The sections are collapsible so that you only need to look at the sections you want.

By Sequence displays policies in the order that they are checked for matching traffic without any grouping.

The default display is Interface PairView. You can switch between the two views except if any or multiple-interfaces are applied in the policy.

How Any or multiple-interfaces policy can change the Interface Pair View

The FortiGate unit automatically changes the view on the policy list page to By Sequence whenever there is a policy containing any or multiple-interfaces as the Source or Destination interface. If the Interface PairView is grayed out, it is likely that one or more policies have used the any or multiple-interfaces.

When you use the any or multiple-interfaces, the policy goes into multiple sections because it might be any one of a number of interface pairings. Policies are divided into sectioned using the interface pairings, for example, port1 to port2.

Each section has its own policy order. The order in which a policy is checked for matching criteria to a packet’s information is based solely on the position of the policy within its section or within the entire list of policies. If the policy is in multiple sections, FortiGate cannot place the policy in order in multiple sections. Therefore the view can only be By Sequence.

Policy lookup

Firewall policy lookup is based on the Source_interfaces/Protocol/Source_Address/Destination_

Address that matches the source-port and dst-port of the protocol. Use this tool to find out which policy matches specific traffic from a number of policies. After completing the lookup, the matching firewall policy is highlighted on the policy list page.

The Policy Lookup tool has the following requirements:

Transparent mode does not support Policy lookup function.
When executing the policy lookup, you need to confirm whether the relevant route required for the policy work already exists.

Sample configuration

This example uses the TCP protocol to show how policy lookup works:

In Policy & Objects policy list page, click Policy Lookup and enter the traffic parameters.
Click Search to display the policy lookup results.