Fortinet Basic and Fundamentals

FORTINET
FortiGate Fundamentals
This document describes firewall components, and how to implement firewall policies
on FortiGate units operating in both NAT/Route, and Transparent mode.
This FortiOS Handbook chapter contains the following sections:
The Purpose of a Firewall provides an overview of the FortiGate firewall and its traffic controlling
options.
Life of a Packet describes how a FortiGate unit processes incoming and outgoing network traffic
through its interfaces and firewall policies.
Firewall components describes the FortiGate interfaces, addressing, services and user
configuration that goes into creating a firewall policy.
Firewall Policies describes what policies are, the types of firewall policies and how to configure
and arrange them to ensure proper traffic management.
Troubleshooting describes some common problems and solutions when setting up firewall
policies to manage network traffic.
Concept Example: Small Office Network Protection walks through a small office configuration of
firewall policies.
Concept Example: Library Network Protection walks through an enterprise network

configuration of firewall policies.
The Purpose of a Firewall
Ranging from the FortiGate-30B series for small offices to the FortiGate-5000 series
for large enterprises, service providers and carriers, the FortiGate line combines the FortiOS™
security operating system and latest hardware technologies to provide a comprehensive and
high-performance array of security and networking functions.
FortiGate platforms incorporate sophisticated networking features, such as

high availability for maximum network uptime, and virtual domain (VDOM) capabilities to
separate various networks requiring different security policies.
At the heart of these networking security functions, is the firewall policies.Firewall

policies control all traffic attempting to pass through the FortiGate unit, between FortiGate
interfaces, zones, and VLAN subinterfaces. They are instructions the FortiGate unit uses to
decide connection acceptance and packet processing for traffic attempting to pass through.
When the firewall receives a connection packet, it analyzes the packet’s source address,
destination address, and service (by port number), and attempts to locate a firewall policy
matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow when
it receives matching packets. Some instructions are required, such as whether to drop or accept
and process the packets, while other instructions, such as logging and authentication, are
optional. It is through these policies that the FortiGate unit grants or denies the packets and
information in or out of the network, who gets priority (bandwidth) over other users, and when
the packets can come through.
This chapter describes the features of the FortiGate firewall that help to protect your network,
and the firewall policies that are the instructions for the FortiGate unit.
Firewall features
The FortiGate unit provides unified threat management by including a rich feature set
to protect your network from unwanted attacks. This section provides an overview of what the
FortiGate unit can protect against. Each of these elements are configured and added to firewall
policies as a means of instructing the FortiGate unit what to do when encountering an security
threat.
Antivirus
Antivirus is a group of features that are designed to prevent unwanted and
potentially malicious files from entering your network. These features all work in different ways,
whether by checking for a file size, name, type, or the presence of a virus or grayware
signature.
The antivirus scanning routines used are designed to share access to the network traffic. This
way, each individual feature does not have to examine the network traffic as a separate
operation, reducing overhead significantly. For example, if you enable file filtering and virus
scanning, the resources used to complete these tasks are only slightly greater than enabling
virus scanning alone. Two features do not require twice the resources.
Antivirus scanning function includes various modules and engines that perform separate tasks.
The FortiGate unit performs antivirus processing in the following order:
•File size
•File pattern
•File type
•Virus scan
•Grayware
•Heuristics
If a file fails any of the tasks of the antivirus scan, no further scans are performed. For example,
if the file “fakefile.exe” is recognized as a blocked pattern, the FortiGate unit will send the
recipient a message informing them that the original message had a virus, and the file will be
deleted or quarantined. The virus scan, grayware, heuristics, and file type scans will not be
performed as the file is already been determined to be a threat and has been dealt with.
Web Filtering
Web filtering is a means of controlling the content that an Internet user is able to
view. With the popularity of web applications, the need to monitor and control web access is
becoming a key component of Secure Content Management systems that employ antivirus, web
filtering, and messaging security.
As the number and severity of threats increase on the web, the risk potential is increasing within
a company's network as well. Casual non-business related web surfing has caused many
businesses countless hours of legal litigation as hostile environments have been created by
employees who download and view offensive content.web-based attacks and threats are also
becoming increasingly sophisticated. New threats and web-based applications that are causing
additional problems for corporations include:
•Spyware/Grayware
•Phishing
•Instant Messaging
•Peer-to-Peer File Sharing
•Streaming Media
•Blended Network Attacks
Data Leak Prevention
The FortiGate data leak prevention (DLP) system allows you to prevent sensitive
data from leaving your network. When you define sensitive data patterns, data matching these
patterns will be blocked, logged, and archived, or any combination of these three actions, when
passing through the FortiGate unit. You configure the DLP system by creating individual rules,
combining the rules into DLP sensors, and then assigning a sensor to a firewall policy.
Although the primary use of the DLP feature is to stop sensitive data from leaving
your network, it can also be used to prevent unwanted data from entering your network and to
archive some or all of the content passing through the FortiGate unit.
DLP examines network traffic for data patterns you specify. You define whatever
patterns you want the FortiGate unit to look for in network traffic. The DLP feature is broken
down into a number of parts.
Application control
Using the application control UTM feature, your FortiGate unit can detect and take
action against network traffic depending on the application generating the traffic. 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.
The FortiGate unit can recognize the network traffic generated by a large number
of applications. You can create application control lists 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 lists to the firewall policies that control the network traffic you need
to monitor.
Spyware/Grayware
Spyware is also known as Grayware. Spyware is a type of computer program

that attaches itself to a user’s operating system. It does this without the user’s consent or
knowledge. It usually ends up on a computer because of something the user does such as
clicking on a button in a popup window. Spyware can do a number of things such as track the
user’s Internet usage, cause unwanted popup windows, and even direct the user to a host web
site. It is estimated that 80% of all personal computers are infected with spyware. For further
information, visit the FortiGuard Center.
Some of the most common ways of grayware infection include:

• Downloading shareware, freeware or other forms of file-sharing services
•Clicking on pop-up advertising
Visiting legitimate web sites infected with grayware
Phishing
Phishing is the term used to describe social engineering attacks that use web technology to
trick users into revealing personal or financial information. Phishing attacks use web sites and
emails that claim to be from legitimate financial institutions to trick the viewer into believing that
they are legitimate. Although phishing is initiated by spam email, getting the user to access the
attacker’s web site is always the next step.
Pharming
Pharming is a next generation threat that is designed to identify, and extract financial,
and other key pieces of information for identity theft. Pharming is much more dangerous than
Phishing because it is designed to be completely hidden from the end user. Unlike phishing
attacks that send out spam email requiring the user to click to a fraudulent URL, Pharming
attacks require no action from the user outside of their regular web surfing activities. Pharming
attacks succeed by redirecting users from legitimate web sites to similar fraudulent web sites
that have been created to look and feel like the authentic web site.
Instant messaging
Instant Messaging presents a number of problems. Instant Messaging can be used to infect
computers with spyware and viruses. Phishing attacks can be made using Instant Messaging.
There is also a danger that employees may use instant messaging to release sensitive
information to an outsider.
Peer-to-peer
Peer-to-Peer networks are used for file sharing. Such files may contain viruses. Peer-to-Peer
applications take up valuable network resources and lower employee productivity but also has
legal implications with the downloading of copyrighted material. Peer-to-Peer file sharing and
applications can also be used to expose company secrets.
Streaming media
Streaming media is a method of delivering multimedia, usually in the form of audio or video to
Internet users. The viewing of streaming media has increased greatly in the past few years.
The problem with this is the way it impacts legitimate business.
Blended network attacks

Blended network threats are rising and the sophistication of network threats is increasing with
each new attack. Attackers are learning from each previous successful attack and are
enhancing and updating attack code to become more dangerous and fast spreading. Blended
attacks use a combination of methods to spread and cause damage. Using virus or network
worm techniques combined with known system vulnerabilities, blended threats can quickly
spread through email, web sites, and Trojan applications. Blended attacks can be designed to
perform different types of attacks - from disrupting network services to destroying or stealing
information to installing stealthy back door applications to grant remote access.
For more information on FortiGate web filter processes, features and configuration,
see the UTM chapter.
Antispam/Email Filter
The FortiGate unit performs email filtering (formerly called antispam) for IMAP, POP3,
and SMTP email. Email filtering includes both spam filtering and filtering for any words or files
you want to disallow in email messages. If your FortiGate unit supports SSL content scanning
and inspection you can also configure spam filtering for IMAPS, POP3S, and SMTPS email
traffic.
You can configure the FortiGate unit to manage unsolicited commercial email by detecting and
identifying spam messages from known or suspected spam servers. The FortiGuard Antispam
Service uses both a sender IP reputation database and a spam signature database, along with
sophisticated spam filtering tools, to detect and block a wide range of spam messages. Using
FortiGuard Antispam protection profile settings you can enable IP address checking, URL
checking, E-mail checksum check, and Spam submission. Updates to the IP reputation and
spam signature databases are provided continuously via the global FortiGuard distribution
network.
From the FortiGuard Antispam Service page in the FortiGuard center you can use IP and
signature lookup to check whether an IP address is blacklisted in the FortiGuard antispam IP
reputation database, or whether a URL or email address is in the signature database.
Email filter techniques

The FortiGate unit has a number of techniques available to help detect spam. Some use the
FortiGuard AntiSpam service, requiring a subscription. The remainder use your DNS servers,
or lists you must maintain.
The FortiGate unit queries the FortiGuard Antispam service to determine if the IP address of
the client delivering the email is blacklisted. A match will have the FortiGate unit treat delivered
messages as spam. If enabled, the FortiGate unit will check all the IP addresses in the header
of SMTP email against the FortiGuard Antispam service.
The FortiGate unit queries the FortiGuard Antispam service to determine if any URL in
the message body is associated with spam. If any URL is blacklisted, the FortiGate unit
determines that the email message is spam.
The FortiGate unit sends a hash of an email to the FortiGuard Antispam server
which compares the hash to hashes of known spam messages stored in the FortiGuard
Antispam database. If the hash results match, the email is flagged as spam.
The FortiGate unit compares the IP address of the client delivering the email to the addresses
in the IP address black/white list specified in the protection profile. If a match is found, the
FortiGate unit will take the action configured for the matching black/white list entry against all
delivered email.
The FortiGate unit takes the domain name specified by the client in the HELO greeting sent
when starting the SMTP session, and does a DNS lookup to determine if the domain exists. If
the lookup fails, the FortiGate unit determines that any messages delivered during the SMTP
session are spam.
The FortiGate unit compares the sender email address, as shown in the message envelope
MAIL FROM, to the addresses in the email address black/white list specified in the protection
profile. If a match is found, the FortiGate unit will take the action configured for the matching
black/white list entry.
The FortiGate unit performs a DNS lookup on the reply-to domain to see if there is an A or MX
record. If no such record exists, the message is treated as spam.
The FortiGate unit will block email messages based on matching the content of the message
with the words or patterns in the selected spam filter banned word list.
For more information on FortiGate antispam processes, features and configuration,
see the UTM chapter.
Intrusion Protection
The FortiGate Intrusion Protection system combines signature detection and prevention with
low latency and excellent reliability. With intrusion Protection, you can create multiple IPS
sensors, each containing a complete configuration based on signatures. Then, you can apply
any IPS sensor to each protection profile. The FortiGate intrusion protection system protects
your network from outside attacks. Your FortiGate unit has two techniques to deal with these
attacks.
Anomaly-based defense is used when network traffic itself is used as a weapon. A host can be
flooded with far more traffic than it can handle, making the host inaccessible. The most
common example is the denial of service attack, in which an attacker directs a large number of
computers to attempt normal access of the target system. If enough access attempts are
made, the target is overwhelmed and unable to service genuine users. The attacker does not
gain access to the target system, but it is not accessible to anyone else. The FortiGate unit
DoS feature will block traffic over a certain threshold from the attacker, allowing connections
from other legitimate users.
Signature-based defense is used against known attacks or vulnerability exploits. These often
involve an attacker attempting to gain access to your network. The attacker must communicate
with the host in an attempt to gain access, and this communication will include particular
commands or sequences of commands and variables. The IPS signatures include these
command sequences, allowing the FortiGate unit to detect and stop the attack.
The basis of signature-based intrusion protection are the IPS signatures, themselves. Every
attack can be reduced to a particular string of commands or a sequence of commands and
variables. Signatures include this information so your FortiGate unit knows what to look for in
network traffic.
Signatures also include characteristics about the attack it describes. These

characteristics include the network protocol in which it will appear, the vulnerable operating
system, and the vulnerable application.
Before examining network traffic for attacks, the FortiGate will identify each protocol appearing
in the traffic. Attacks are protocol-specific so your FortiGate unit conserves resources by
looking for attacks only in the protocols used to transmit them. For example, the FortiGate unit
will only examine HTTP traffic for the presence of a signature describing an HTTP attack.
Once the protocol decoders separate the network traffic by protocol, the IPS engine examines
the network traffic for the attack signatures.
The IPS engine does not examine network traffic for all signatures, however. You must first
create an IPS sensor and specify which signatures are included. You do not have to choose
each signature you want to include individually, however. Instead, filters are used to define the
included signatures.
IPS sensors contain one or more IPS filters. A filter is simply a collection of signature attributes
you specify. The signatures that have all of the attributes specified in a filter are included in the
IPS signature.
For example, if your FortiGate unit protects a Linux server running the Apache web
server software, you could create a new filter to protect it. Set OS to Linux,
and Application to Apache and the filter will include only the signatures applicable to both Linux
and Apache. If you wanted to scan for all the Linux signatures and all the Apache signatures,
you would create two filters, one for each.
For more information on FortiGate IPS processes, features and configuration, see
the UTM chapter.
Traffic Shaping
Traffic shaping, when included in a firewall policy, controls the bandwidth available to, and sets
the priority of the traffic processed by, the policy. Traffic shaping makes it possible to control
which policies have the highest priority when large amounts of data are moving through the
FortiGate unit. For example, the policy for the corporate web server might be given higher
priority than the policies for most employees’ computers. An employee who needs extra high
speed Internet access could have a special outgoing policy set up with higher bandwidth.
Traffic shaping is available for firewall policies whose Action is ACCEPT, IPSEC, or SSLVPN. It
is also available for all supported services, including H.323, TCP, UDP, ICMP, and ESP
Traffic shaping cannot increase the total amount of bandwidth available, but you can use it to
improve the quality of bandwidth-intensive and sensitive traffic.
The bandwidth available for traffic set in a traffic shaper is used to control data sessions for
traffic in both directions. For example, if guaranteed bandwidth is applied to an internal and an
external FTP policy, and a user on an internal network uses FTP to put and get files, both the
put and get sessions share the bandwidth available to the traffic controlled by the policy.
Once included in a firewall policy, the guaranteed and maximum bandwidth is the
total bandwidth available to all traffic controlled by the policy. If multiple users start multiple
communications session using the same policy, all of these communications sessions must
share from the bandwidth available for the policy.
However, bandwidth availability is not shared between multiple instances of using the same
service if these multiple instances are controlled by different policies. For example, you can
create one FTP policy to limit the amount of bandwidth available for FTP for one network
address and create another FTP policy with a different bandwidth availability for another
network address
Traffic shaping attempts to “normalize” traffic peaks/bursts to prioritize certain flows

over others. But there is a physical limitation to the amount of data which can be buffered and
to the length of time. Once these thresholds have been surpassed, frames and packets will be
dropped, and sessions will be affected in other ways. For example, incorrect traffic shaping
configurations may actually further degrade certain network flows, since the excessive
discarding of packets can create additional overhead at the upper layers that may be
attempting to recover from these errors.
A basic traffic shaping approach is to prioritize certain traffic flows over other traffic
whose potential discarding is less advantageous. This would mean that you accept sacrificing
certain performance and stability on low-priority traffic, in order to increase or guarantee
performance and stability to high-priority traffic.
If, for example, you are applying bandwidth limitations to certain flows, you must accept the fact
that these sessions can be limited and therefore negatively impacted. Traffic shaping applied to
a firewall policy is enforced for traffic which may flow in either direction. Therefore a session
which may be set up by an internal host to an external one, through an Internal-to-External
policy, will have traffic shaping applied even if the data stream flows external to internal. One
example may be an FTP “get” or a SMTP server connecting to an external one, in order to
retrieve email.
Note that traffic shaping is effective for normal IP traffic at normal traffic rates. Traffic shaping is
not effective during periods when traffic exceeds the capacity of the FortiGate unit. Since
packets must be received by the FortiGate unit before they are subject to traffic shaping, if the
FortiGate unit cannot process all of the traffic it receives, then dropped packets, delays, and
latency are likely to occur.
For more information on traffic shaping, see the Traffic Shaping chapter.
NAT vs. Transparent Mode

The FortiGate unit can run in two modes: Network Address Translation (NAT) mode
and Transparent mode. Generally speaking, both modes function the same, with some minor
differences in feature availability due to the nature of the mode. With both modes, however,
firewall policies define how traffic moves, or is prevented, from moving within the local network
or to an external network or the Internet.
NAT mode
In NAT mode, the FortiGate unit is visible to the network that it is connected to. All of
its interfaces are on different subnets. Each interface that is connected to a network must be
configured with an IP address that is valid for that subnetwork.
You would typically use NAT mode when the FortiGate unit is deployed as a gateway between
private and public networks. In its default NAT mode configuration, the FortiGate unit functions
as a firewall. Firewall policies control communications through the FortiGate unit to both the
Internet and between internal networks. In NAT mode, the FortiGate unit performs network
address translation before IP packets are sent to the destination network. For example, a
company has a FortiGate unit as their interface to the Internet. The FortiGate unit also acts as
a router to multiple sub-networks within the company.
Figure 19: FortiGate unit in NAT mode

