AppCtrl basic category filters and overrides

Once you have created an application sensor, you can define the applications that you want to control. You can add applications and filters using categories, application overrides, and/or filter overrides.

• Categories: Choose groups of signatures based on a category type. l Application overrides: Choose individual applications. l Filter overrides: Select groups of applications and override the application signature settings for them.

Categories

Categories allow you to choose groups of signatures based on a category type.

Applications belonging to the category trigger the action set to the category.

To set category filters in the CLI:

config application list edit {id} config entries edit 1 set category {id}

set log {enable | disable} next

end

next

end

To set category filters in the GUI:

1. Go to Security Profiles > Application Control.
2. Under Categories, left click the icon next to the category name to view a dropdown of actions:

l Allow l Monitor l Block l Quarantine l View signatures

3. Select OK.

Application and filter overrides

To set overrides in the CLI:

config application list     edit {id}

config entries

edit 1 set protocols {0-47} #network protocol ID

set risk {id}

*level Risk, or impact, of allowing traffic from this application to

occur (1 – 5; Low, Elevated, Medium, High, and Critical).

set vendor {0-25}       #vendor ID

set technology {id}

All         All

• Network-Protocol
• Browser-Based
• Client-Server

4           Peer-to-Peer

set behavior {id}

All         All

• Botnet
• Evasive
• Excessive-Bandwidth
• Tunneling

9           Cloud

set popularity {1-5} #Popularity level 1-5

set action {pass | block | reset}

pass    Pass or allow matching traffic.

block   Block or drop matching traffic.

reset   Reset sessions for matching traffic.

set log {enable | disable}

next

end     next end

To set overrides in the GUI:

1. Go to Security Profiles > Application Control.
2. Under the Application and FilterOverrides table, click Create New.
3. To add individual applications:
   1. Select Application as the Type.
   2. Choose an action to be associated with the application.
   3. Select the + button in the Application field and choose the specific applications from the list where app signatures are displayed. Multiple applications may be selected.
   4. Select OK.
4. To add advanced filters:
   1. Create another entry in the Application and FilterOverrides
   2. Select Filter as the Type.
   3. Select Cloud under the behavior section from the Select Entries Matched signatures are shown along the bottom.
   4. Select OK.

Introduction to AppCtrl sensors

FortiGate units can detect and take action against network traffic depending on the application generating the traffic. Based on FortiGate Intrusion Protection protocol decoders, application control is a user-friendly and powerful way to use Intrusion Protection features to log and manage the behavior of application traffic passing through the FortiGate unit. Application control uses IPS protocol decoders that can analyze network traffic to detect application traffic even if the traffic uses non-standard ports or protocols. Applications control supports detection for traffic using the HTTP protocol (version 1.0, 1.1, and 2.0).

The FortiGate unit can recognize the network traffic generated by a large number of applications. You can create application control sensors that specify the action to take with the traffic of the applications you need to manage and the network on which they are active, and then add application control sensors to the firewall policies that control the network traffic you need to monitor.

An application control sensor has one or more options/entries configured which examines the app traffic for:

• Application category l Application signature ID l Filters overrides l Custom signature l Default port service l Default network service

When selecting the app category, signature, or filter that you intend to work with, the following actions can be set to the specific entry:

• Allow: App traffic will be allowed and no logs are recorded. l Monitor: The entry match is allowed and logged. l Block: Traffic matching the entry will be blocked. l Reset: The session will be dropped and a new session will be started. l Quarantine IP address: Traffic matching the entry will be blocked. The client initiating the traffic will be source-ip banned. l Shaper/Per-ip-shaper: Max-bandwidth and quaratined-bandwidth values can be set to limit the link speed.

AntiVirus

Content disarm and reconstruction for AntiVirus

Introduction

Content Disarm and Reconstruction (CDR) allows the FortiGate to sanitize Microsoft documents and PDF (disarm) by removing active content such as hyperlinks, embedded media, javascript, macros, etc. from the office document files without affecting the integrity of it’s textual content (reconstruction).

This feature allows network admins to protect their users from malicious office document files.

Files processed by CDR can have the original copy quarantined on the FortiGate, allowing admins to observe them. These original copies can also be obtained in the event of a false positive.

Support and limitations