In this situation, as shown in Figure 19, the FortiGate unit is set to NAT mode. Using this mode,
the FortiGate unit can have a designated port for the Internet, in this example, wan1 with an
address of 172.20.120.129, which is the public IP address. The internal network segments are
behind the FortiGate unit and invisible to the public access, for example port 2 with an address
of 10.10.10.1. The FortiGate unit translates IP addresses passing through it to route the traffic
to the correct subnet or the Internet.
How address translation works

In NAT mode, firewall policies perform the address translation between the internal
and external interfaces. When a user accesses a web site, for example, the web site only
knows the request by the external interface of the FortiGate unit, in this example, wan1.
For example, a user surfs to a web server (IP address 172.50.20.20). The user’s PC has an IP
address of 10.10.10.2 on the Internal interface. The FortiGate unit receives the request from
the user to go to the web server. The external interface for the FortiGate unit to send and
receive information is want 1 (172.20.120.129). The FortiGate unit looks at the firewall policies
to determine where the request should go, in this case, out the external interface.
The FortiGate unit changes the packet information of the return address to its
external interface, while keeping track of the originating user request, and the originating PC
address. Once modified, the FortiGate unit sends the packet information to the web server.
Figure 20:
Sender’s IP internal address translated to the FortiGate unit’s external address
When the web server sends the response, it sends it to what it believes to be the originating
address, the FortiGate wan1 address, 172.20.120.129. When the FortiGate unit receives the
information, it determines where it should go by looking at its session information. Using
firewall policies, it determines that the information should be going to the originating user at
10.10.10.2. The FortiGate changes the destination IP to the correct user and delivers the
packet.
Figure 21:
Web server sends to FortiGate external address and translated to internal address
Throughout this exchange, which occurs in nanoseconds, and because of network address
translation, the web server does not know that the originating address is really 10.10.10.2, but
172.20.120.129.
Central NAT table

The central NAT table enables you to define, and control with more granularity, the address
translation performed by the FortiGate unit. With the NAT table, you can define the rules which
dictate the source address or address group and which IP pool the destination address uses.
The NAT table also functions in the same way as the firewall policy table. That is, the FortiGate
unit reads the NAT rules in a top-down methodology, 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. The NAT policies can be rearranged within the policy list as
well, the same way as firewall policies.
NAT policies are applied to network traffic after a firewall policy. For more information
on central NAT tables, see “Central NAT table”.
Transparent mode
In Transparent mode, the FortiGate unit is invisible to the network. All of its interfaces are on
the same subnet and share the same IP address. You only have to configure a management IP
address so that you can make configuration changes.
You would typically use the FortiGate unit in Transparent mode on a private network behind an
existing firewall or behind a router. In Transparent mode, the FortiGate unit also functions as a
firewall. Firewall policies control communications through the FortiGate unit to the Internet and
internal network. No traffic can pass through the FortiGate unit until you add firewall policies.
For example, the company has a router or other firewall in place. The network is simple enough
that all users are on the same internal network. They need the FortiGate unit to perform
antispam, antivirus and intrusion protection and similar traffic scanning. In this situation, as
shown in Figure 22, the FortiGate unit is set to transparent mode. The traffic passing through
the FortiGate unit does not change the addressing from the router to the internal network.
Firewall policies and protection profiles define the type of scanning the FortiGate unit performs
on traffic entering the network.
Figure 22: FortiGate unit in transparent mode
By default when shipped, the FortiGate unit operates in NAT mode. To use the FortiGate unit in
Transparent mode, you need to switch its mode. When switched to a different mode, the
FortiGate unit does not need to be restarted; the change is automatic.
In the following example, the steps change the FortiGate unit to Transparent mode with an IP
of 10.11.101.10, netmask of 255.255.255.0 and a default gateway of 10.11.101.1
To enable Transparent mode - web-based manager
To enable Transparent mode - CLI
config system settings
set opmode transparent
set manageip 10.11.101.10 255.255.255.0
set gateway 10.11.101.1
end
For information on unique Transparent mode firewall configurations, see “Advanced firewall
concepts”.
Note: This guide and its examples are constructed with the FortiGate unit
running in NAT mode, unless otherwise noted.
Operating mode differences
The FortiGate unit, running in either NAT or Transparent mode have essentially the
same feature set. Due to the differences in the modes, however, some features are not
available in Transparent mode. The list below outlines the key features not available in
Transparent mode:
•Network > DNS Databases

•DHCP
•Router (basic routing is available by going to Network > Routing Table)
•Virtual IP
•Load Balance
•IPSec Concentrator (Transparent mode supports policy-based configurations)
•SSL VPN
WCCP cache engine
Life of a Packet
Directed by firewall policies, a FortiGate unit screens network traffic from the IP layer
up through the application layer of the TCP/IP stack. This chapter provides a general,
high-level description of what happens to a packet as it travels through a FortiGate security
system.
The FortiGate unit performs three types of security inspection:

•stateful inspection, that provides individual packet-based security within a basic session state
flow-based inspection, that buffers packets and uses pattern matching to identify security
•threats
proxy-based inspection, that reconstructs content passing through the FortiGate unit and
•inspects the content for security threats.
Each inspection component plays a role in the processing of a packet as it traverses
the FortiGate unit en route to its destination. To understand these inspections is the first step
to understanding the flow of the packet.
Stateful inspection
With stateful inspection, the FortiGate unit looks at the first packet of a session to make
a security decision. Common fields inspected include TCP SYN and FIN flags to identity the
start and end of a session, the source/destination IP, source/destination port and protocol.
Other checks are also performed on the packed payload and sequence numbers to verify it as
a valid communication and that the data is not corrupted or poorly formed.
The FortiGate unit makes the decision to drop, pass or log a session based on what is found
in the first packet of the session. If the FortiGate unit decides to drop or block the first packet
of a session, then all subsequent packets in the same session are also dropped or blocked
without being inspected. If the FortiGate unit accepts the first packet of a session, then all
subsequent packets in the same session are also accepted without being inspected.
•Figure 23: Stateful inspection of packets through the FortiGate unit

Flow inspection
With flow inspection, the FortiGate unit samples multiple packets in a session and
multiple sessions, and uses a pattern matching engine to determine the kind of activity that the
session is performing and to identify possible attacks or viruses. For example, if application
control is operating, flow inspection can sample network traffic and identify the application that
is generating the activity. Flow-based antivirus can sample network traffic and determine if the
content of the traffic contains a virus, IPS can sample network traffic and determine if the
traffic constitutes an attack. The security inspection occurs as the data is passing from its
source to its destination. Flow inspection identifies and blocks security threats in real time as
they are identified.
Figure 24: Flow inspection of packets through the FortiGate unit
Flow-based inspections typically require less processing than proxy-based inspection,

and therefore flow-based antivirus performance can be better than proxy-based antivirus
performance. However, some threats can only be detected when a complete copy of the
payload is obtained so, proxy-based inspection tends to be more accurate and complete than
flow-based inspection.
Proxy inspection
With flow inspection, the FortiGate unit will pass all the packets between the source
and destination, and keeps a copy of the packets in its memory. It then uses a reconstruction
engine to build the content of the original traffic. The security inspection occurs after the data
has passed from its source to its destination.
Proxy inspection examines the content contained a content protocol session for
security threats. Content protocols include the HTTP, FTP, and email protocols. Security
threats can be found in files and other content downloaded using these protocols. With proxy
inspection, the FortiGate unit downloads the entire payload of a content protocol sessions and
re-constructs it. For example, proxy inspection can reconstruct an email message and its
attachments. After a satisfactory inspection the FortiGate unit passes the content on to the
client. If proxy inspection detects a security threat in the content, the content is removed from
the communication stream before the it reaches its destination. For example, if proxy
inspection detects a virus in an email attachment, the attachment is removed from the email
message before its sent to the client. Proxy inspection is the most thorough inspection of all,
although it requires more processing power, and this may result in lower performance.
If you enable ICAP in a firewall policy, HTTP traffic intercepted by the policy is transferred to
the ICAP servers in the ICAP profile added to the policy. The FortiGate unit is the surrogate, or
“middle-man”, and carries the ICAP responses from the ICAP server to the ICAP client; the
ICAP client then responds back, and the FortiGate unit determines the action that should be
taken with these ICAP responses and requests.
Figure 25: Proxy inspection of packets through the FortiGate unit
FortiOS functions and security layers

Within these security inspection types, FortiOS functions map to different inspections.
The table below outlines when actions are taken as a packet progresses through its life within
a FortiGate unit.
Table 2: FortiOS security functions and security layers
Security Function Stateful Flow Proxy
Firewall 
IPsec VPN 
Traffic Shaping 
User Authentication 
Management Traffic 
SSL VPN 
Intrusion Prevention 
Flow-based Antivirus 
Application Control 
VoIP inspection 
Proxy Antivirus 
Email Filtering 
Web Filtering (Antispam) 
Data Leak Prevention 
Packet flow
After the FortiGate unit’s external interface receives a packet, the packet proceeds through a
number of steps on its way to the internal interface, traversing each of the inspection types,
depending on the firewall policy and UTM profile configuration. The diagram in Figure 26 is a
high level view of the packet’s journey.
The description following is a high-level description of these steps as a packet enters
the FortiGate unit towards its destination on the internal network. Similar steps occur for
outbound traffic.
Packet inspection (Ingress)

In the diagram in Figure 26, in the first set of steps (ingress), a number of header checks take
place to ensure the packet is valid and contains the necessary information to reach its
destination. This includes:
Packet verification - during the IP integrity stage, verification is performed to ensure that the
•layer 4 protocol header is the correct length. If not, the packet is dropped.
•Session creation - the FortiGate unit attempts to create a session for the incoming data
IP stack validation for routing - the firewall performs IP header length, version and checksum
•verifications in preparation for routing the packet.
•Verifications of IP options - the FortiGate unit validates the rouging information
Figure 26: Packet flow
Interface
Ingress packets are received by a FortiGate interface.The packet enters the system, and the
interface network device driver passes the packet to the Denial of Service (DoS) sensors, if
enabled, to determine whether this is a valid information request or not.
DoS sensor
DoS scans are handled very early in the life of the packet to determine whether the traffic is
valid or port of a DoS attack. Unlike signature-based IPS which inspects all the packets within
a certain traffic flow, the DoS module inspects all traffic flows but only tracks packets that can
be used for DoS attacks (for example TCP SYN packets), to ensure they are within the
permitted parameters. Suspected DoS attacks are blocked, other packets are allowed.
IP integrity header checking

The FortiGate unit reads the packet headers to verify if the packet is a valid TCP,
UDP, ICMP,SCTP, or GRE packet. The only verification that is done at this step to ensure that
the protocol header is the correct length. If it is, the packet is allowed to carry on to the next
step. If not, the packet is dropped.
IPsec
If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. The IPsec
engine applies the correct encryption keys to the IPsec packet and sends the unencrypted
packet to the next step. IPsec is bypassed when for non-IPsec traffic and for IPsec traffic that
cannot be decrypted by the FortiGate unit.
Destination NAT (DNAT)

The FortiGate unit checks the NAT table and determines the destination IP address for
the traffic. This step determines whether a route to the destination address actually exists.
For example, if a user’s browser on the internal network at IP address 192.168.1.1 visited the
web site www.example.com using NAT, after passing through the FortiGate unit the source IP
address becomes NATed to the FortiGate unit external interface IP address. The destination
address of the reply back from www.example.com is the IP address of the FortiGate unit
internal interface. For this reply packet to be returned to the user, the destination IP address
must be destination NATed to 192.168.1.1.
Routing
The routing step determines the outgoing interface to be used by the packet as it leaves the
FortiGate unit. In the previous step, the FortiGate unit determined the real destination address,
so it can now refer to its routing table and decide where the packet must go next.
Routing also distinguishes between local traffic and forwarded traffic and selects the source
and destination interfaces used by the firewall policy engine to accept or deny the packet.
Policy lookup
The policy look up is where the FortiGate unit reviews the list of firewall policies which govern
the flow of network traffic, from the first entry to the last, to find a match for the source and
destination IP addresses and port numbers. The decision to accept or deny a packet, after
being verified as a valid request within the stateful inspection, occurs here. A denied packet is
discarded. An accepted packet will have further actions taken. If IPS is enabled, the packet will
go to Flow-based inspection engine, otherwise it will go to the Proxy-based inspection engine.
If no other UTM options are enabled, then the session was only subject to stateful inspection.
If the action is accept, the packet will go to Source NAT to be ready to leave the FortiGate unit.
Session tracking
Part of the stateful inspection engine, session tracking maintains session tables that maintain
information about sessions that the stateful inspection module uses for maintaining sessions,
NAT, and other session related functions.
User authentication
User authentication added to firewall policies is handled by the stateful inspection
engine, which is why Firewall authentication is based on IP address. Authentication takes
place after policy lookup selects a firewall policy that includes authentication. This is also
known as identify-based policies. Authentication also takes place before UTM features are
applied to the packet.
Management traffic
This local traffic is delivered to the FortiGate unit TCP/IP stack and includes communication
with the web-based manager, the CLI, the FortiGuard network, log messages sent to
FortiAnalyzer or a remote syslog server, and so on. Management traffic is processed by
applications such as the web server which displays the FortiOS web-based manager, the SSH
server for the CLI or the FortiGuard server to handle local FortiGuard database updates or
FortiGuard Web Filtering URL lookups.
SSL VPN traffic

For local SSL VPN traffic, the internal packets are decrypted and are routed to a
special interface. This interface is typically called ssl.root for decryption. Once decrypted, the
packets goes to policy lookup.
Session helpers
Some protocols include information in the packet body (or payload) that must be analyzed to
successfully process sessions for this protocol. For example, the SIP VoIP protocol uses TCP
control packets with a standard destination port to set up SIP calls. To successfully process
SIP VoIP calls, FortiOS must be able to extract information from the body of the SIP packet
and use this information to allow the voice-carrying packets through the firewall.
FortiOS uses session helpers to analyze the data in the packet bodies of some protocols and
adjust the firewall to allow those protocols to send packets through the firewall.
Flow-based inspection engine

Flow-based inspection is responsible for IPS, application control, flow-based
antivirus scanning and VoIP inspection. Packets are sent to flow-based inspection if the
firewall policy that accepts the packets includes one or more of these UTM features.
Note: Flow-based antivirus scanning is only available on some FortiGate

models.
Once the packet has passed the flow-based engine, it can be sent to the proxy
inspection engine or egress.
Proxy-based inspection engine

The proxy inspection engine is responsible for carrying out antivirus protection, email filtering
(antispam), web filtering and data leak prevention. The proxy engine will process multiple
packets to generate content before it is able to make a decision for a specific packet.
IPsec
If the packet is transmitted through an IPsec tunnel, it is at this stage the encryption
and required encapsulation is performed. For non-IPsec traffic (TCP/UDP) this step is
bypassed.
Source NAT (SNAT)
When preparing the packet to leave the FortiGate unit, it needs to NAT the source address of
the packet to the external interface IP address of the FortiGate unit. For example, a packet
from a user at 192.168.1.1 accessing www.example.com is now using a valid external IP
address as its source address.
Routing
The final routing step determines the outgoing interface to be used by the packet as it leaves
the FortiGate unit.
Egress
Upon completion of the scanning at the IP level, the packet exits the FortiGate unit.
Example 1: client/server connection

The following example illustrates the flow of a packet of a client/web server connection with
authentication and FortiGuard URL and antivirus filtering.
This example includes the following steps:
Initiating connection from client to web server

1Client sends packet to web server.
2Packet intercepted by FortiGate unit interface.
2.1 Link level CRC and packet size checking. If the size is correct, the packet continues,
otherwise it is dropped.
DoS sensor - checks are done to ensure the sender is valid and not attempting a denial of
3service attack.
4IP integrity header checking, verifying the IP header length, version and checksums.
5Next hop route
6Policy lookup
7User authentication
8Proxy inspection
8.1 Web Filtering
8.2 FortiGuard Web Filtering URL lookup
8.3 Antivirus scanning
9 Source NAT
10Routing
11Interface transmission to network
12Packet forwarded to web server
Response from web server
1Web Server sends response packet to client.
2Packet intercepted by FortiGate unit interface
2.1 Link level CRC and packet size checking.
3IP integrity header checking.
4DoS sensor.
5Proxy inspection
5.1 Antivirus scanning.
6Source NAT.
7Stateful Policy Engine
7.1 Session Tracking
8Next hop route
10Packet returns to client
Figure 27: Client/server connection
Example 2: Routing table update

1FortiGate unit receives routing update packet
3service attack.
5Stateful policy engine
5.1 Management traffic (local traffic)
6Routing module
6.1 Update routing table
Figure 28: Routing table update
Example 3: Dialup IPsec with application control

1FortiGate unit receives IPsec packet from Internet
3service attack.
5IPsec
5.1 Determines that packet matched IPsec phase 1 configuration
5.2 Unencrypted packet
6Next hop route
7.1 Session tracking
8Flow inspection engine
8.1 IPS
8.2 Application control
9 Source NAT
10Routing
12Packet forwarded to internal server
Response from server
1Server sends response packet
2.1 Link level CRC and packet size checking
3IP integrity header checking.
4DoS sensor
5Flow inspection engine
5.1 IPS
5.2 Application control
6.1 Session tracking
7Next hop route
8IPsec
8.1 Encrypts packet
9 Routing
11Encrypted Packet returns to internet
Figure 29: Dialup IPsec with application control
Firewall components
The FortiGate unit’s primary purpose is to act as a firewall to protect your networks
from unwanted attacks and to control the flow of network traffic. The FortiGate unit does this
through the use of firewall policies. The policies you create review the traffic passing through
the device to determine if the traffic is allowed into or out of the network, if it is normal network
traffic or encrypted VPN or SSL VPN traffic, where it is going and how it should be handled.
Every firewall policy uses similar components. This section briefly describes
these components.
The following topics are included in this section:
•Interfaces
•Addressing
•Ports
•Services
•Schedules
•UTM profiles
Interfaces
Interfaces, both physical and virtual, enable traffic to flow to and from the internal network, and
the Internet and between internal networks. The FortiGate unit has a number of options for
setting up interfaces and groupings of subnetworks that can scale to a company’s growing
requirements.
Physical
FortiGate units have a number of physical ports where you connect Ethernet or optical cables.
Depending on the model, they can have anywhere from four to 40 physical ports. Some units
have a grouping of ports labelled as internal, providing a built-in switch functionality.
In FortiOS, the port names, as labeled on the FortiGate unit, appear in the web-
based manager in the Unit Operation the Dashboard. They also appear when you are
configuring the interfaces, by going to System > Network > Interface. As shown below, the
FortiGate-60C has eight interfaces
Figure 30: FortiGate-60C physical interfaces
Figure 31: FortiGate-60C interfaces on the Dashboard
Figure 32: Configuring the FortiGate-60C ports
Normally the internal interface is configured as a single interface shared by all

physical interface connections - a switch. The switch mode feature has two states - switch
mode and interface mode. Switch mode is the default mode with only one interface and one
address for the entire internal switch. Interface mode allows you to configure each of the
internal switch physical interface connections separately. This enables you to assign different
subnets and netmasks to each of the internal physical interface connections.
The larger FortiGate units can also include Advanced Mezzanine Cards (AMC), which
can provide additional interfaces (ethernet or optical), with throughput enhancements for more
efficient handling of specialized traffic. These interfaces appear in FortiOS as port amc/sw1,
amc/sw2 and so on. In the following illustration, the FortiGate
FortiGate-3810A
3810A has three AMC
A cards
installed: two single-width
width (amc/sw1, amc/sw2) and one double
double-width
width (amc/dw).
Figure 33: FortiGate-3810A

3810A AMC card port naming
Administrative access
Interfaces, especially the public
public-facing
facing ports can be potentially accessed by those who you
may not want access to the FortiGate unit. When setting up the FortiGate unit, you can set the
type of protocol an administrator must use to access the FortiGate unit. The options include:
•HTTPS
•HTTP
•SSH
•TELNET
•PING
•SNMP
You can select as many,
any, or as few, even none, that are accessible by an administrator.
Example
This example adds an IPv4 address 172.20.120.100 to the WAN1 interface as well as
the administrative access to HTTPS and SSH. As a good practice, set the administrative
access whenn you are setting the IP address for the port.
To add an IP address on the WAN1 interface - web-based manager
To create IP address on the WAN1 interface - CLI
config system interface
edit wan1
set ip 172.20.120.100/24
set allowaccess https ssh
end
Note: When adding to, or removing a protocol, you must type the entire
list again. For example, if you have an access list of HTTPS and SSH,
and you want to add PING, typing:
set allowaccess ping
...only PING will be set. In this case, you must type...
set allowaccess https ssh ping
Wireless
A wireless interface is similar to a physical interface only it does not include a

physical connection. The FortiWiFi units enables you to add multiple wireless interfaces that
can be available at the same time (the FortiWiFi-30B can only have one wireless interface).
On FortiWiFi units, you can configure the device to be either an access point, or a wireless
client. As an access point, the FortiWiFi unit can have up to four separate SSIDs, each on
their own subnet for wireless access. In client mode, the FortiWiFi only has one SSID, and is
used as a receiver, to enable remote users to connect to the existing network using wireless
protocols.
Wireless interfaces also require additional security measures to ensure the signal does not get
hijacked and data tampered or stolen.
Virtual domains
Virtual domains (VDOMs) are a method of dividing a FortiGate unit into two or more
virtual units that function as multiple independent units. A single FortiGate unit is then flexible
enough to serve multiple departments of an organization, separate organizations, or to act as
the basis for a service provider’s managed security service.
Note: Some smaller FortiGate units do not support virtual domains.
VDOMs provide separate security domains that allow separate zones, user
authentication, firewall policies, routing, and VPN configurations. By default, each FortiGate
unit has a VDOM named root. This VDOM includes all of the FortiGate physical interfaces,
modem, VLAN subinterfaces, zones, firewall policies, routing settings, and VPN settings.
When a packet enters a VDOM, it is confined to that VDOM. In a VDOM, you can
create firewall policies for connections between Virtual LAN (VLAN) subinterfaces or zones in
the VDOM. Packets do not cross the virtual domain border internally. To travel between
VDOMs, a packet must pass through a firewall on a physical interface. The packet then arrives
at another VDOM on a different interface, but it must pass through another firewall before
entering the VDOM. Both VDOMs are on the same FortiGate unit. Inter-VDOMs change this
behavior in that they are internal interfaces; however their packets go through all the same
security measures as on physical interfaces.
Example
This example shows how to enable VDOMs on the FortiGate unit and the basic and create a
VDOM accounting on the DMZ2 port and assign an administrator to maintain the VDOM. First
enable Virtual Domains on the FortiGate unit. When you enable VDOMs, the FortiGate unit will
log you out.
To enable VDOMs - web-based manager

1Go to System > Dashboard > Status.
2In the System Information widget, select Enable for Virtual Domain.
The FortiGate unit logs you out. Once you log back in, you will notice that the menu structure
has changed. This reflects the global settings for all Virtual Domains.
To enable VDOMs - CLI

config system global
set vdom-admin enable
end
Next, add the VDOM called accounting.
To add a VDOM - web-based manager

1Go to System > VDOM > VDOM, and select Create New.
2Enter the VDOM name accounting.
3Select OK.
To add a VDOM - CLI
config vdom
edit <new_vdom_name>
end
With the Virtual Domain created, you can assign a physical interface to it, and assign it an IP
address.
To assign physical interface to the accounting Virtual Domain - web-based manager

1Go to System > Network > Interface.
2Select the DMZ2 port row and select Edit.
3For the Virtual Domain drop-down list, select accounting.
4Select the Addressing Mode of Manual.
5Enter the IP address for the port of 10.13.101.100/24.
6Set the Administrative Access to HTTPS and SSH.
7Select OK.
To assign physical interface to the accounting Virtual Domain - CLI
config global
edit dmz2
set vdom accounting
set ip 10.13.101.100/24
next
end
Virtual LANs
The term VLAN subinterface correctly implies the VLAN interface is not a complete interface
by itself. You add a VLAN subinterface to the physical interface that receives VLAN-tagged
packets. The physical interface can belong to a different VDOM than the VLAN, but it must be
connected to a network route that is configured for this VLAN. Without that route, the VLAN
will not be connected to the network, and VLAN traffic will not be able to access this
interface.The traffic on the VLAN is separate from any other traffic on the physical interface.
FortiGate unit interfaces cannot have overlapping IP addresses—the IP addresses of
all interfaces must be on different subnets. This rule applies to both physical interfaces and to
virtual interfaces such as VLAN subinterfaces. Each VLAN subinterface must be configured
with its own IP address and netmask. This rule helps prevent a broadcast storm or other
similar network problems.
Any FortiGate unit, with or without VDOMs enabled, can have a maximum of 255 interfaces in
Transparent operating mode. In NAT/Route operating mode, the number can range from 255
to 8192 interfaces per VDOM, depending on the FortiGate model. These numbers include
VLANs, other virtual interfaces, and physical interfaces. To have more than 255 interfaces
configured in Transparent operating mode, you need to configure multiple VDOMs with many
interfaces on each VDOM.
Example
This example shows how to add a VLAN, vlan_accounting on the FortiGate unit
internal interface with an IP address of 10.13.101.101.
To add a VLAN - web-based manager

1Go to System > Network > Interface and select Create New.
The Type is by default set to VLAN.
2Enter a name for the VLAN to vlan_accounting.
3Select the Internal interface.
4Enter the VLAN ID.
The VLAN ID is a number between 1 and 4094 that allow groups of IP addresses with the
same VLAN ID to be associated together.
6Enter the IP address for the port of 10.13.101.101/24.
7Set the Administrative Access to HTTPS and SSH.
8Select OK.
To add a VLAN - CLI

edit VLAN_1
set interface internal
set type vlan
set vlanid 100
set ip 10.13.101.101/24
next
end
Zones
Zones are a group of one or more FortiGate interfaces, both physical and virtual, that you can
apply firewall policies to control inbound and outbound traffic. Grouping interfaces and VLAN
subinterfaces into zones simplifies the creation of firewall policies where a number of network
segments can use the same policy settings and protection profiles. When you add a zone, you
select the names of the interfaces and VLAN subinterfaces to add to the zone. Each interface
still has its own address and routing is still done between interfaces, that is, routing is not
affected by zones. Firewall policies can also be created to control the flow of intra-zone traffic.
For example, in the illustration below, the network includes three separate groups of
users representing different entities on the company network. While each group has its own
set of port and VLANs, in each area, they can all use the same firewall policy and protection
profiles to access the Internet. Rather than the administrator making nine separate firewall
policies, he can add the required interfaces to a zone, and create three policies, making
administration simpler.
Figure 34: Network zones
You can configure policies for connections to and from a zone, but not between interfaces in a
zone. Using the above example, you can create a firewall policy to go between zone 1 and
zone 3, but not between WAN2 and WAN1, or WAN1 and DMZ1.
Example
This example explains how to set up a zone on the FortiGate unit to include the
Internal interface and a VLAN.
To create a zone - web-based manager
2Select the arrow on the Create New button and select Zone.
3Enter a zone name of Zone_1.
Select the Internal interface and the virtual LAN interface vlan_accounting from the previous
4section.
5Select OK.
To create a zone - CLI
config system zone
edit Zone_1
set interface internal VLAN_1
end
its with continuous IP addresses in a subnet, such as 192.168.1.[2-10], or 192.168.1.* to
indicate the complete range of hosts on that subnet. Valid IP Range formats include:
•x.x.x.x-x.x.x.x, such as 192.168.110.100-192.168.110.120
•x.x.x.[x-x], such as 192.168.110.[100-120]
•x.x.x.*, such as 192.168.110.*
When representing hosts by a FQDN, the domain name can be a subdomain, such
as mail.example.com. A single FQDN firewall address may be used to apply a firewall policy to
multiple hosts, as in load balancing and high availability (HA) configurations. FortiGate units
automatically resolve and maintain a record of all addresses to which the FQDN resolves.
Valid FQDN formats include:
<host_name>.<second_level_domain_name>.<top_level_domain_name>,
•such as mail.example.com
•<host_name>.<top_level_domain_name>
Caution: Be cautious when employing FQDN firewall addresses. Using a

fully qualified domain name in a firewall policy, while convenient, does
present some security risks, because policy matching then relies on a
trusted DNS server. Should the DNS server be compromised, firewall
policies requiring domain name resolution may no longer function
properly.
Example
This example adds an IPv4 firewall address for guest users of 10.13.101.100 address
the port1 interface.
To add a firewall IP address to the port1 interface - web-based manager
1Go to Firewall > Address > Address and select Create New.
2For the Address Name, enter Guest.
3Leave the Type as Subnet/IP Range.
4Enter the IP address of 10.13.101.100/24.
5For the Interface, select port1.
6Select OK.
To add a firewall IP address to the port1 interface- CLI
config firewall address
edit Guest
set type ipmask
set subnet 10.13.101.100/24
set associated-interface port1
end
Example
This example adds an IPv4 firewall address range for guest users with the range
of 10.13.101.100 to 10.13.101.110 addresses on any interface. By setting the interface to Any,
the address range is not bound to a specific interface on the FortiGate unit.
To add a firewall IP address to the port1 interface - web-based manager
3Leave the Type as Subnet/IP Range.
4Enter the IP address range of 10.13.101.[100-110].
5For the Interface, select Any.
6Select OK.
To add a firewall IP address to the port1 interface - CLI
edit Guest
set type iprange
set start-ip 10.13.101.100
set end-ip 10.13.101.110
end
Geography based addressing

An option is available to add a geography-based address scheme. With this type
of addressing, you indicated the geographic region, or country. The FortiGate unit includes an
internal list of countries and IP addresses based on historical data from the FortiGuard
network.
When used in firewall policies, traffic originating or going to a particular country can be logged,
blocked or specific filtering applied.
In the following examples, an geographic-based address for China is added for the
WAN1 port.
To add a geography-based address - web-based manager

2Enter the Name of China
3For the Type, select Geography.
4From the Country list, select China.
5Select the Interface of WAN1.
6Select OK.
To add a geography-based address - CLI
edit China
set type geography
set country CN
set interface wan1
end
Wildcard masks
Wildcard masks, are common with OSPF and Cisco routers. The use of wildcard masks
is most prevalent when building Access Control Lists (ACLs) on Cisco routers. ACLs are filters
and make use of wildcard masks to define the scope of the address filter.
Masks are used with IP addresses to specify what addresses are permitted and denied. To
configure IP addresses on interfaces, the netmask starts with 255. For example, to filter a
subnetwork 10.1.1.0 which has a Class C mask of 255.255.255.0, the ACL will require the
scope of the addresses to be defined by a wildcard mask which, in this example is 0.0.0.255.
When the value of the mask is shown in binary (0s and 1s), the results determine which
address bits are the “do and don’t care” bits for processing the traffic. A zero is the do care bit
and the one is a don’t care bit. This is also known as an inverse mask.
For example, an address of 1.1.1.0, and a netmask of 0.0.0.255

would appear in binary as an address of 00000001.00000001.00000001.00000000
and a netmask of 00000000.00000000.00000000.11111111
Based on the binary mask, it can be seen that the first three octets of the address must match
the given binary network address exactly (00000001.00000001.00000001). The last set of
numbers is made of “don't cares” (all ones). As such, all traffic that begins with 1.1.1. matches
since the last octet o the netmask is “don't care”. All IP addresses 1.1.1.1 through 1.1.1.255
are acceptable.
Wildcard masks are configured in the CLI:
set type wildcard
set wildcard 1.1.1.0/0.0.0.255
end
Fully Qualified Domain Name addresses

Using Fully Qualified Domain Name (FQDN) addresses in firewall policies has the advantage
of causing the FortiGate unit to keep track of DNS TTLs and adapt as records change. As long
as the FQDN address is used in a firewall policy, it stores the address in the DNS cache. The
FortiGate unit will query the DNS for an amount of time specified, in seconds, and update the
cache as required. This feature can reduce maintenance requirements for changing firewall
addresses for dynamic IP addresses. This also means that you can create firewall policies for
networks configured with dynamic addresses using DHCP.
Caution: Be cautious when employing FQDN firewall addresses. Using a
fully qualified domain name in a firewall policy, while convenient, does
present some security risks, because policy matching then relies on a
trusted DNS server. Should the DNS server be compromised, firewall
policies requiring domain name resolution may no longer function
properly.
You specify the TTL time in the CLI only. For example, to set the TTL for 30 minutes on
an FQDN of www.example.com on port 1, enter the following commands:
edit FQDN_example
set type fdqn
set associated-interface port 1
set fqdn www.example.com
set cache-ttl 1800
end
Virtual IPs
Virtual IP addresses (VIPs) can be used when configuring firewall policies to translate
IP addresses and ports of packets received by a network interface. When the FortiGate unit
receives inbound packets matching a firewall policy whose Destination Address field is a
virtual IP, the FortiGate unit applies NAT, replacing packets’ IP addresses with the virtual IP’s
mapped IP address.
IP pools, similarly to virtual IPs, can be used to configure aspects of NAT; however, IP pools
configure dynamic translation of packets’ IP addresses based on
the Destination Interface/Zone, whereas virtual IPs configure dynamic or static translation of a
packets’ IP addresses based upon the Source Interface/Zone.
To implement the translation configured in the virtual IP or IP pool, you must add it to a NAT
firewall policy.
Note: In Transparent mode, from the CLI, you can configure NAT firewall
policies that include Virtual IPs and IP pools. For more information, see
the System Administration chapter of The Handbook.
Virtual IPs can specify translations of packets’ port numbers and/or IP addresses for
both inbound and outbound connections. In Transparent mode, virtual IPs are available from
the FortiGate CLI.
Example
This simple example adds a virtual IP of 10.13.100.1 that allows users on the Internet
to connect to a web server on the DMZ IP address of 192.168.1.1. In the example, the wan1
interface of the FortiGate unit is connected to the Internet and the dmz1 interface is connected
to the DMZ network.
To add a static NAT virtual IP for a single IP address - web-based manager
1Go to Firewall > Virtual IP > Virtual IP and select Create New.
2For the Name, enter Static_NAT.
3Select the External interface of wan1
4Enter the External IP Address of 10.13.100.1.
5Enter the Mapped IP Address of 192.168.1.1.
6Select OK.
To add a static NAT virtual IP for a single IP address - CLI
config firewall vip
edit Static_NAT
set extintf wan1
set extip 10.13.100.1
set mappedip 192.168.1.1
end
Inbound connections
Virtual IPs can be used in conjunction with firewall policies whose Action is not DENY to apply
bidirectional NAT, also known as inbound NAT.
When comparing packets with the firewall policy list to locate a matching policy, if a
firewall policy’s Destination Address is a virtual IP, FortiGate units compare a packets’
destination address to the virtual IP’s external IP address. If they match, the FortiGate unit
applies the virtual IP’s inbound NAT mapping, which specifies how the FortiGate unit
translates network addresses and/or port numbers of packets from the receiving (external)
network interface to the network interface connected to the destination (mapped) IP address
or IP address range.
In addition to specifying IP address and port mappings between interfaces, virtual

IP configurations can optionally bind an additional IP address or IP address range to the
receiving network interface. By binding an additional IP address, you can configure a separate
set of mappings that the FortiGate unit can apply to packets whose destination matches that
bound IP address, rather than the IP address already configured for the network interface.
DNAT and virtual IP