• CDR can only be performed on Microsoft Office Document and PDF files. l Local Disk CDR quarantine is only possible on FortiGate models that contain a hard disk.
• CDR is only supported on HTTP, SMTP, POP3, IMAP. l SMTP splice and client-comfort mode is not supported.
• CDR does not work on flow based inspection modes. l CDR can only work on files in .ZIP type archives.

Network topology example

Configuring the feature

In order to configure AntiVirus to work with CDR, you must enable CDR on your AntiVirus profile, set the quarantine location, and then fine tune the CDR detection parameters.

To enable CDR on your AntiVirus profile:

1. Go to Security Profiles > AntiVirus.
2. Enable the toggle for Content Disarm and Reconstruction under APT Protection Options.

To set a quarantine location:

1. Go to Security Profiles > AntiVirus.
2. Select a quarantine location from the available options, including Discard, File Quarantine, and FortiSandbox.

To fine tune CDR detection parameters in the FortiGate CLI:

• Select which active content to detect/process:
• By default, all active office and PDF content types are enabled. To fine tune CDR to ignore certain content, you must disable that particular content parameter. The example below configures the CDR to ignore Microsoft Office macros.

FGT_PROXY (vdom1) # config antivirus profile

FGT_PROXY (profile) # edit av change table entry ‘av’

FGT_PROXY (av) # config content-disarm

FGT_PROXY (content-disarm) # set office-macro disable FGT_PROXY (content-disarm) #

• Detect but do not modify active content:
• By default, CDR will disarm any detected documents containing active content. To prevent CDR from disarming documents, you can set it to operate in detect-only mode. To do this, the option detect-only must be enabled.

FGT_PROXY (vdom1) # config antivirus profile

FGT_PROXY (profile) # edit av change table entry ‘av’ FGT_PROXY (av) # config content-disarm

FGT_PROXY (content-disarm) # set detect-only ?

disable      Disable this Content Disarm and Reconstruction feature. enable Enable this Content Disarm and Reconstruction feature.

FGT_PROXY (content-disarm) # set detect-only enable FGT_PROXY (content-disarm) #

• Enabling/disabling the CDR cover page:
• By default, a cover page will be attached to the file’s content when the file has been processed by CDR. To disable the cover page, the paramater cover-page needs to be disabled.

FGT_PROXY (vdom1) # config antivirus profile

FGT_PROXY (profile) # edit av change table entry ‘av’

FGT_PROXY (av) # config content-disarm

FGT_PROXY (content-disarm) # set cover-page disable  Disable this Content Disarm and Reconstruction feature. enable    Enable this Content Disarm and Reconstruction feature.

FGT_PROXY (content-disarm) # set cover-page disable

FGT_PROXY (content-disarm) #

FortiGuard Outbreak Prevention for AntiVirus

Introduction

FortiGuard Outbreak Prevention was introduced in FortiOS 6.0.0 and allows the FortiGate’s AntiVirus database to be subsidized with third-party malware hash signatures curated by the FortiGuard.

Those hash signatures are obtained from external sources such as VirusTotal, Symantec, Kaspersky, and other thirdparty websites and services.

This feature provides the mechanism for AntiVirus to query the FortiGuard with the hash of a scanned file. If the FortiGuard returns a match from its many curated signature sources, the scanned file is deemed to be malicious.

The concept of FortiGuard Outbreak Prevention is to detect zero-day malware in a collaborative approach.

Support and limitations

• FortiGuard Outbreak Prevention can be used in both proxy-based and flow-based policy inspections across all supported protocols.
• FortiGuard Outbreak Prevention does not support AV in quick scan mode. l FortiGate must be registered with a valid FortiGuard Outbreak Prevention license before this feature can be used.

Network topology example

Configuring the feature

In order for AntiVirus to work with an external block list, you must register the FortiGate with a FortiGuard Outbreak Prevention license and enable FortiGuard Outbreak Prevention in the AntiVirus profile.

To obtain/renew a FortiGuard AntiVirus license:

1. See the following link for instructions on how to purchase or renew a FortiGuard Outbreak Prevention license:

https://video.fortinet.com/products/fortigate/6.0/how-to-purchase-or-renew-fortiguard-services-6-0

2. Once the license has been activated, you can verify its status by going to Global > System > FortiGuard.

To enable FortiGuard Outbreak Prevention in the AntiVirus profile:

1. Go to Security Profiles > AntiVirus.
2. Select the toggle to enable Use FortiGuard Outbreak Prevention Database.
3. Select Apply.

Diagnostics and debugging

l Check if FortiGate has Outbreak Prevention license:

FGT_PROXY (vdom1) # su 4739 job 1 open

su 4739 req vfid 1 id 1 ep 0 new request, size 313, policy id 1, policy type 0 su 4739 req vfid 1 id 1 ep 0 received; ack 1, data type: 0 su 4739 job 1 request info: su 4739 job 1 client 10.1.100.11:39412 server 172.16.200.44:80 su 4739 job 1 object_name ‘zhvo_test.com’ su 4739 file-typing NOT WANTED options 0x0 file_filter no su 4739 enable databases 0b (core mmdb extended) su 4739 job 1 begin http scan su 4739 scan file ‘zhvo_test.com’ bytes 68

su 4739 job 1 outbreak-prevention scan, level 0, filename ‘zhvo_test.com’ su 4739 scan result 0 su 4739 job 1 end http scan su 4739 job 1 inc pending tasks (1)

su 4739 not wanted for analytics: analytics submission is disabled (m 0 r 0) su 4739 job 1 suspend su 4739 outbreak-prevention recv error su 4739 ftgd avquery id 0 status 1

su 4739 job 1 outbreak-prevention infected entryid=0 su 4739 report AVQUERY infection priority 1

su 4739 insert infection AVQUERY SUCCEEDED loc (nil) off 0 sz 0 at index 0 total infections 1 error 0 su 4739 job 1 dec pending tasks 0 su 4739 job 1 send result su 4739 job 1 close su 4739 outbreak-prevention recv error

External malware blocklist for Antivirus

Introduction

External Malware Blocklist is a new feature introduced in FortiOS 6.2.0 which falls under the umbrella Outbreak Prevention.

This feature provides another means of supporting the AV Database by allowing users to add their own malware signatures in the form of MD5, SHA1, and SHA256 hashes.

This feature provides a mechanism for Antivirus to retrieve an external malware hash list from a remote server and polls the hash list every n minutes for updates.

Support and limitations

Malware detection using External Malware Blocklist can be used in both proxy-based and flow-based policy inspections.

Just like FortiGuard Outbreak Prevention, External Dynamic Block List is not supported in AV quick scan mode.

Using different types of hash simultaneously may slow down the performance of malware scanning. For this reason, users are recommended to only using one type of hash (either MD5, SHA1, or SHA256), not all three simultaneously.

Network topology example

Configuring the feature

To configure AntiVirus to work with External Block List:

1. Creating the Malware Hash List

The malware hash list follows a strict format in order for its contents to be valid. Malware hash signatures entries must be separated into each line. A valid signature needs to follow the format below:

# MD5 Entry with hash description aa67243f746e5d76f68ec809355ec234 md5_sample1

# SHA1 Entry with hash description a57983cb39e25ab80d7d3dc05695dd0ee0e49766 sha1_sample2

# SHA256 Entry with hash description ae9bc0b4c5639d977d720e4271da06b50f7c60d1e2070e9c75cc59ab30e49379 sha256_sample1

# Entry without hash description

0289b0d967cb7b1fb1451339c7b9818a621903090e0020366ab415c549212521

# Invalid entries

7688499dc71b932feb126347289c0b8a_md5_sample2

7614e98badca10b5e2d08f8664c519b7a906fbd5180ea5d04a82fce9796a4b87sha256_sample3

2. Configure External Malware Blocklist source:

Create new external source on Global > Security Fabric > Fabric Connectors page:

• Select Malware Hash:

Fill out the fields as shown below. URI should point to the malware hashlist on the remote server:

• Malware Hash source object is now created:

User can view entries inside the malware blocklist by clicking the View Entries button:

• Malware Has Threatfeed hash_list is shown.

3. Enable External Malware Blocklist in Antivirus profile

Enable External Malware Blocklist on the AntiVirus profile and apply the change:

Antivirus is now ready to use external malware blocklist.

Diagnostics and debugging

Check if scanunit daemon has updated itself with the external hashes:

FGT_PROXY # config global

FGT_PROXY (global) # diagnose sys scanunit malware-list list