If the NAT check box is not selected when building the firewall policy, the resulting policy does
not perform full (source and destination) NAT; instead, it performs destination network address
translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private
IP address, but does not translate the source address. The private network is aware of the
source’s public IP address. For reply traffic, the FortiGate unit translates packets’ private
network source IP address to match the destination address of the originating packets, which
is maintained in the session table.
You can define alternate IP addresses for the reply traffic. When configuring the
VIP addresses, you can define alternate source addresses for the return traffic. When
configuring the VIP, select the Source Address Filter option and enter the IP address or
address range.
The CLI command is:
config firewall vip
edit local-vip
set src-filter 172.20.120.129/24, 172.20.120.3-172.20.120.10
set extip x.x.x.x
set mappedip y.y.y.y
set port-forward enable
...
End
This enables packets from different sources to be translated to different VIP (or ports).
By default, the source filter is set to 0.0.0.0, or all source IPs.
Virtual IP options
The following table describes combinations of PAT and/or NAT that are possible
when configuring a firewall policy with a virtual IP.
Depending on your configuration of the virtual IP, its mapping may involve port address
translation (PAT), also known as port forwarding or network address port translation (NAPT),
and/or network address translation (NAT) of IP addresses.
If you configure NAT in the virtual IP and firewall policy, the NAT behavior varies by
your selection of:
•static vs. dynamic NAT mapping

•the dynamic NAT’s load balancing style, if using dynamic NAT mapping
•full NAT vs. destination NAT (DNAT)
Static NAT Static, one-to-one NAT mapping: an external IP address is always

translated to the same mapped IP address.
If using IP address ranges, the external IP address range
corresponds to a mapped IP address range containing an equal
number of IP addresses, and each IP address in the external range
is always translated to the same IP address in the mapped range.
Static NAT with Port Static, one-to-one NAT mapping with port forwarding: an external IP
Forwarding address is always translated to the same mapped IP address, and
an external port number is always translated to the same mapped
port number.
If using IP address ranges, the external IP address range

corresponds to a mapped IP address range containing an equal
number of IP addresses, and each IP address in the external range
is always translated to the same IP address in the mapped range. If
using port number ranges, the external port number range
corresponds to a mapped port number range containing an equal
number of port numbers, and each port number in the external
range is always translated to the same port number in the mapped
range.
Server Dynamic, one-to-many NAT mapping: an external IP address is

Load Balancing translated to one of the mapped IP addresses, as determined by the
selected load balancing algorithm for more even traffic distribution.
The external IP address is not always translated to the same
mapped IP address.
Server load balancing requires that you configure at least one “real”
server, but can use up to eight. Real servers can be configured with
health check monitors. Health check monitors can be used to gauge
server responsiveness before forwarding packets.
Server Dynamic, one-to-many NAT mapping with port forwarding: an

Load Balancing with external IP address is translated to one of the mapped IP
Port Forwarding addresses, as determined by the selected load balancing algorithm
for more even traffic distribution. The external IP address is not
always translated to the same mapped IP address.
Server load balancing requires that you configure at least one “real”
server, but can use up to eight. Real servers can be configured with
health check monitors. Health check monitors can be used to gauge
server responsiveness before forwarding packets.
A typical example of static NAT is to allow client access from a public network to a web server
on a private network that is protected by a FortiGate unit. Reduced to its essence, this
example involves only three hosts, as shown in Figure 35: the web server on a private
network, the client computer on another network, such as the Internet, and the FortiGate unit
connecting the two networks.
When a client computer attempts to contact the web server, it uses the virtual IP on
the FortiGate unit’s external interface. The FortiGate unit receives the packets. The addresses
in the packets are translated to private network IP addresses, and the packet is forwarded to
the web server on the private network.
Figure 35: A simple static NAT virtual IP example
The packets sent from the client computer have a source IP of 192.168.37.55 and
a destination IP of 192.168.37.4. The FortiGate unit receives these packets at its external
interface, and matches them to a firewall policy for the virtual IP. The virtual IP settings map
192.168.37.4 to 10.10.10.42, so the FortiGate unit changes the packets’ addresses. The
source address is changed to 10.10.10.2 and the destination is changed to 10.10.10.42. The
FortiGate unit makes a note of this translation in the firewall session table it maintains
internally. The packets are then sent on to the web server.
Figure 36: Example of packet address remapping during NAT from client to server
Note that the client computer’s address does not appear in the packets the server receives.
After the FortiGate unit translates the network addresses, there is no reference to the client
computer’s IP address, except in its session table. The web server has no indication that
another network exists. As far as the server can tell, all packets are sent by the FortiGate unit.
When the web server replies to the client computer, address translation works similarly, but in
the opposite direction. The web server sends its response packets having a source IP address
of 10.10.10.42 and a destination IP address of 10.10.10.2. The FortiGate unit receives these
packets on its internal interface. This time, however, the session table is used to recall the
client computer’s IP address as the destination address for the address translation. In the
reply packets, the source address is changed to 192.168.37.4 and the destination is changed
to 192.168.37.55. The packets are then sent on to the client computer.
The web server’s private IP address does not appear in the packets the client receives. After
the FortiGate unit translates the network addresses, there is no reference to the web server’s
network. The client has no indication that the web server’s IP address is not the virtual IP. As
far as the client is concerned, the FortiGate unit’s virtual IP is the web server.
Figure 37: Example of packet address remapping during NAT from server to client
In the previous example, the NAT check box is checked when configuring the firewall policy. If
the NAT check box is not selected when building the firewall policy, the resulting policy does
not perform full NAT; instead, it performs destination network address translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private
IP address, but does not translate the source address. The web server would be aware of the
client’s IP address. For reply traffic, the FortiGate unit translates packets’ private network
source IP address to match the destination address of the originating packets, which is
maintained in the session table.
Outbound connections
Virtual IPs can also affect outbound NAT, even though they are not selected in an outbound
firewall policy. If no virtual IPs are configured, FortiGate units apply traditional outbound NAT
to connections outbound from private network IP addresses to public network IP addresses.
However, if virtual IP configurations exist, FortiGate units use virtual IPs’ inbound NAT
mappings in reverse to apply outbound NAT, causing IP address mappings for both inbound
and outbound traffic to be symmetric.
For example, if a network interface’s IP address is 10.10.10.1, and its bound virtual
IP’s external IP is 10.10.10.2, mapping inbound traffic to the private network IP address
192.168.2.1, traffic outbound from 192.168.2.1 will be translated to 10.10.10.2, not 10.10.10.1.
Note: A virtual IP setting with port forwarding enabled does not translate the source address of
outbound traffic. If both virtual IP (without port forwarding) and IP Pools are enabled, IP Pools is
preferred for source address translation of outbound traffic.
Virtual IP, load balance virtual server / real server limitations

The following limitations apply when adding virtual IPs, load balancing virtual
servers, and load balancing real servers. Load balancing virtual servers are
actually server load balancing virtual IPs. You can add server load balance virtual
IPs from the CLI.
Virtual IP External IP Address/Range entries or ranges cannot overlap with each
•other or with load balancing virtual server Virtual Server IP entries.
•A virtual IP Mapped IP Address/Range cannot be 0.0.0.0 or 255.255.255.255.
•A real server IP cannot be 0.0.0.0 or 255.255.255.255.
If a static NAT virtual IP External IP Address/Range is 0.0.0.0, the Mapped
•IP Address/Range must be a single IP address.
If a load balance virtual IP External IP Address/Range is 0.0.0.0, the Mapped
•IP Address/Range can be an address range.
When port forwarding, the count of mapped port numbers and external
port numbers must be the same. The web-based manager does this
•automatically but the CLI does not.
Virtual IP and virtual server names must be different from firewall address or
address group names.
Address groups
Similar to zones, if you have a number of addresses or address ranges that

require the same firewall policies, you can put them into address groups, rather
than creating multiple similar policies. Because firewall policies require addresses
with homogenous network interfaces, address groups should contain only
addresses bound to the same network interface, or to Any — addresses whose
selected interface is Any are bound to a network interface during creation of a
firewall policy, rather than during creation of the firewall address.
For example, if address 1.1.1.1 is associated with port1, and address 2.2.2.2 is
associated with port2, they cannot be in the same group. However, if 1.1.1.1 and
2.2.2.2 are configured with an interface of Any, they can be grouped, even if the
addresses involve different networks.
You cannot mix IPv4 firewall addresses and IPv6 firewall addresses in the same
address group.
Example
This example creates an address group accounting, where addresses for User_1
and User_2 have port association of Any. It is recommended to add the addresses
you want to add to the group before setting up the address group.
To create an address group - web-based manager
1Go to Firewall > Address > Group, and select Create New.
2Enter the Group Name of accounting.
From the Available Addresses list, select an address and select the down-arrow
3button to move the address name to the Members list.
Repeat step three as many times as required. You can also hold the SHIFT key
4to select a range of address names from the list.
5Select OK.
To create an address group - CLI
config firewall addrgrp
edit accounting
set member User_1
set member User_2
end
DHCP
The Dynamic Host Configuration Protocol (DHCP) enables hosts to automatically
obtain an IP address from a DHCP server. Optionally, hosts can also obtain
default gateway and DNS server settings.
Note: DHCP is not available when the FortiGate unit is operating in
Transparent mode.
On FortiGate 30B, 50 and 60 series units, a DHCP server is configured, by

default, on the Internal interface, as follows:
IP Range 192.168.1.110 to 192.168.1.210

Netmask 255.255.255.0
Default gateway 192.168.1.99
Lease time 7 days
DNS Server 1 192.168.1.99
A FortiGate interface can provide the following DHCP services:
•Basic DHCP servers with up to three IP address ranges per server
•IPSec DHCP servers for IPSec (VPN) connections
•DHCP relay for regular Ethernet or IPSec (VPN) connections
An interface cannot provide both a server and a relay for connections of the same
type.
You can configure one or more DHCP servers on any FortiGate interface. A
DHCP server dynamically assigns IP addresses to hosts on the network
connected to the interface. The host computers must be configured to obtain their
IP addresses using DHCP. The IP range of each DHCP server must match the
network address range. The routers must be configured for DHCP relay.
DHCP options
When adding a DHCP server, you have the ability to include DHCP codes and
options. The DHCP options are BOOTP vendor information fields that provide
additional vendor-independent configuration parameters to manage the DHCP
server. For example, you may need to configure a FortiGate DHCP server that
gives out a separate option as well as an IP address. For example, an
environment that needs to support PXE boot with Windows images.
The option numbers and codes are specific to the particular application.
The documentation for the application will indicate the values to use. Option codes
are represented in a option value/HEX value pairs. The option is a value 1 and
255.
You can add up to three DHCP code/option pairs per DHCP server.
To configure option 252 with value http://192.168.1.1/wpad.dat - web-based
manager
1Go to System > Network > DHCP Server and select Create New.
2Select a Mode of Server.
3Select the blue arrow to expand the Advanced options.
4Select Options.
5Enter a Code of 252.
Enter
6the Options of 687474703a2f2f3139322e3136382e312e312f777061642e646174.
In the CLI, use the commands:
config system dhcp server
edit <dhcp_server_number>
set option1
252 687474703a2f2f3139322e3136382e312e312f777061642e646174
end
Example
This example sets up a DHCP server on the Internal interface for guests with an
IP range of 10.13.101.100 to 10.13.101.110, a default gateway of 10.13.101.2 and
address lease of 5 days.
To configure a DHCP server on the internal interface - web-based manager
1Go to Go to System > Network > DHCP Server and select Create New.
2Select the Interface of Internal.
3Select the Mode of Server.
4Enter the IP Range of 10.13.101.100 to 10.13.101.110.
5Enter a Netmask of 255.255.255.0.
6Enter a Default Gateway of 10.10.101.2.
7Select the blue arrow to expand the Advanced options.
8Set a Lease Time of five days.
9Select OK.
To configure a DHCP server on the internal interface - CLI
config system dhcp server
edit 1
config ip-range
edit 1
set start-ip 10.13.101.100
set end-ip 10.13.101.105
end
set server-type regular
set interface internal
set netmask 255.255.255.0
set default-gateway 10.13.101.2
set lease-time 432000
end
A FortiGate interface can also be configured as a DHCP relay. The interface
forwards DHCP requests from DHCP clients to an external DHCP server and
returns the responses to the DHCP clients. The DHCP server must have
appropriate routing so that its response packets to the DHCP clients arrive at the
FortiGate unit.
Example
This example sets up a DHCP relay on the internal interface from the DHCP
server located at 172.20.120.55. The FortiGate unit will send a request for an IP
address from the defined DHCP server and forward it to the requesting
connection.
To configure a DHCP relay on the internal interface - web-based manager

1Go to System > Network > DHCP Server and select Create New.
2Select the internal interface and select the Mode of Relay.
3Select the Type of Regular.
4Enter the DHCP Server IP address of 172.20.120.55.
5Select OK.
To configure a DHCP relay on the internal interface - CLI
edit internal
set dhcp-relay-service enable
set dhcp-relay-type regular
set dhcp-relay-ip 172.20.120.55
end
IP reservation with DHCP

Within the DHCP pool of addresses, you can ensure certain computers will always
have the same address. This can be to ensure certain users always have an IP
address when connecting to the network, or if you want a device that connects
occasionally to have the same address for monitoring its activity or use.
In the example below, the IP address 172.20.19.69 will be matched to MAC
address 00:1f:5c:b8:03:57.
To configure IP reservation - web-based manager

1Go to System > Network > DHCP Server.
2Select the DHCP server from the list.
3Select IP Reservation and select Create New.
4Enter an IP address of 172.20.19.69
5Enter the MAC address of 00:1f:5c:b8:03:57.
6Select OK.
To configure IP reservation - CLI
config sys dhcp server
edit 1
config reserved-address
edit 1
set ip 172.20.19.69
set mac 00:1f:5c:b8:03:57
end
Alternatively, an administrator can manually select an IP address from the

assigned address list and set it to be linked to that MAC address automatically.
To reserve an IP from an assigned list
1Go to System > Network > DHCP Server.
2Select the DHCP server from the list.
3Select IP Reservation and select Add from DHCP Client List.
When the DHCP Client List window appears, select the check boxes beside the
4IP addresses and select Add to Reserved.
IP pools
An IP pool defines a single IP address or a range of IP addresses. A single IP
address in an IP pool becomes a range of one IP address. For example, if you
enter an IP pool as 1.1.1.1, the IP pool is actually the address range, 1.1.1.1 to
1.1.1.1. Use IP pools to add NAT policies that translate source addresses to
addresses randomly selected from the IP pool, rather than the IP address
assigned to that FortiGate interface.
If a FortiGate interface IP address overlaps with one or more IP pool address
ranges, the interface responds to ARP requests for all of the IP addresses in the
overlapping IP pools.
For example, consider a FortiGate unit with the following IP addresses for the
port1 and port2 interfaces:
•port1 IP address: 1.1.1.1/255.255.255.0 (range is 1.1.1.0-1.1.1.255)
•port2 IP address: 2.2.2.2/255.255.255.0 (range is 2.2.2.0-2.2.2.255)
And the following IP pools:

•IP_pool_1: 1.1.1.10-1.1.1.20
•IP_pool_2: 2.2.2.10-2.2.2.20
•IP_pool_3: 2.2.2.30-2.2.2.40
The port1 interface overlap IP range with IP_pool_1 is:

•(1.1.1.0-1.1.1.255) and (1.1.1.10-1.1.1.20) = 1.1.1.10-1.1.1.20

•(2.2.2.0-2.2.2.255) & (2.2.2.10-2.2.2.20) = 2.2.2.10-2.2.2.20

•(2.2.2.0-2.2.2.255) & (2.2.2.30-2.2.2.40) = 2.2.2.30-2.2.2.40
And the result is:

•The port1 interface answers ARP requests for 1.1.1.10-1.1.1.20
The port2 interface answers ARP requests for 2.2.2.10-2.2.2.20 and for 2.2.2.30-
•2.2.2.40
Select NAT in a firewall policy and then select Dynamic IP Pool. Select an IP pool
to translate the source address of packets leaving the FortiGate unit to an address
randomly selected from the IP pool.
IP pools cannot be set up for a zone. IP pools are connected to individual
interfaces.
Example
This example sets up an IP Pool with an address range of 10.13.101.100 to
10.13.101.110 for guest accounts on the network.
To configure an IP Pool - web-based manager
1Go to Firewall > Virtual IP > IP Pool and select Create New.
2Enter the Name of Guest.
3Enter the IP Range/Subnet of 10.13.101.100-10.13.101.110.
4Select OK.
To configure an IP Pool - CLI
config firewall ippool
edit Guest
set startip 10.13.101.100
set endip 10.13.101.110
end
IP Pools for firewall policies that use fixed ports

Some network configurations do not operate correctly if a NAT policy translates
the source port of packets used by the connection. NAT translates source ports to
keep track of connections for a particular service.
From the CLI you can enable fixedport when configuring a firewall policy for NAT
policies to prevent source port translation.
config firewall policy
edit policy_name
...
set fixedport enable
...
end
However, enabling fixedport means that only one connection can be supported
through the firewall for this service. To be able to support multiple connections,
add an IP pool, and then select Dynamic IP pool in the policy. The firewall
randomly selects an IP address from the IP pool and assigns it to each
connection. In this case, the number of connections that the firewall can support is
limited by the number of IP addresses in the IP pool.
Source IP address and IP pool address matching

When the source addresses are translated to the IP pool addresses, one of the
following three cases may occur:
Scenario 1: The number of source addresses equals that of IP pool

addresses
In this case, the FortiGate unit always matches the IP addressed one to one.
If you enable fixedport in such a case, the FortiGate unit preserves the original
source port. This may cause conflicts if more than one firewall policy uses the
same IP pool, or the same IP addresses are used in more than one IP pool.
Original address Change to
192.168.1.1 172.16.30.1
192.168.1.2 172.16.30.2
...... ......
192.168.1.254 172.16.30.254
Scenario 2: The number of source addresses is more than that of IP pool

addresses
In this case, the FortiGate unit translates IP addresses using a wrap-around
mechanism.
If you enable fixedport in such a case, the FortiGate unit preserves the original
source port. But conflicts may occur since users may have different sessions using
the same TCP 5 tuples.

192.168.1.1 172.16.30.10
192.168.1.2 172.16.30.11
...... ......
192.168.1.10 172.16.30.19
192.168.1.11 172.16.30.10
192.168.1.12 172.16.30.11
192.168.1.13 172.16.30.12
...... ......
Scenario 3: The number of source addresses is fewer than that of IP pool
addresses
In this case, some of the IP pool addresses are used and the rest of them are not
be used.

192.168.1.1 172.16.30.10
192.168.1.2 172.16.30.11
192.168.1.3 172.16.30.12
No more source addresses 172.16.30.13 and other addresses are not used
IPv6
Internet Protocol version 6 (IPv6) is the next-generation version of IP addressing,
to eventually replace IPv4. IPv6 was developed because there is a concern that in
the near future, the available addresses for the IPv4 infrastructure will be
exhausted. The IPv6 infrastructure will supplement, and eventually, replace the
IPv4 standard.
Where IPv4 uses 32 bit addressing, IPv6 uses 128 bit addressing, effectively
providing trillions upon trillions of unique addresses, whereas IPv4 can have a a
little over 4 billion. With this larger address space, allocating addresses and
routing traffic becomes easier, and network address translation (NAT) becomes
virtually unnecessary.
Where IPv4 addresses are written numerals separated by a decimal, the IPv6
address is written with hexadecimal digits separated by a colon. For example,
fe80:218:8bff:fe84:4223.
By default, the FortiGate unit is not enabled to use IPv6 addressing. To enable
this feature, go to System > Admin > Settings and select IPv6 Support on GUI.
When enabled you can use IPv6 addressing on any of the address-dependant
components of the FortiGate unit, including firewall policies, interface addressing,
DNS servers. IPv6 addressing can be configured on the web-based manager and
in the CLI.
For further information on IPV6 in FortiOS, see “IPv6”.
Example
This example adds an IPv6 address 2001:db8:0:1234:0:567:1:1 for the WAN1
interface as well as the administrative access to HTTPS and SSH. As a good
practice, set the administrative access when you are setting the IP address for the
port.
To add an IP address for the WAN1 interface - web-based manager

2Select WAN1 row and select Edit.
4Enter the IPv6 Address of 2001:db8:0:1234:0:567:1:1.
5For Administrative Access select HTTPS and SSH.

6Select OK.
To create IP address for the WAN1 interface - CLI

edit wan1
config ipv6
set ip6-address 2001:db8:0:1234:0:567:1:1
set ip6-allowaccess https ssh
end
Example
This example adds an IPv6 firewall address for guest users of
2001:db8:0:1234:0:567:1:1.
To add a firewall IPv6 address - web-based manager

1Go to Firewall > Address > Address.
2On the Create New button, click the down arrow on the right.
If there is no arrow, ensure you have enabled IPv6 by going to System > Admin
> Settings and select IPv6 Support on GUI.
3Select IPv6 Address.
5Enter the IP address of 2001:db8:0:1234:0:567:1:1/128.
6Select OK.
To add a firewall IPv6 address - CLI

config firewall address6
edit Guest
set ip6 2001:db8:0:1234:0:567:1:1/128
end
Ports
A port is a type of address used by specific applications and processes. The
FortiGate unit uses a number of port assignments to send and receive information
for basic system operation and communication by default.
Originating traffic
Function Port(s)
DNS lookup; RBL lookup UDP 53
FortiGuard Antispam or Web Filtering rating lookup UDP 53 or
UDP 8888
FDN server list UDP 53 (default)
Source and destination port numbers vary by originating or UDP 8888, and
or reply traffic. UDP 1027 or UDP
1031
NTP synchronization UDP 123
SNMP traps UDP 162
Syslog UDP 514
All FortiOS versions can use syslog to send log
messages to remote syslog servers.
Note: If a secure connection has been configured
between a FortiGate and a FortiAnalyzer, Syslog traffic
will be sent into an IPSec tunnel. Data will be exchanged
over UDP 500/4500, Protocol IP/50.
Configuration backup to FortiManager unit or FortiGuard TCP 22
Analysis and Management Service
SMTP alert email; encrypted virus sample auto-submit TCP 25
LDAP or PKI authentication TCP 389 or TCP 636
FortiGuard Antivirus or IPS update TCP 443
When requesting updates from a FortiManager unit
instead of directly from the FDN, this port must be
reconfigured as TCP 8890.
FortiGuard Analysis and Management Service TCP 443
FortiGuard Analysis and Management Service log TCP 514
transmission (OFTP)
SSL management tunnel to FortiGuard Analysis and TCP 541
Management Service
FortiGuard Analysis and Management Service contract TCP 10151
validation
Quarantine, remote access to logs & reports on a TCP 514
FortiAnalyzer unit, device registration with FortiAnalyzer
units (OFTP)
RADIUS authentication TCP 1812
Receiving traffic
When operating in the default configuration, FortiGate units do not accept TCP or
UDP connections on any port except the default internal interface, which accepts
HTTPS connections on TCP port 443.
Function Port(s)
FortiGuard Antivirus and IPS update push UDP 9443
The FDN sends notice that an update is available. Update
downloads then occur on standard originating ports for updates.
SSH administrative access to the CLI; remote management from TCP 22
a FortiManager unit
Telnet administrative access to the CLI; HA synchronization TCP 23
(FGCP L2)
Changing the telnet administrative access port number also
changes the HA synchronization port number.
HTTP administrative access to the web-based manager TCP 80
HTTPS administrative access to the web-based manager; TCP 443
remote management from a FortiManager unit; user
authentication for policy override
SSL management tunnel from FortiGuard Analysis and TCP 541
Management Service (FortiOS v3.0 MR6 or later)
HA heartbeat (FGCP L2) TCP 703
User authentication keep alive and logout for policy override TCP 1000
(default value of port for HTTP traffic)
This port is closed until enabled by the auth-keepalive command.
User authentication keepalive and logout for policy override TCP 1003
(default value of port for HTTPS traffic)
This port is closed until enabled by the auth-keepalive command.
Windows Active Directory (AD) Collector Agent TCP 8000
User authentication for policy override of HTTP traffic TCP 8008
FortiClient download portal TCP 8009
This feature is available on FortiGate-1000A, FortiGate-3600A,
and
FortiGate-5005FA2.
User authentication for policy override of HTTPS traffic TCP 8010
VPN settings distribution to authenticated FortiClient installations TCP 8900
SSL VPN TCP 10443
HA ETH 8890
(Layer 2)
Closing specific ports to traffic

By default, FortiGate units do not accept remote administrative access except by
HTTPS connections on TCP port 443 to the default internal network interface for
some FortiGate models. Restricting administrative access by default ensures that
only you can change your firewall policies and security configuration. It also
improves security of the FortiGate unit itself by reducing the number of ports that
potential attackers can discover by network probes and port scans, a common
method of discovering open ports for denial of service (DoS) attacks.
Port 113
TCP port 113 (Ident/Auth) is an exception to the above rule. By default, FortiGate
units receiving an IDENT request on this port respond with a TCP RST, which
resets the connection. This prevents delay that would normally occur if the
requesting host were to wait for the connection attempt to time out.
This port is less commonly used today. If you do not use this service, you can
make your FortiGate unit less visible to probes. You can disable TCP RST
responses to IDENT requests and subject those requests to firewall policies, and
thereby close this port.
For each network interface that should not respond to ident requests on TCP port
113, enter the following CLI commands:
edit <port_name>
set ident-accept enable
end
For example, to disable ident responses on a network interface names port1, enter
the following commands:
edit port1
set ident-accept enable
end
Port 541
By default, FortiGate units use this port to initiate an SSL-secured management
tunnel connection to centralized device managers such as the FortiGuard Analysis
and Management Service.
If you do not use centralized management you can make your FortiGate unit less
visible to probes. You can disable the management tunnel feature, and thereby
close this port using the following CLI command:
config sys central-management
set status disable
end
Services
Services represent typical traffic types and application packets that pass through
the FortiGate unit. Firewall services define one or more protocols and port
numbers associated with each service. Firewall policies use service definitions to
match session types. You can organize related services into service groups to
simplify your firewall policy list.
Many well-known traffic types have been predefined in firewall services and
protocols on the FortiGate unit. These predefined services and protocols are
defaults, and cannot be edited or removed. However, if you require different
services, you can create custom services.
To view the predefined servers, go to Firewall > Service > Predefined.
Custom service
Should there be a service that does not appear on the list, or you have a unique
service or situation, you can create your own custom service. You need to know
the port(s), IP addresses or protocols the particular service or application uses to
create the custom service.
Example
This example creates a custom service for the “Widget” application, which
communicates on TCP port 9620 for source traffic and between ports 4545 and
4550 for destination traffic.
To create a custom service - web-based manager
1Go to Firewall > Service > Custom and select Create New.
2Enter the following and select Add:
Name Widget
Protocol Type TCP/UDP/SCTP
Protocol TCP
Source Port
Low 9620
Hi 9620
Destination Port
Low 4545
High 4550
3Select OK.
To create a custom service - CLI
config firewall service custom
edit Widget
set protocol TCP/UDP/SCTP
set tcp-portrange 9620:4545-4550
end
Schedules
When you add firewall policies on a FortiGate unit, those policies are always on,
policing the traffic through the device. Firewall schedules control when policies are
in effect, that is, when they are on. You can create one-time schedules which are
schedules that are in effect only once for the period of time specified in the
schedule. You can also create recurring schedules that are in effect repeatedly at
specified times of specified days of the week.
You can create a recurring schedule that activates a policy during a specified
period of time. For example, you might prevent game playing during office hours
by creating a recurring schedule that covers office hours.
If a recurring schedule has a stop time that is earlier than the start time, the
schedule will take effect at the start time but end at the stop time on the next day.
You can use this technique to create recurring schedules that run from one day to
the next. For example, to prevent game playing except at lunchtime, you might set
the start time for a recurring schedule at 1:00 p.m. and the stop time at 12:00
noon. To create a recurring schedule that runs for 24 hours, set the start and stop
times to 00.
Example
This example creates a schedule for surfing the Internet at lunch time. The
company restricts the amount of surfing on company time, but over lunch, the
restrictions are lifted. For this schedule, a firewall policy would be created to
enable all services for a limited amount of time. This example sets up the time
frame.
To create a recurring firewall schedule - web-based manager

To create a recurring firewall schedule - CLI
config firewall schedule recurring
edit Lunch-Surfing
set day monday tuesday wednesday thursday friday
set start 12:00
set end 1:00
end
Example
This example creates a one-time schedule for a firewall policy. In this example, a
company is shut down over the Christmas holidays. To prevent employees from
coming to work to use the internet connection, the company sets up a one-time
firewall policy to block most internet traffic during this time period. A schedule
needs to be created to limit internet traffic between December 25 and January 1.
To create a one-time firewall schedule - web-based manager
1Go to Firewall > Schedule > One-time, and select Create New.
2Enter the schedule Name of Xmas-Shutdown.
3Enter the following and select OK.
/Start
Year 2009
Month 12
Day 25
Hour 00
Minute 00
Stop
Year 2010
Month 01
Day 01
Hour 23
Minute 00
To create a firewall schedule - CLI
config firewall schedule onetime
edit Xmas-Shutdown
set start 00:00 2009/12/25
set end 23:00 2010/01/01
end
Schedule groups
You can organize multiple firewall schedules into a schedule group to simplify your
firewall policy list. For example, instead of having five identical policies for five
different but related firewall schedules, you might combine the five schedules into
a single schedule group that is used by a single firewall policy.
Schedule groups can contain both recurring and one-time schedules. Schedule
groups cannot contain other schedule groups.
Example
This example creates a schedule group for the schedules created in the
previous schedule examples. The schedule group enables you to have one
firewall policy that covers both schedules, rather than creating two separate
policies.
To create a firewall schedule group - web-based manager

1Go to Firewall > Schedule > Group, and select Create New.
2Enter the group Name of Schedules.
From the Available Schedules list, select the Lunch-Surfing schedule and select
3the down-arrow button to move the address name to the Members list.
From the Available Schedules list, select the Xmas-Shutdown schedule and
4select the down-arrow button to move the address name to the Members list.
5Select OK.
To create a recurring firewall schedule - CLI
config firewall schedule group
edit Schedules
set member Lunch-Surfing Xmas-Shutdown
end
Schedule expiry
The schedule in a firewall policy enables certain aspects of network traffic to occur
for a specific length of time. What it does not do however, is police that time. That
is, the policy is active for a given time frame, and as long as the session is open,
traffic can continue to flow.
For example, in an office environment, Skype use is allowed between noon and
1pm. During that hour, any Skype traffic continues. As long as that session is
open, after the 1pm end time, the Skype conversations can continue, yet new
sessions will be blocked. Ideally, the Skype session should close at 1pm.
Using a CLI command you can set the schedule to terminate all sessions when
the end time of the schedule is reached. Within the config firewall command enter
the command:
set schedule-timeout enable
By default, this is set to disable.
Identity-based policies
It is important to note that this setting is similar to the termination time of an

identity-based policy, also known as an authentication policy. These can be used
together. If user authentication is used, FortiOS will use the Hard Timeout option.
With a combination of the schedule timeout and the authentication timeout,
FortiOS will use whichever time is shorter.
For example, Example.com has a schedule policy to use P2P applications

between 12:00 and 1:00, and a user authentication timeout of 30 minutes.
With user authentication, if a user logs in at 12:15, their authentication time will log
them off at 12:45 (30 minutes later). If they log in at 12:45, the firewall schedule
will log them out at 1:00 (15 minutes later).
Equally, if no authentication is used, and a user logs in at 12:45, the schedule will
log them out at 1:00 (45 minutes later). If they log in at 12:55, they will also be
logged out at 1:00 (5 minutes later). The following table illustrates this point:
Authentication Session Session end

Start
Yes 12:15 30 minutes (expire at 12:45 - authentication
timeout of 30 minutes)
12:45 15 minutes (expire at 1:00 - end of the firewall
schedule)
No 12:15 45 minutes (expire at 1:00 - end of firewall
schedule)
12:55 5 minutes (expire at 1:00 - end of firewall
schedule)
UTM profiles
Where firewall policies provide the instructions to the FortiGate unit as to what
traffic is allowed through the device, the Unified Threat Management (UTM)
profiles provide the screening that filters the content coming and going on the
network. The UTM profiles enable you to instruct the FortiGate unit what to look
for in the traffic that you don’t want, or want to monitor, as it passes through the
device.
A UTM profile is a group of options and filters that you can apply to one or more
firewall policies. UTM profiles can be used by more than one firewall policy. You
can configure sets of UTM profiles for the traffic types handled by a set of firewall
policies that require identical protection levels and types, rather than repeatedly
configuring those same UTM profile settings for each individual firewall policy.
For example, while traffic between trusted and untrusted networks might need
strict antivirus protection, traffic between trusted internal addresses might need
moderate antivirus protection. To provide the different levels of protection, you
might configure two separate protection profiles: one for traffic between trusted
networks, and one for traffic between trusted and untrusted networks.
UTM profiles are available for various unwanted traffic and network threats. Each
are configured separately and can be used in different groupings as needed. You
configure UTM profiles in the UTM menu and applied when creating a firewall
policy by selecting the UTM profile type.
Profiles and sensors
The UTM profiles can be identified by two categories: profiles (VoIP, antivirus, web
filter and email filter) and sensors (intrusion prevention, application control and
data leak prevention). Profiles are a group of identifiers to filter unwanted email
such as spam, web content and provide virus detection. Sensors are a grouping of
common or custom signature information that the FortiGate unit uses to identify, or
sense, an intrusion or data leak and prevent it from occurring. FortiOS includes a
selection of common sensors, and you can create custom ones as well.
For both categories, you create a unique set of criteria for the profile or sensor and
select it for the firewall policy. When traffic passes through the FortiGate unit, the
FortiGate unit compares the traffic information to see if the policy is valid. If it is, it
then applies the profiles and sensors to the traffic to determine if the traffic is an
attack, virus, spam or unwanted web content and either blocks or allows the traffic
through depending on how the sensor or policy was configured.
FortiOS includes a selection default UTM profiles and sensors. The defaults
provide varying levels of security from very strict, monitoring or blocking
everything, to very light allowing most traffic through. You can use these default
protection profiles as is to quickly configure your network security or as the bases
for creating your own.
Example
This example creates an antivirus profile that will scan all email traffic for viruses.
The new profile will be called email_scan.
To create a antivirus profile for email - web-based manager
Go to UTM > AntiVirus > Profile and select the plus sign in the upper right corner
1of the window.
2Enter the Name of email_scan.
3For the Virus Scan row, select IMAP, POP3 and SMTP.
4Select OK.
To create a antivirus profile for email - CLI
config antivirus profile
edit email_scan
config imap
set options scan
end
config smtp
set options scan
end
config pop3
set options scan
end
end
Firewall Policies
Firewall policies control all traffic attempting to pass through the FortiGate unit,
between FortiGate interfaces, zones, and VLAN subinterfaces.
Firewall policies are instructions the FortiGate unit uses to decide connection
acceptance and packet processing for traffic attempting to pass through. When the
firewall receives a connection packet, it analyzes the packet’s source address,
destination address, and service (by port number), and attempts to locate a
firewall policy matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow
when it receives matching packets. Some instructions are required, such as
whether to drop or accept and process the packets, while other instructions, such
as logging and authentication, are optional.
Policy instructions may include network address translation (NAT), or port