md5 ‘aa67243f746e5d76f68ec809355ec234’ profile ‘hash_list’ description ‘md5_sample1’ sha1 ‘a57983cb39e25ab80d7d3dc05695dd0ee0e49766’ profile ‘hash_list’ description ‘sha1_sample2’ sha256 ‘0289b0d967cb7b1fb1451339c7b9818a621903090e0020366ab415c549212521’ profile ‘hash_list’ description ”

sha256 ‘ae9bc0b4c5639d977d720e4271da06b50f7c60d1e2070e9c75cc59ab30e49379’ profile ‘hash_list’ description ‘sha256_sample1’

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:

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

The default bandwidth unit is kbps.

4. Click OK.

To configure an interface bandwidth limit on the FortiOS CLI:

1. 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}

next

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

next

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

next

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:

1. 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.
2. 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.
3. 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:

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

next

end

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

next

end

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

next

end

To troubleshoot shared traffic shapers:

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

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

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

1. 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.
2. Create the per-IP traffic shaper:
3. Go to Policy & Objects > Traffic Shapers. Click Create New.
4. For Type, select Per-IP.
5. In the Name field, enter FTP_Max_1M. This shaper is for VoIP traffic.
6. Enable Max Bandwidth and enter 1000. This equates to 1 Mbps.
7. Enable Max Concurrent Connections and enter 10. This means that each user can have up to ten concurrent connections to the FTP server.
8. Click OK.
9. Create a firewall shaping policy:
10. Go to Policy & Objects > Traffic Shaping Policy. Click Create New.
11. In the Name field, enter FTP speed 1M.
12. For the Source fields, select the users that need to access the FTP server.
13. For the Destination field, select FTP_Server.
14. For the Service field, select ALL.
15. For the Outgoing Interface field, select port9.
16. Enable Per-IP shaper. Select FTP_Max_1M from the dropdown list.
17. Click OK.

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

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

next

end

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

next

end

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

next

end

To troubleshoot per-IP traffic shapers:

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

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

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

next

end

Each priority level is mapped to a value as follows:

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)

next

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:

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:

1. On entering ingress – for packets flowing through the firewall.
2. Upon generation – for packets generated by the firewall (including packets generated due to AV proxying).
3. 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

next

end

Each priority level is mapped to a value like following:

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)

next

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:

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.

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:

1. Go to Policy & Object > Multicast Policy.
2. Click Create New.
3. For Incoming Interface, select port1.
4. For Outgoing Interface, select port2.
5. For Source Address, select 10.0.10/32.
6. For Destination Address, select RIPv2.
7. 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

next

end

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

next

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”

next

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

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:

1. Go to System > Feature Visibility.
2. In the Basic Features section, enable IPv6.
3. In the Additional Features section, enable NAT46 & NAT64.
4. 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:

1. Go to Policy & Object > Virtual IPs.
2. Click Create New.
3. For Name, enter vip46_server.
4. For External IP Address/Range, enter 1.100.55-10.1.100.55.
5. For Mapped IP Address/Range, enter 2000:172:16:200::55.
6. 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

next

end

To configure IPv6 IP pool using the GUI:

1. Go to Policy & Object > IP Pools.
2. Click Create New.
3. For Name, enter client_expternal.
4. For External IP Range, enter 2000:172:16:201::11- 2000:172:16:201::20.
5. 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

next

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

next

end

end

To create NAT46 policy using the GUI:

1. Go to Policy & Object > NAT46 Policy.
2. Click Create New.
3. For Incoming Interface, select port10.
4. For Outgoing Interface, select port9.
5. For Source Address, select all.
6. For Destination Address, select vip46_server.
7. Set IP Pool Configuration to Use Dynamic IP Pool and select the IP pool client_expernal.
8. 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”

next

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)

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. The packet is routed to the FortiGate internal interface (port10) where it is accepted by the NAT64 security policy.
6. 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:

1. Go to System > Feature Visibility.
2. In the Basic Features section, enable IPv6.
3. In the Additional Features section, enable the following features: l NAT46 & NAT64 l DNS Database
4. 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:

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

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

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

next

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

next

end

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

next

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:

1. 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.
2. 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.
3. 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.
4. 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

next

end

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

next

end

config firewall ippool edit “exit-pool4”

set startip 172.16.200.200 set endip 172.16.200.210

next

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”

next

end