address translation (PAT), or by using virtual IPs or IP pools to translate source
and destination IP addresses and port numbers.
Policy instructions may also include UTM profiles, which can specify application-
layer inspection and other protocol-specific protection and logging, as well as IPS
inspection at the transport layer.
This chapter describes what firewall policies are and how they affect all traffic to
and from your network. It also describes how to configure some key policies; these
are basic policies you can use as a building block to more complex policies, but
they enable you to get the FortiGate unit running on the network quickly.
This chapter contains the following topics:
•Policy order
•Creating basic policies
•Firewall policy examples
You configure firewall policies to define which sessions will match the policy and
what actions the FortiGate unit will perform with packets from matching sessions.
Sessions are matched to a firewall policy by considering these features of both the
packet and policy:
•Source Interface/Zone
•Source Address
•Destination Interface/Zone
•Destination Address
•Schedule and time of the session’s initiation
•Service and the packet’s port numbers.
If the initial packet matches the firewall policy, the FortiGate unit performs the
configured Action and any other configured options on all packets in the session.
Packet handling actions can be ACCEPT, DENY, IPSEC or SSL-VPN.

ACCEPT policy actions permit communication sessions, and may optionally
include other packet processing instructions, such as requiring authentication to
use the policy, or specifying one or more UTM profiles to apply features such as
virus scanning to packets in the session. An ACCEPT policy can also apply
interface-mode IPSec VPN traffic if either the selected source or destination
•interface is an IPSec virtual interface.
DENY policy actions block communication sessions, and you can optionally log
the denied traffic. If no firewall policy matches the traffic, the packets are
dropped, therefore it is not required to configure a DENY firewall policy in the last
position to block the unauthorized traffic. A DENY firewall policy is needed when
•it is required to log the denied traffic, also called “violation traffic”.
IPSEC and SSL-VPN policy actions apply a tunnel mode IPSec VPN or SSL
VPN tunnel, respectively, and may optionally apply NAT and allow traffic for one
or both directions. If permitted by the firewall encryption policy, a tunnel may be
initiated automatically whenever a packet matching the policy arrives on the
•specified network interface, destined for the local private network.
Create firewall policies based on traffic flow. For example, a policy for POP3,
where the email server is outside of the internal network, traffic should be from an
internal interface to an external interface rather than the other way around. It is
typically the user on the network requesting email content from the email server
and thus the originator of the open connection is on the internal port, not the
external one of the email server. This is also important to remember when view log
messages as to where the source and destination of the packets can seem
backwards.
Policy order
Each time a FortiGate unit receives a connection attempting to pass through one
of its interfaces, the unit searches its firewall policy list for a matching firewall
policy.
The search begins at the top of the policy llist
ist and progresses in order towards the
bottom. The FortiGate unit evaluates each policy in the firewall policy list for a
match until a match is found. When the FortiGate unit finds the first matching
policy, it applies the matching policy’s specified act actions
ions to the packet, and
disregards subsequent firewall policies. Matching firewall policies are determined
by comparing the firewall policy and the packet’s:
•source and destination interfaces
•source and destination firewall addresses
•services
•time/schedule.
If no policy matches, the connection is dropped.

As a general rule, you should order the firewall policy list from most specific to
most general because of the order in which policies are evaluated for a match,
and because only the first matching
ching firewall policy is applied to a connection.
Subsequent possible matches are not considered or applied. Ordering policies
from most specific to most general prevents policies that match a wide range of
traffic from superseding and effectively masking policies that match exceptions.
For example, you might have a general policy that allows all connections from the
internal network to the Internet, but want to make an exception that blocks FTP. In
this case, you would add a policy that denies FTP connecti
connections
ons above the general
policy.
Figure 38: Example: Blocking FTP — Correct policy order
FTP connections would immediately match the deny policy, blocking the
connection. Other kinds of services do not match the FTP policy, and so policy
evaluation would continue
ntinue until reaching the matching general policy. This policy
order has the intended effect. But if you reversed the order of the two policies,
positioning the general policy before the policy to block FTP, all connections,
including FTP, would immediatel
immediately y match the general policy, and the policy to block
FTP would never be applied. This policy order would not have the intended effect.
Figure 39: Example: Blocking FTP — Incorrect policy order
Similarly, if specific traffic requires authentication, IPSec VPN, or SSL VPN, you
would position those policies above other potential matches in the policy list.
Otherwise, the other matching policies would always take precedence, and the
required authentication, IPSec VPN, or SSL VPN might never occur.
Note: A default firewall policy may exist which accepts all connections.
You can move, disable or delete it. If you move the default policy to the
bottom of the firewall policy list and no other policy matches the packet,
the connection will be accepted. If you disable or delete the default policy
and no other policy matches the packet, the connection will be dropped.
You can arrange the firewall policy list to influence the order in which policies
are evaluated for matches with incoming traffic. When more than one policy has
been defined for the same interface pair, the first matching firewall policy will be
applied to the traffic session.
Creating basic policies

This section describes how to configure basic firewall policies based on the
selectable actions described above. The following criteria will be used for each
policy for internal/source and external/destination information. Single addresses
are used for simplification.
Source interface/Zone Internal

Source address 10.13.20.22
Destination interface/Zone WAN1
Destination address 172.20.120.141
Using an interface of “any”

When adding a firewall policy
with Source interface/zone or Destination interface/zone set to ANY, that the
firewall policy list can only be displayed in Global View. This is because a firewall
policy with an ANY interface potentially applies to all interfaces, however it does
not accurately reflect the actual firewall configuration if all of the ANY interface
policies appears in every section in Section View.
The actual affect to policy matching of a firewall policy with any as the source
or destination interface is only clear on the global policy list.
Basic accept policy example

With this basic accept policy example, the firewall policy will accept all HTTP
traffic passing from the external interface (WAN1) to the internal interface
(Internal) at all times. This enables users to surf the internet using HTTP (port 80).
Using this policy alone, no other traffic (email, FTP and so on) to pass through the
FortiGate unit. The policy allows a session to be created that traverses the
FortiGate unit from WAN1 (the source) to Internal (the destination). That is the
direction data is moving when an internal user views a web page, but the incoming
page data first has to be requested, and that happens by opening a session from
Internal to WAN1 first.
To create a basic accept policy for HTTP - web-based manager
1Go to Firewall > Policy > Policy and select Create New.
2Enter the following and select OK:
Destination address ALL
Schedule always
Service HTTP
Action ALLOW
To create a basic accept policy for HTTP - CLI
edit 1
set srcintf internal
set scraddr 10.13.20.22
set dstintf wan1
set dstaddr all
set action accept
set schedule always
set service http
end
Basic deny policy example

With this basic deny policy example, the firewall policy will deny all FTP traffic
passing from the internal interface (Internal) to the external interface (WAN1) at all
times. This prevents users from uploading files to an FTP site. Ideally, this would
not be the only policy on the FortiGate unit.
To create a basic deny policy for FTP - web-based manager
Schedule always
Service FTP
Action DENY
To create a basic accept policy for FTP - CLI
edit 1
set srcaddr 10.13.20.22
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service ftp
end
Basic VPN policy example

With this basic VPN policy example, the firewall policy will allow VPN traffic
between the FortiGate unit in the branch office and the head office. For simplicity,
the VPN configuration has been completed. The Phase 1 name is Head_Office.
This firewall policy would be configured on the Branch office FortiGate unit.
To create a basic VPN policy - web-based manager
Destination WAN1
interface/Zone
Schedule always
Service any
Action IPSEC
VPN Tunnel Select Head_Office from the configured list of
VPN tunnels.
To create a basic VPN tunnel - CLI
edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action allow
set schedule always
set service any
set vpntunnel Head_Office
end
Firewall policy examples
This section provides some simple, real-world, examples of firewall policies you
can use as a starting point when creating policies for your network.
Blocking an IP address
This example describes how to create a firewall policy to block a specific IP
address. Any traffic from the configured IP address will be dropped at the point of
hitting the FortiGate unit. To block an IP address, you need to create an address
entry before creating a firewall policy to block the address.
Add an Address
First create the address which the FortiGate will identify to be blocked. In this
example, the address will be 172.20.120.29 for the address name of Blocked_IP.
To add an address entry - web-based manager
2Enter a Name of Blocked_IP.
3Enter the IP address and subnet of 172.20.120.29/255.255.255.255.
The subnet is set to 255.255.255.255 to block the specific address. If you wanted
to block the entire subnet enter 172.20.120.0/255.255.255.0.
To add an address entry - web-based CLI
edit Blocked_IP
set subnet 172.20.120.29/32
end
Add a Firewall Policy

With the address added, you can now create the DENY firewall policy which will
prevent any traffic from this IP address from traversing the network. In this policy,
the traffic will be restricted from the IP of an outside source through the external
interface, WAN1.
To add a firewall policy - web-based manager

2Complete the following and select OK:
Source Interface/Zone WAN1
Source Address Blocked_IP
Destination Interface/Zone Internal
Destination Address All
Schedule Always
Service ALL
Action DENY
3Move the firewall policy to the top of the policy list.
To add a firewall policy - web-based CLI
config firewall poliy
edit 1
set srcintf wan1
set srcaddr Blocked_IP
set dstintf Internal
set dstaddr all
set action deny
set schedule always
set service any
end
Scheduled access policies

Firewall schedules control when policies are in effect, that is, when they are on.
You can create one-time schedules which are schedules that are in effect only
once for the period of time specified in the schedule. You can also create recurring
schedules that are in effect repeatedly at specified times of specified days of the
week. For more information on schedules, see “Services”.
This example describes firewall policy rules that:
On weekdays, allow all users to fully access the Internet during lunchtime and
•after business hours
Allow full access to the Internet without any restriction for users from a specific
•IP range, called Admin_PCs
During business hours, allow only access to www.example.com
•and www.example2.com for the other users
•No restriction during the weekend
It should be noted that a Firewall Policy is inactive outside of its schedule and that
the schedule relies upon the date/time that is configured on the FortiGate unit.
In this example all users are connected to the Internal interface and that the
Internet access is connected to WAN1.
Configuring the schedules

Begin by adding the schedule time when the firewall policies take affect.
Note: If the stop time is set earlier than the start time, the stop time will
be considered as the next day. If the start time is equal to the stop time,
the schedule will run for 24 hours.
To configure schedules - web-based manager

1Go to Firewall > Schedule > Recurring, and select Create New.
2Enter the schedule Name of week-end.
Select the days of the week this schedule is employed. In this case, Saturday
3and Sunday.
4Select OK.
5Select Create New
6Enter the schedule Name of lunch-time.
Select the days of the week this schedule is employed. In this case, Monday
7through Friday.
8Select the Start Hour of 12.
9 Select the Stop Hour of 14.
10Select OK.
11Select Create New
12Enter the schedule Name of late evening early morning.
Select the days of the week this schedule is employed. In this case, Monday
13through Friday.
14Select the Start Hour of 18.
15Select the Stop Hour of 08.
16Select OK.
To configure schedules - web-based manager
config firewall schedule recurring
edit week-end
set day sunday saturday
next
edit lunch-time
set end 14:00
set start 12:00
next
edit late evening to early morning
set end 08:00
set start 18:00
next
end
Configuring the IP addresses

Configure the addresses for the administrator computers and the web sites that
can be accessible during the scheduled times.
To configure addresses and web sites - web-based manager
2Enter a Name of Admin_PCs.
3Enter the Subnet/IP Range of 192.168.1.200-192.168.1.254.
4Select OK.
5Select Create New.
6Enter the Name of example.com
7Select the Type of FQDN.
8Enter the FQDN of www.example.com.
9 Select OK.
10Select Create New.
11Enter the Name example2.com
12Select the Type of FQDN.
13Enter the FQDN of www.example2.com.
14Select OK.
To configure addresses and web sites - CLI
edit Admin_PCs
set type iprange
set end-ip 192.168.1.254
set start-ip 192.168.1.200
next
edit example.com
set type fqdn
set fqdn www.example.com
next
edit example2.xom
set type fqdn
set fqdn www.example2.com
next
end
Configuring the firewall policies

With the key components, the schedules and addresses, create the firewall
policies to employ these components and set the schedules to drive what users
can view during the day. There are a total of five required for this example.
To create the firewall policies - web-based manager
2Complete the following for the weekend access policy and select OK:
Source Interface/Zone Internal

Source Address All
Destination Interface/Zone WAN1
Schedule week-end
Service ALL
Action Accept
NAT Select to Enable.
Comments Week-end policy.
3Select Create New.
4Complete the following for the administrator access policy and select OK:

Source Address Admin_PCs
Schedule Always
Service ALL
Action Accept
Comments Admin PCs no restriction.
5Select Create New.
6Complete the following for the lunch-time surfing policy and select OK
:
Source Address All
Schedule lunch-time
Service ALL
Action Accept
Comments Lunch-time policy.
7Select Create New.
8Complete the following for the overnight policy and select OK
:
Source Address All
Schedule late_eveing_early_morning
Service ALL
Action Accept
Comments Late evening to early morning policy.
9 Select Create New.
10Complete the following for the web site access policy and select OK
:
Source Address All
Destination Interface/Zone example.com and example2.com
Schedule Always
Service ALL
Action Accept
Comments Access to the example.com websites policy.
To create the firewall policies - CLI
edit 1
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments week-end policy
set schedule week-end
set service ANY
set nat enable
next
edit 2
set dstintf wan1
set srcaddr Admin_PCs
set dstaddr all
set action accept
set comments Admin PCs no restriction
set schedule always
set service ANY
set nat enable
next
edit 3
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments lunch time policy
set schedule lunch-time
set service ANY
set nat enable
next
edit 4
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments “late evening to early morning policy”
set schedule “late evening to early morning”
set service ANY
set nat enable
next
edit 5
set dstintf wan1
set srcaddr all
set dstaddr example.com example2.com
set action accept
set schedule always
set service ANY
set nat enable
next
end
Troubleshooting
When the firewall policies are in place and traffic is not flowing, or flowing more
than it should, there may be an issue with the one or more firewall policies. This
chapter outlines some troubleshooting tips and steps to diagnose where the traffic
is not getting through, or letting too much traffic through. For more troubleshooting
options and methods, see the Troubleshooting Guide chapter of The Handbook.
This chapter includes the topics:
•Basic policy checking
•Verifying traffic
•Using log messages to view violation traffic
•Traffic trace
•Packet sniffer
Basic policy checking

Before going into a deep troubleshooting session, first verify a few simple settings
in the firewall policy configuration to ensure everything is setup correctly.
For example:
Verify the policy position. The FortiGate unit evaluates each policy in the firewall
policy list for a match until a match is found. When the FortiGate unit finds the
first matching policy, it applies the matching policy’s specified actions to the
packet, and disregards subsequent firewall policies. Is the order of the policies
•affecting traffic flow? For more information see “Policy order”.
Verify that the source and destination ports and their addresses (IP Pools and
•virtual IPs) are selected correctly for the correct subdomain.
Ensure that the NAT check box is selected in the policy. If you selected a virtual
IP as the destination address, but did not select the NAT option, the FortiGate
•unit performs destination NAT rather than full NAT.
Verify that the UTM profiles you selected are properly configured, and that any
•URLs or IP addresses are entered correctly.
Verify that the policy is enabled. In the firewall policy list (Firewall > Policy >
Policy), the Status column indicates whether a firewall policy is enabled or not. To
•be enabled, the check box must be selected.
Verifying traffic
With many firewall policies in place, you may want to verify that traffic is being
affected by the policy. There is a simple way to get a quick visual confirmation
within the web-based manager. This is done by adding a counter column to the
firewall policy table. These steps are only available in the web-based manager.
To view the traffic count on firewall policies
1Go to Firewall > Policy > Policy.
2Select Column Settings in the upper right of the window.
3From Available fields list, select Count.
4Select the right-facing arrow to add it to the Show these fields column.
5Select OK.
As packets hit this policy, the count will appear in the column in kilobytes.
Note: For accelerated traffic, NP2 ports the count does not reflect the real
traffic count. Only the start of a session packet will be counted. For non-
accelerated traffic, all packets are counted.
Using log messages to view violation traffic

Firewall policies are instructions the FortiGate unit uses to decide connection
acceptance and packet processing for traffic attempting to pass through. When the
firewall receives a connection packet, it analyzes the packet’s source address,
destination address, and service (by port number), and attempts to locate a
firewall policy matching the packet. If no Firewall Policy is matching the traffic, the
packets are dropped. Because of this, you do not need to configure a DENY
Firewall Policy in the last position to block the unauthorized traffic.
However, you may want to see what type of traffic is attempting to access the
network. By adding a DENY firewall policy, you can log the dropped traffic for
analysis. Note that storing and viewing the log for denied traffic requires a
FortiAnalyzer, or a Syslog server, or a FortiGate unit with a local hard disk.
To configure logging denied traffic you need to crate the DENY firewall policy and
enable logging. In this example, the firewall policy will deny all HTTP traffic
passing from the internal interface (Internal) to the external interface (WAN1) at all
times.
To configure the logging of violation traffic - web-based manager
2Enter the following:

Schedule always
Service HTTP
Action DENY
3Select Log Violation Traffic.
4Select OK.
To create a basic accept policy for FTP - CLI
edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service http
set logtraffic enable
end
The following is a sample syslog message from a logged traffic violation.
Warning 10.160.0.110 date=2009-09-14 time=10:16:25
devname=FG300A3906550380 device_id=FG300A3906550380
log_id=0022000003 type=traffic subtype=violation pri=warning fwver=040000
status=deny vd="root" src=10.160.1.10 srcname=10.160.1.10 src_port=0
dst=4.2.2.1 dstname=10.2.2.1 dst_port=0 service=8/icmp proto=1 app_type=N/A
duration=0 rule=3 policyid=1 sent=0 rcvd=0 vpn="N/A" src_int="port2"
dst_int="port1" SN=12215 user="N/A" group="N/A" carrier_ep="N/A"
Traffic trace
Traffic tracing enables you to follow a specific packet stream. View the
characteristics of a traffic session though specific firewall policies using the CLI
command diagnose system session, trace per-packet operations for flow tracing
using diagnose debug flow and trace per-Ethernet frame using diagnose sniffer
packet.
Session table
The FortiGate session table can be viewed from the web-based manager or the
CLI. The most useful troubleshooting data comes from the CLI. The session table
in web-based manager also provides some useful summary information,
particularly the current policy number that the session is using.
Sessions only are appear if a session was established. If a packet is dropped,
then no session will appear in the table. Using the CLI command diagnose debug
flow can be used to identify why the packet was dropped.
To view the session table in the web-based manager
1Go to System > Dashboard > Status.
2Select Add Content > Top Sessions.
3In the Top Sessions pane, select Details.
The Policy ID displays which firewall policy matches the session. The sessions
that do not have a Policy ID entry originate from the FortiGate unit.
To view the session table in the CLI
diagnose sys session list
The session table output using the CLI is very verbose. You can use filters to
display only the session data of interest. An entry is placed in the session table for
each traffic session passing through a firewall policy.
Sample output
session info: proto=6 proto_state=05 expire=89 timeout=3600 flags=00000000
av_idx=0 use=3
bandwidth=204800/sec guaranteed_bandwidth=102400/sec traffic=332/sec
prio=0 logtype=session ha_id=0 hakey=4450
tunnel=/
state=log shape may_dirty
statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0 tuples=2
orgin->sink: org pre->post, reply pre->post
oif=3/5 gwy=192.168.11.254/10.0.5.100
hook=post dir=org act=snat 10.0.5.100:1251-
>192.168.11.254:22(192.168.11.105:1251)
hook=pre dir=reply act=dnat 192.168.11.254:22-
>192.168.11.105:1251(10.0.5.100:1251)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0 serial=00007c33
tos=ff/ff
Filter options enable you to view specific information from this command:
diagnose sys session filter <option>
The <option> values available include the following:
clear clear session filter
dport dest port
dst destination IP address
negate inverse filter
policy policy ID
proto protocol number
sport source port
src source IP address
vd index of virtual domain. -1 matches all
Even though UDP is a sessionless protocol, the FortiGate unit still keeps track of
the following two different states:
•UDP reply not seen with a value of 0
•UDP reply seen with a value of 1
The table below shows the firewall session states from the session table:
State Meaning
log Session is being logged.
local Session is originated from or destined for local stack.
ext Session is created by a firewall session helper.
may_dirty Session is created by a policy. For example, the session for ftp
control channel will have this state but ftp data channel will not. This
is also seen when NAT is enabled.
ndr Session will be checked by IPS signature.
nds Session will be checked by IPS anomaly.
br Session is being bridged (TP) mode.
Finding object dependencies

An administrator may not be permitted to delete a configuration object if there are
other configuration objects that depend on it. For example, you may not be able to
delete a user group because that user group is connected with a firewall policy.
This command identifies other objects which depend on or make reference to the
configuration object in question. If a message appears that an object is in use and
cannot be deleted, this command can help identify where this is occurring.
When running multiple VDOMs, this command is run in the Global configuration
only and it searches for the named object both in the Global and VDOM
configuration most recently used:
diagnose sys checkused <path.object.mkey>
For example, to verify which objects are referred to in a firewall policy with an ID of
1, enter the command:
diagnose sys checkused firewall.policy.policyid 1
To verify what is referred to by port1 interface, enter the command:
diagnose sys checkused system.interface.name port1
To show all the dependencies for the WAN1 interface, enter the command:
diag sys checkused system.interface.name wan1
Sample output
entry used by table firewall.address:name '10.98.23.23_host’
entry used by table firewall.address:name 'NAS'
entry used by table firewall.address:name 'all'
entry used by table firewall.address:name 'fortinet.com'
entry used by table firewall.vip:name 'TORRENT_10.0.0.70:6883'
entry used by table firewall.policy:policyid '21'
In this example, the interface has dependent objects, including four address
objects, one VIP, and three firewall policies.
Flow trace
To trace the flow of packets through the FortiGate unit, use the command
diagnose debug flow trace start
Follow the packet flow by setting a flow filter using the command:
diagnose debug flow filter <option>
Filtering options include:
addr IP address
clear clear filter
daddr destination IP address
dport destination port
negate inverse filter
port port
proto protocol number
saddr source IP address
sport source port
vd index of virtual domain, -1 matches all
Enable the output to in the console:
diagnose debug flow show console enable
Start flow monitoring with a specific number of packets using the command:
diagnose debug flow trace start <N>
Stop flow tracing at any time using:
diagnose debug flow trace stop
Sample output
This an example shows the flow trace for the device at the IP
address 203.160.224.97.
diag debug enable
diag debug flow filter addr 203.160.224.97
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow trace start 100
Flow trace output example - HTTP

Connect to the web site at the following address to observe the debug flow trace.
The display may vary slightly:
http://www.fortinet.com
Comment: SYN packet received:
id=20085 trace_id=209 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
SYN sent and a new session is allocated:
id=20085 trace_id=209 func=resolve_ip_tuple line=2799
msg="allocate a new session-00000e90"
Lookup for next-hop gateway address:
id=20085 trace_id=209 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.11.254 via port6"
Source NAT, lookup next available port:
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
direction“
Matched firewall policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
Apply source NAT:
id=20085 trace_id=209 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
SYN ACK received:
id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6, 203.160.224.97:80-
>192.168.11.59:31925) from port6."
Found existing session ID. Identified as the reply direction:
msg="Find an existing session, id-00000e90, reply
direction"
Apply destination NAT to inverse source NAT action:
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
Lookup for next-hop gateway address for reply traffic:
id=20085 trace_id=210 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.3.221 via port5"
ACK received:
msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
msg="Find an existing session, id-00000e90, original
direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from client:
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
line=2727 msg="Find an existing session, id-00000e90,
original direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from server:
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
line=2727 msg="Find an existing session, id-00000e90,
reply direction"
Apply destination NAT to inverse source NAT action:
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
Packet sniffer
The packet sniffer in the FortiGate unit can sniff traffic on a specific Interface or on
all Interfaces. There are 3 different Level of Information, a.k.a. Verbose Levels 1 to
3, where verbose 1 shows less information and verbose 3 shows the most
information.
Verbose levels in detail:
•1Print header of packets
•2Print header and data from the IP header of the packets
•3Print header and data from the Ethernet header of the packets
•4Print header of packets with interface name
•5Print header and data from IP of packets with interface name
•6Print header and data from ethernet of packets with interface
All Packet sniffing commands are in the format:
diagnose sniffer packet <interface> <'filter'> <verbose> <count>
... where...
<interface> can be an Interface name or “any” for all Interfaces. An interface

can be physical, VLAN, IPsec interface, Link aggregated or
redundant.
<verbose> the level of verbosity as described above.
<count> the number of packets the sniffer reads before stopping.
<'filter'> is a very powerful filter functionality which will be described below.
Simple trace example

In this example, the packet sniffer sniffs three packets of all traffic with verbose
level 1 on internal interface
diagnose sniffer packet internal “none” 1 3
The none variable means no filter applies, 1 means verbose level 1 and 3 means
catch 3 packets and stop. The resulting output is
192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764
ack 1949135261 192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918816
ack 1949135261 192.168.0.30.1144 -> 192.168.0.1.22: ack 2859918884
The sniffer has caught some packets in the middle of a communication. Because
the 192.168.0.1 IP address uses port 22 (192.168.0.1.22) this particular sniff is
from a SSH Session.
Simple trace example

In this example, the packet sniffer sniff 3 packets of all traffic with verbose 1evel 1
on internal interface
The none variable means no filter applies, 1 means verbose level 1 and 3 means
catch 3 packets and stop. The resulting output is
192.168.0.30.1156 -> 192.168.0.1.80: syn 2164883624
192.168.0.1.80 -> 192.168.0.30.1156: syn 3792179542 ack 2164883625
192.168.0.30.1156 -> 192.168.0.1.80: ack 3792179543
In this example, the sniffer captures a TCP session being set up. 192.168.0.30
is attempting to connect to 192.168.0.1 on Port 80 with a SYN and gets a SYN
ACK returned. The session is acknowledged and established after the 3-way TCP
handshake.
With information level set to verbose 1, the source and destination IP address is
visible, as well as source and destination port. The corresponding Sequence
numbers is also visible.
Note: If you do not enter a <count> value, for example as above, 3, the
sniffer will continue to run until you stop it.
Verbose levels 2 and 3

Verbose level 2 contains much more information; the IP header as with verbose
level 1 and the payload of the IP packet itself.
The output of verbose 2 is:
192.168.0.1.22 -> 192.168.0.30.1144: psh 2867817048 ack 1951061933
0x0000 4510 005c 8eb1 4000 4006 2a6b c0a8 0001 E..\..@.@.*k....
0x0010 c0a8 001e 0016 0478 aaef 6a58 744a d7ad .......x..jXtJ..
0x0020 5018 0b5c 8ab9 0000 9819 880b f465 62a8 P..\.........eb.
0x0030 3eaf 3804 3fee 2555 8deb 24da dd0d c684 >.8.
.%U..$.....
0x0040 08a9 7907 202d 5898 a85c facb 8c0a f9e5 ..y..-X..\......
0x0050 bd9c b649 5318 7fc5 c415 5a59 ...IS.....ZY
Verbose level 3 includes the previous information as well as Ethernet (Ether
Frame) information. This is the format that technical support will usually request
when attempting to analyze a problem.
Troubleshooting Using Forti OS

Troubleshooting Tool: Using the FortiOS built-in packet sniffer
Article
Introduction
Sniffer Basics
 Basic sniffing command

o Example 1 : Simple trace
o Example 2 : Simple trace
Filter Functionality
 Example 3 : Trace with filters
Introduction
All FortiGate units have a powerful packet sniffer on board. If you know tcpdump
you should feel comfortable using the FortiGate Sniffer.
See the related article "Packet capture (sniffer) tips" for additional sniffer tips.
Scope : All FortiOS

Note : Other Fortinet appliances also providing a CLI sniffer : FortiAnalyzer -
FortiMail - FortiManager
DMZ
|
|
+-----------+
----internal----| FortiGate |---external-----
+-----------+
Sniffer Basics
The packet sniffer "sits" in the FortiGate and can sniff traffic on a specific
Interface or on all Interfaces. There are 3 different Level of Information, also
known as Verbose Levels 1 to 3, where verbose 1 shows less information and
verbose 3 shows the most information. Verbose 4, 5 and 6 would additionally
provide the interface details
Verbose levels in detail:
1: print header of packets

2: print header and data from IP of packets
3: print header and data from Ethernet of packets
4: print header of packets with interface name
5: print header and data from IP of packets with interface name
6: print header and data from Ethernet of packets with interface name
This article walks through some examples and different levels of verbosity to
show the different possibilities for debugging.
Basic sniffing command
All Packet sniffing commands start like:
# diag sniffer packet <interface> <'filter'> <verbose> <count> a
Where...
<interface> can be an Interface name or "any" for all Interfaces.

<'filter'> is a very powerful filter functionality which will be described in more
detail.<verbose> means the level of verbosity as described already.
<count> the number of packets the sniffer reads before stopping.
a introduced in release 3.0 MR6, this setting allows display of absolute time
stamp
Example 1: Simple Trace
Sniff 3 packets of all traffic with verbose Level 4 on internal Interface
# diag sniffer packet internal none 4 3

internal in 192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764 ack
1949135261
1949135261
internal out 192.168.0.30.1144 -> 192.168.0.1.22: ack 2859918884
As you can see we caught some Packets in the middle of a communication.

Because the 192.168.0.1 IP Address uses Port 22 (192.168.0.1.22) we can
assume that we've caught some Packets from a running SSH Session. The
"none" variable means 'no filter applies', "4" means 'verbose 4' and "3" means
'catch 3 packets and stop'.
Example 2: Simple Trace
Sniff 3 packets of all traffic with verbose Level 4 on Internal interface

internal out 192.168.0.30.1156 -> 192.168.0.1.80: syn 2164883624
internal in 192.168.0.1.80 -> 192.168.0.30.1156: syn 3792179542 ack
2164883625
internal out 192.168.0.30.1156 -> 192.168.0.1.80: ack 3792179543
Apparently we caught some more interesting information, just when a TCP

session was being set up. 192.168.0.30 tries to connect to 192.168.0.1 on Port
80 with a syn and gets a syn ack back. Finally the session is acknowledged and
established after the 3-way TCP handshake.
With information level set to Verbose 4, we see a summary of Source and

Destination IP Address, as well as Source and Destination Port. We can also see
the corresponding TCP Sequence numbers.
If you don't enter a <count> value, the Sniffer runs forever until you stop it with
<CTRL C>
Hint: For further investigation it's always a good idea to log to a file. If you're
using Putty (a free SSH client for Windows) you can easily log all Output to a file
which you can search/sort/process.
Verbose 5 and Verbose 6 levels:

Verbose 5 contains much more information
1. The IP Header as we've already seen in Verbose 4

2. The Payload of the IP packet itself
An Output of Verbose 5 looks like this:

1951061933
0x0000 4510 005c 8eb1 4000 4006 2a6b c0a8 0001 E..\..@.@.*k....
0x0010 c0a8 001e 0016 0478 aaef 6a58 744a d7ad .......x..jXtJ..
0x0020 5018 0b5c 8ab9 0000 9819 880b f465 62a8 P..\.........eb.
0x0030 3eaf 3804 3fee 2555 8deb 24da dd0d c684 >.8.?.%U..$.....
0x0040 08a9 7907 202d 5898 a85c facb 8c0a f9e5 ..y..-X..\......
0x0050 bd9c b649 5318 7fc5 c415 5a59 ...IS.....ZY
Notice the in/ out parameter after internal interface that will confirm the direction
of the packet entering or leaving the interface.
Verbose 6, finally, even includes Ethernet (Ether Frame) Information. A script is

available (fgt2eth.pl), which will convert a captured verbose 6 output, into a file
that can be read and decoded by Ethereal/Wireshark. See the end of this article
for details.
Use of absolute time stamp in sniffer trace will report the absolute system time
(no time zone) in packet summary:
# diag sniffer packet internal none 4 2 a
2010-06-02 10:23:17.170751 port1 out arp who-has 192.168.1.110 tell

192.168.1.103
2010-06-02 10:23:19.077409 port1 in arp who-has 192.168.1.120 tell
192.168.1.2
Hint: Below is the format that Technical Support will usually request when
attempting to analyze a problem as it includes full packet content, as well as
absolute time stamp, in order to correlate packets with other system events.
# diag sniffer packet any <'filter'> 6 0 a
Filter Functionality
As already mentioned: diag sniffer includes a powerful filter functionality that will
be described here.
FortiOS tells us:

<filter> filter for sniffer
Syntax: '[[src|dst] host<IP1>] [[src|dst] host<IP2>] [[arp|ip|gre|esp|udp|tcp]
[port_no]] [[arp|ip|gre|esp|udp|tcp] [port_no]]'
If a second host is specified, only the traffic between the 2 hosts will be displayed.
<filter> flexible logical filters for sniffer (or "none").

For example: To print udp 1812 traffic between forti1 and either forti2 or forti3
'udp and port 1812 and host forti1 and (forti2 or forti3)'
Imagine you only want to sniff the traffic from one PC to another PC. Without
Filter the sniffer will display all packets which is far too much and painful to
debug.
Example 3: Trace with Filters
To see what's going on between two PCs (or a PC and a FortiGate),(Don't forget
to put your filter expressions in single quotes ' ' ):
# diag sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1' 1
192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087

192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244686 ack 3483111190
Assuming there is a lot of traffic on the wire, this filter command will only display
traffic (but all traffic) from Source 192.168.0.130 to Destination 192.168.0.1. It will
NOT show traffic to 192.168.0.130 (for example the ICMP reply) because we said
' src host 192.168.0.130 and dst host 192.168.0.1'
As you can see we also captured some other things like ICMP or DNS queries
from a PC. If we're just interested in a specific type of traffic (let's say TCP Traffic
only) we need to change our filter command slightly like this:
# diag sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1
and tcp' 1
192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497

192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498
192.168.0.130.3569 -> 192.168.0.1.23: ack 4238146023
Though ICMP (ping) was also running, the trace only shows the TCP part. As we
can see the Destination is: 192.168.0.1.23 which is IP 192.168.0.1 on Port 23.
Apparently we found a Telnet Session to 192.168.0.1 right during initial setup.
The same the other way around:
# diag sniffer packet internal 'host 192.168.0.130 and icmp' 1

192.168.0.1 -> 192.168.0.130: icmp: echo reply
In this example we're sniffing for ICMP only, to and from 192.168.0.130
Another useful feature is logical combination. Let us assume you want to sniff for
ICMP and TCP only (but not for UDP, ARP, etc). You can combine protocols in
the following manner:
# diag sniffer packet internal 'host 192.168.0.130 and (icmp or tcp)' 1
This sniff will display all tcp or icmp traffic to and from host 192.168.0.30, in
verbose 1 level.
Now we are going to limit the sniffer even more:
We want to sniff traffic between 2 hosts, but only TCP and only port 80.
# diag sniffer packet internal 'host 192.168.0.130 and 192.168.0.1 and tcp port
80' 1
192.168.0.130.3625 -> 192.168.0.1.80: syn 2057246590

192.168.0.1.80 -> 192.168.0.130.3625: syn 3291168205 ack 2057246591
192.168.0.130.3625 -> 192.168.0.1.80: ack 3291168206
192.168.0.130.3625 -> 192.168.0.1.80: psh 2057246591 ack 3291168206
192.168.0.1.80 -> 192.168.0.130.3625: ack 2057247265
A logical "and" is used in this command between 192.168.0.130 and 192.168.0.1

so that only packets containing both these host addresses will be seen.
Even if telnet and ssh is running between the two hosts, we only see port 80 TCP
traffic.
Filtered can be used to display packets based on their content, using

hexadecimal byte position.
Match TTL = 1
# diagnose sniffer packet port2 "ip[8:1] = 0x01"
Match Source IP address = 192.168.1.2:

# diagnose sniffer packet internal "(ether[26:4]=0xc0a80102)"
Match Source MAC = 00:09:0f:89:10:ea

# diagnose sniffer packet internal "(ether[6:4]=0x00090f89) and
(ether[10:2]=0x10ea)"
Match Destination MAC = 00:09:0f:89:10:ea

# diagnose sniffer packet internal "(ether[0:4]=0x00090f89) and
(ether[4:2]=0x10ea)"
Match ARP packets only

# diagnose sniffer packet internal "ether proto 0x0806"
TCP or UDP flags can be addressed using the following:
Match packets with RST flag set:

# diagnose sniffer packet internal "tcp[13] & 4 != 0"
Match packets with SYN flag set:

# diagnose sniffer packet internal "tcp[13] & 2 != 0"
Match packets with SYN-ACK flag set:

# diagnose sniffer packet internal "tcp[13] = 18"
Also attached is the fgt2eth.pl script that will convert a verbose level 3 or 6 sniffer
output, into a file readable and decodable by Ethereal/Wireshark.
The fgt2eth.exe file is also attached to this article, this file is outdated and is not
supported but may provide some guidance.
Note: The attached script is provided "as is", it is not supported by Technical
Support.
$ ./fgt2eth.pl
Version : Dec 19 2014
Usage : fgt2eth.pl -in <input_file_name>
Mandatory argument are :

-in <input_file> Specify the file to convert (FGT verbose 3
text file)
Optional arguments are :

-help Display help only
-version Display script version and date
-out <output_file> Specify the output file (Ethereal readable)
By default <input_file>.pcap is used
- will start wireshark for realtime follow-up
-lines <lines> Only convert the first <lines> lines
-demux Create one pcap file per interface (verbose 6
only)
-debug Turns on debug mode
Trace with filters example
In this example, use the filter option of the sniffer to see the traffic information
between two PCs or a PC and a FortiGate unit. Using the following command:
diagnose sniffer packet internal 'src host 192.168.0.130 and dst host
192.168.0.1' 1
The resulting output is:
192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087
192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189
ack 1325244088 192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42 192.168.0.130.1035 -
> 192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request 192.168.0.130.3426 -
> 192.168.0.1.80: psh 1325244686 ack 3483111190
192.168.0.1.80 ->
192.168.0.130.3426: ack 1325244735 192.168.0.130 -> 192.168.0.1: icmp: echo
request
Assuming there is a lot of traffic, this filter command will only display traffic (but all
traffic) from the source IP 192.168.0.130 to the destination IP 192.168.0.1. It will
not show traffic to 192.168.0.130 (for example the ICMP reply) because the
command included:
'src host 192.168.0.130 and dst host 192.168.0.1'
Additional information such as ICMP or DNS queries from a PC are included. If
you only require a specific type of traffic, for example, TCP traffic only, you need to
change the filter command as below:
diagnose sniffer packet internal 'src host 192.168.0.130 and dst

host 192.168.0.1 and tcp' 1 
The resulting output would be:

192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497
192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498
192.168.0.130.3569 -> 192.168.0.1.23: ack 4238146023
Though ICMP (ping) was also running, the trace only shows the TCP part. The
destination IP is 192.168.0.1.23, which is IP 192.168.0.1 on port 23 - a Telnet
session.
Concept Example: Small Office Network Protection

This document describes an example network and firewall configuration for
a small office-home office (SOHO) or a small- to medium-sized business (SMB).
SOHO and SMB networks, in this case, refer to
•small offices
•home offices
•broadband telecommuter sites or large remote access populations
•branch offices (small- to medium-sized)
•retail stores
Note: IP addresses and domain names used in this document are
examples and are not valid outside of this example.
This document includes

• Example small office network
• First steps
• Configuring settings for Finance and Engineering departments
• Configuring settings for the Help Desk department
• Configuring remote access VPN tunnels
• Configuring the web server
• Configuring the email server
• ISP web site and email hosting
• Other features and products for SOHO
Example small office network

The Example Corporation is a small software company performing development
and providing customer support. In addition to their internal network of 15
computers, they also have several employees that work from home all or some of
the time.
The Example Corporation requires secure connections for home-based workers.
Like many companies, they rely heavily on email and Internet access to conduct
business. They want a comprehensive security solution to detect and prevent
network attacks, block viruses, and decrease spam. They want to apply different
protection settings for different departments. They also want to integrate web and
email servers into the security solution.
The Example Corporation network provides limited functionality for their needs,
including:
•a very basic router to manage the network traffic
•an email server hosted by the Internet Service Provider (ISP)
•a web server hosted by the ISP
•client-based antivirus software with no reliable central distribution of updates
•no secure method of providing remote connections for home-based workers
Network management and protection requirements

The Example Corporation established several goals for planning a network
security solution. Table 3 describes the company’s goals and the FortiGate
options that meet them.
Table 3: Company security goals and FortiGate solutions
Security Policy/Goal FortiGate solution
Protect the internal network Enable IPS, antivirus, and spam filters.
from attacks, intrusions,
viruses, and spam.
Automate network There are several features to make

protection as much maintenance simpler:
as possible to make
management simpler • enable automatic daily updates of antivirus
and attack definitions
• enable automatic “push” updates so that
Fortinet updates the virus list when new threats
occur
• enable FortiGuard web filtering so that web
requests are automatically filtered based on
configured policies, with no required
maintenance
• enable FortiGuard Antispam, an IP address
black list and spam filter service that keeps track
of known or suspected spammers, to
automatically block spam with no required
maintenance
Provide secure access for Configure secure IPSec VPN tunnels for remote
remote workers with static access employees. Use Dynamic Domain Name
or dynamic IP addresses. Server (DDNS) VPN for users with dynamic IP
Use a secure VPN client addresses. Use the FortiClient software to establish
solution. a secure connection between the FortiGate unit and
the home-based worker.
See “Configuring remote access VPN tunnels”.
Serve the web site and Place the web and email servers on the DMZ
email from a DMZ to further network and create appropriate policies.
protect internal data.
See “Configuring the web server”.
Block access by all Enable FortiGuard web content filtering solution.

employees to potentially
offensive web content. See “Configuring web category block settings”.
Severely limit web access Create a schedule that covers business hours,
for certain employees (help create a custom web access solution, and include
desk) during work hours. these in a firewall policy for specific addresses.
See “Configuring settings for the Help Desk

department”.
Topology
Figure 40 shows the The Example Corporation network configuration after
installation of the FortiGate-100A.
Figure 40: SOHO network topology with FortiGate-100A
Features used in this example

The following table lists the FortiGate features implemented in the Example
Corporation example network.
• “Configuring FortiGate network interfaces”

System
• “Configuring DNS forwarding”
• “Scheduling automatic antivirus and attack definition updates”
• “Setting the time and date”
• “Configuring administrative access and passwords”
• “Registering the FortiGate unit”
• “Adding the default route”
Router
• “Removing the default firewall policy”

Firewall
• Adding firewall policies for different addresses and address
groups, see “Configuring firewall policies for Finance and
Engineering”, “Configuring firewall policies for help desk”,
and “Configuring firewall policies for the VPN tunnels”
• Adding addresses and address groups, see “Adding the Finance
and Engineering department addresses”, “Adding the Help Desk
department address”, “Adding addresses for home-based
workers”, “Adding the web server address”, and “Adding the email
server address”
• “Creating a recurring schedule”
• “Configuring remote access VPN tunnels” (IPsec)

VPN

IPS
• “Configuring antivirus grayware settings”

Antivirus
• enabling virus scanning (see Configuring protection profiles)
• “Configuring web category block settings” (FortiGuard)

Web
Filter • “Creating and Configuring URL filters”
• “Configuring FortiGuard spam filter settings”

Spam
Filter
First steps
First steps includes creating a network plan and configuring the basic FortiGate
settings.
• Configuring FortiGate network interfaces
• Adding the default route
• Removing the default firewall policy
• Configuring DNS forwarding
• Setting the time and date
• Registering the FortiGate unit
• Scheduling automatic antivirus and attack definition updates
• Configuring administrative access and passwords
Configuring FortiGate network interfaces
The Example Corporation assigns IP addresses to the three FortiGate interfaces
to identify them on their respective networks. It is important to limit administrative
access to maintain security. The Example Corporation configures administrative
access for each interface as follows:
Interface Administrative access

internal HTTPS for web-based manager access from the internal network,
PING for connectivity troubleshooting, and SSH for secure access to
the command line interface (CLI) from the internal network.
wan1 HTTPS for remote access to the web-based manager from the
Internet.
dmz1 PING access for troubleshooting.
To configure FortiGate network interfaces - web-based manager
2Select the Internal interface row and select Edit:
Addressing mode Manual

IP/Netmask 10.11.101.1/255.255.255.0
Administrative access HTTPS, PING, SSH
3Select OK.
4Select the wan1 interface row and select Edit:

IP/Netmask 172.20.120.141/255.255.255.0
Administrative access HTTPS
5Select OK.
6Select the dmz1 interface row and select Edit:

IP/Netmask 10.20.10.1/255.255.255.0
Administrative access PING
7Select OK.
To configure the FortiGate network interfaces - CLI
edit internal
set ip 10.22.101.1 255.255.255.0
set allowaccess ping https ssh
next
edit wan1
set ip 172.20.120.141 255.255.255.0
set allowaccess https
next
edit dmz1
set ip 10.20.10.1 255.255.255.0
set allowaccess ping
end
Adding the default route

The Example Corporation gets the default gateway address from their ISP.
To add the default route - web-based manager
1Go to Router > Static > Static Route.
2Select the default route and enter the following information:
Destination IP/ Mask 0.0.0.0/0.0.0.0

Device wan1
Gateway 172.20.120.39
Distance 10
3Select OK.
Note: Entering 0.0.0.0 as the IP and mask represents any IP address.
To add the default route - CLI

config router static
edit 1
set device wan1
set gateway 172.20.120.39
set distance 10
end
Removing the default firewall policy

The FortiGate-100A comes pre configured with a default internal -> wan1 firewall
policy which allows any type of traffic from any internal source to connect to the
Internet at any time. Remove this policy to simplify policy configuration and
increase security. By deleting this policy you ensure that any traffic which does not
match a configured policy is rejected, rather than possibly matching the default
policy and passing through the FortiGate unit.
To remove the default firewall policy
1Go to Firewall > Policy > Policy.
2Expand the internal -> wan1 entry.
3Select policy 1 (Source: All, Dest: All) and select Delete.
To remove the default firewall policy using the CLI
delete 1
end
Configuring DNS forwarding

After deleting the default firewall policy, configure DNS forwarding from the
internal interface to allow DNS requests and replies to pass through the firewall.
DNS server addresses are usually provided by the ISP.
To configure DNS forwarding - web-based manager
1Go to System > Network > Options.
2For DNS Settings, enter the primary and secondary DNS server addresses:
Primary DNS Server 239.120.20.1

Secondary DNS Server 239.10.30.31
3Select OK.
To configure DNS forwarding - CLI
config system dns
set autosvr disable
set primary 239.120.20.1
set secondary 239.10.30.31
end
Setting the time and date

Time can be set manually or updated automatically using an NTP server. The
Example Corporation sets the time manually.
To set the time and date - web-based manager
1Go to System > Status and select the Change link for the System Time.
2Select the correct time zone for your location.
3Select Set Time and set the current time and date.
4Select OK.
To configure the time zone - CLI
config system global
set timezone 04
end
To configure the time and date - CLI
execute date <2010-03-31>
execute time <21:12:00>
Registering the FortiGate unit

The FortiGate-100A must be registered with Fortinet to receive automatic
scheduled updates and push updates. Enter the support contract number during
the registration process.
To register the FortiGate unit - web-based manager
Go to System > Status and get the product serial number from the Unit
1Information section or check the label on the bottom of the FortiGate unit.
2Go to http://support.fortinet.com and click Product Registration.
3Fill in all the required fields including the product model and serial number.
4Select Finish.
Scheduling automatic antivirus and attack definition updates

The Example Corporation schedules daily antivirus and attack definition updates
at 5:30 am. They also enable push updates so that critical antivirus or attack
definitions are automatically delivered to the FortiGate-100A whenever a threat is
imminent.
FortiProtect Distribution Network (FDN) services provide all antivirus and attack
updates and information. A virus encyclopedia and an attack encyclopedia with
useful protection suggestions, as well as a daily newsletter, are available on the
web site at http://www.fortiguard.com.
To check server access and enable daily and push updates - web-based
manager
1Go to System > Maintenance > FortiGuard.
2Expand the Antivirus and IPS Options blue arrow.
3Select Allow Push Update.
4Select Scheduled Update.
5Select Daily and select 5 for the hour.
6Select Apply.
Note: If you want to set the update time to something other than the top
of the hour, you must use the CLI command.
To check server access and enable daily and push updates - CLI
config system autoupdate push-update
set status enable
end
config system autoupdate schedule
set frequency daily
set status enable
set time 05:30
end
Configuring administrative access and passwords

The Example Corporation adds an administrator account and password using a
new read-only access profile. This read-only administrator monitors network
activity and views settings. They can notify the admin administrator if changes are
required or a critical situation occurs. The read-only administrator can only access
the FortiGate web-based manager from their own computer or the lab computer.
The admin administrator gets a new password (default is a blank password).
To configure a new access profile and administrator account - web-based
manager
1Go to System > Admin > Admin Profile.
2Select Create New.
3Enter admin_monitor as the Profile Name.
4Select Read Only.
5Select OK.
6Go to System > Admin > Administrators.
7Select Create New and enter or select the following settings:
Administrator admin_2
Password <psswrd>
Confirm <psswrd>
Password
Trusted Host #1 10.11.101.60 / 255.255.255.255 (administrator’s
computer)
Trusted Host #2 10.11.101.51 / 255.255.255.255 (lab computer)
Admin Profile admin_monitor
8Select OK.
To configure a new access profile and administrator account - CLI
config system accprofile
edit admin_monitor
set admingrp read
set authgrp read
set avgrp read
set fwgrp read
set ipsgrp read
set loggrp read
set mntgrp read
set netgrp read
set routegrp read
set spamgrp read
set sysgrp read
set updategrp read
set vpngrp read
set webgrp read
end
config system admin
edit admin2
set accprofile admin_monitor
set password <psswrd>
set trusthost1 192.168.100.60 255.255.255.255
set trusthost2 192.168.100.51 255.255.255.255
end
To change the admin password - web-based manager
1Go to System > Admin > Administrators.
2Select the check box for the admin name and select Change Password.
3Enter the new password and enter it again to confirm.
4Select OK.
To change the admin password - CLI
config system admin
edit <admin_name>
set password <psswrd>
end

Fortinet Basic and Fundamentals

Uploaded by

Copyright:

Available Formats

You might also like

Fortinet Basic and Fundamentals

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fortinet Basic and Fundamentals

Uploaded by

Copyright:

Available Formats

FORTINET

Concept Example: Library Network Protection walks through an enterprise network

The Purpose of a Firewall

FortiGate platforms incorporate sophisticated networking features, such as

At the heart of these networking security functions, is the firewall policies.Firewall

Data Leak Prevention

Spyware is also known as Grayware. Spyware is a type of computer program

Some of the most common ways of grayware infection include:

Blended network attacks

Email filter techniques

Signatures also include characteristics about the attack it describes. These

Traffic shaping attempts to “normalize” traffic peaks/bursts to prioritize certain flows

NAT vs. Transparent Mode

Figure 19: FortiGate unit in NAT mode

How address translation works

Central NAT table

Figure 22: FortiGate unit in transparent mode

•Network > DNS Databases

WCCP cache engine

The FortiGate unit performs three types of security inspection:

•Figure 23: Stateful inspection of packets through the FortiGate unit

Figure 24: Flow inspection of packets through the FortiGate unit

Flow-based inspections typically require less processing than proxy-based inspection,

Figure 25: Proxy inspection of packets through the FortiGate unit

FortiOS functions and security layers

Web Filtering (Antispam) 

Data Leak Prevention 

Packet inspection (Ingress)

IP integrity header checking

Destination NAT (DNAT)

SSL VPN traffic

Flow-based inspection engine

Note: Flow-based antivirus scanning is only available on some FortiGate

Proxy-based inspection engine

Example 1: client/server connection

Initiating connection from client to web server

Example 2: Routing table update

Example 3: Dialup IPsec with application control

Figure 30: FortiGate-60C physical interfaces

Figure 31: FortiGate-60C interfaces on the Dashboard

Figure 32: Configuring the FortiGate-60C ports

Normally the internal interface is configured as a single interface shared by all

Figure 33: FortiGate-3810A

set allowaccess ping

...only PING will be set. In this case, you must type...

set allowaccess https ssh ping

A wireless interface is similar to a physical interface only it does not include a

Note: Some smaller FortiGate units do not support virtual domains.

To enable VDOMs - web-based manager

To enable VDOMs - CLI

To add a VDOM - web-based manager

To assign physical interface to the accounting Virtual Domain - web-based manager

To add a VLAN - web-based manager

To add a VLAN - CLI

Figure 34: Network zones

Caution: Be cautious when employing FQDN firewall addresses. Using a

Geography based addressing

To add a geography-based address - web-based manager

For example, an address of 1.1.1.0, and a netmask of 0.0.0.255