DO NOT REPRINT

FORTINET

Firewall Policies

In this lesson, we will show you how to pass traffic through FortiGate, and explain how that works. At its
core, FortiGate is a firewall, so almost everything that it does to your traffic is linked into your firewall rules.

DO NOT REPRINT
FORTINET

Firewall Policies

After this lesson, you should be able to properly identify the different components used in a firewall policy.
Youll be able to configure firewall policies and arrange them to correctly match traffic.

DO NOT REPRINT
FORTINET

Firewall Policies

Youll also be able to apply UTM and other features through the firewall policy, test your policies, and
monitor traffic passing through them.

DO NOT REPRINT
FORTINET

Firewall Policies

To begin, lets talk about what firewall policies are.

Firewall policies define which traffic matches, and what FortiGate will do if it does.
Should the traffic be allowed? This is decided first based on simple criteria such as the source. Then, if the
policy itself does not block the traffic, FortiGate begins more computationally expensive UTM inspection,
such as application control and web-filtering, if youve chosen it in the policy. Those scans could block the
traffic if, for example, it contains a virus. Otherwise, the traffic is allowed.
Will NAT be applied? Authentication required? Firewall policies also determine that. Once processing is
finished, FortiGate forwards the packet towards its destination.

DO NOT REPRINT
FORTINET

Firewall Policies

When a packet arrives, how does FortiGate find a matching policy? Each policy has match criteria, which
you can define using objects:
Ingress and egress interfaces
Source and destination, by IP address, device ID, or user
Network service(s) (that is, IP protocol and port number)
Schedule
Once FortiGate finds a matching policy, it applies its settings for packet processing. Is antivirus scanning
applied? Will source NAT be applied?
For example, if you want to block incoming FTP to all but a few FTP servers, you would define the
addresses of your FTP servers, and select those as the destination, and select FTP as the service. You
probably wouldnt specify a source (often any location on the Internet is allowed) nor schedule (usually
FTP servers are always available, day or night). Finally, you would set the Action setting to Accept.
This might be enough, but often, youll want more thorough security. Here, the policy also authenticates
the user, scans for viruses, limits the bandwidth consumption, and logs blocked connection attempts.

DO NOT REPRINT
FORTINET

Firewall Policies

Firewall policies appear in an organized list. Its either organized into a section view, or global view.
Usually, it will appear in section view. Each section contains policies for that ingress-egress pair.
Alternatively, you can choose to view your policies as a single comprehensive list, by selecting Global
View at the top of the page.
Policy sequence numbers define the order in which rules are processed. Policy IDs are identifiers. By
default sequence numbers are displayed on the GUI. CLI commands, however, use policy ID: edit <ID>.
This may confuse the administrator in to modifying the wrong policy. To avoid such errors add the policy ID
to the GUI using the column settings.

DO NOT REPRINT
FORTINET

Firewall Policies

In some cases, you wont have a choice of which view, though.

If you use multiple source/destination interfaces or the any interface, policies cannot be separated into
sections by interface pairs some would be triplets or more. So instead, policies are then always
displayed in a single list. It is ordered primarily by the policy sequence number.
To help you remember the use of each interface, you can give them aliases. For example, you could call
port1 WAN. This can help to make your list of policies easier to comprehend.

DO NOT REPRINT
FORTINET

Firewall Policies

Remember that we mentioned that only the first matching policy applies?
Moving your policies into the correct position is important. It affects which traffic is blocked or allowed.
In the applicable interface pairs section, FortiGate will look for a matching policy, beginning at the top. So
usually, you should put more specific policies at the top. Otherwise, more general policies will match the
traffic first, and your more granular policies will never be applied.
Here, were moving a policy that only matches Windows SMB traffic above the more general accept
everything from everywhere policy. Otherwise, FortiGate would always apply the first matching policy
the accept everything policy and never reach the block SMB policy.
How does FortiGate determine if a packet matches a policy? Lets look at that next.

DO NOT REPRINT
FORTINET

Firewall Policies

Each policy matches traffic and applies security by referring to objects such as addresses and profiles that
youve defined.
What about other firewall policy types? Do IPv6 policies exist? Yes. And they use slightly different objects
that are relevant to their type. In this lesson, were discussing IPv4 firewall policies and SSL/SSH
inspection. They are the most common use case.

DO NOT REPRINT
FORTINET

Firewall Policies

To begin describing how FortiGate finds a policy for each packet, lets start with the interface pairs. We
showed them in section view.
Packets arrive on an ingress interface; routing determines the egress. Both interfaces must match the
policys interface criteria in order for it to be a successful match. In each policy, you must select both a
source and destination interface, even it is any.
So if a packet arrives on port4, but you only have policies for between port1 WAN ingress and port2 DMZ,
for example, the packet would not match your policies and therefore be dropped due to the implicit deny
policy at the end of the list, even if the packet did match the egress port of any.
Interfaces may be grouped into logical zones. For example, you could group port7 to port10 as a LAN
zone. This generally simplifies policy configuration, except that an interface in a zone cannot be referenced
individually. So if you must subdivide a zone, dont. Instead, select multiple source and destination
interfaces in the firewall policy.

DO NOT REPRINT
FORTINET

Firewall Policies

The next match criteria that FortiGate will consider is the packets source.
In each firewall policy, you therefore must select a source address object. Optionally, you can refine your
definition of the source by also selecting a user, group and/or a specific device. If you organization allows
BYOD (that is, Bring Your Own Device), then a combination of all three provides a much more granular
match.
In earlier releases of FortiOS 5, sub-policies were used for authentication (also called identity) and device
identification. Also, it was either-or: you could not use both types in the same rule. In 5.2, you can now
use both user and device definitions together, in the same firewall policy.

DO NOT REPRINT
FORTINET

Firewall Policies

Using Source Device Type causes the FortiGate to enable device identification on the source interface(s)
of that policy.

DO NOT REPRINT
FORTINET

Firewall Policies

There are two device identification techniques: agentless and agent-based.

Agentless uses traffic from the device: the MAC address OUI, TCP fingerprint, and HTTP User-Agent:
header. Devices are indexed by their MAC address.
Agent-based uses FortiClient. FortiClient sends information to FortiGate, and the device tracked by its
FortiClient UID.

DO NOT REPRINT
FORTINET

Firewall Policies

Device Definitions shows the list of detected devices. You can also define static entries.
Detected devices are saved to the FortiGates flash. Therefore on restart, the FortiGate knows devices
already identified, and does not have to re-categorize each device.
The user displayed in the device information is just a tag, it cannot be used as a means of identity for an
authentication policy.

DO NOT REPRINT
FORTINET

Firewall Policies

The CLI command diag user device list shows a more detailed listing than User & Devices > Device >
Device Definitions, including the detection method.

DO NOT REPRINT
FORTINET

Firewall Policies

FortiClient devices have a unique id which can be used as an index for the device. This is instead of the
MAC address, which may be problematic when a device has multiple MAC addresses (such as servers or
virtual machines), or where there is no Layer 2 visibility of that device.

DO NOT REPRINT
FORTINET

FortiGate can control FortiClient settings via the profile and registration.

Firewall Policies

DO NOT REPRINT
FORTINET

Firewall Policies

License Information on the FortiGate GUI dashboard shows the registered devices. Windows and Mac
FortiClient installers are also available from this dashboard widget.

DO NOT REPRINT
FORTINET

Firewall Policies

Once a FortiClient registers itself with a FortiGate, youll be able to see its UID on the endpoint control
device list.

DO NOT REPRINT
FORTINET

Firewall Policies

You may configure the default FortiClient profile or add additional profiles. New profiles applied to devices
or users override the default.

DO NOT REPRINT
FORTINET

Once youve configured the settings, FortiGate will send them back to FortiClient.

Firewall Policies

DO NOT REPRINT
FORTINET

FortiClient is the agent-based approach for source device type.

Firewall Policies

DO NOT REPRINT
FORTINET

Firewall Policies

To reduce the total number of firewall policies in RAM, and simplify administration, you can group service
and address objects, then reference that group in the firewall policy, instead of selecting multiple objects
each time or making multiple policies.
You can also group virtual IPs.

DO NOT REPRINT
FORTINET

Firewall Policies

Here, all three source selectors identify the user group, device type, and specific subnet. This would not
have been possible in previous firmware versions.
Remember, user and device are optional objects. They are used here so that the policy is more specific. If
you wanted the policy to match more traffic, you could leave them undefined.

DO NOT REPRINT
FORTINET

Firewall Policies

In earlier releases of FortiOS 5, if traffic matched an identity sub-policy, by default, FortiGate simply
blocked traffic that failed authentication. It would not fall through to try the next authentication rule unless
you had explicitly enabled the option fall-through-unauthenticated.
But in this release, FortiGate uses the fall-through behavior by default.

DO NOT REPRINT
FORTINET

Firewall Policies

Like the packets source, FortiGate also checks the destination address for a match.
Address objects may be a host name, IP subnet or range. If you enter an FQDN as the address object,
make sure that youve configured your FortiGate with DNS settings. FortiGate uses DNS to resolve those
host names to IP addresses, which are what actually appear in the IP header.
Geographic addresses, which are groups or ranges of addresses allocated to a country, may be selected
instead. These objects are updated via FortiGuard.

DO NOT REPRINT
FORTINET

Firewall Policies

Schedules add a time element to the policy. For example, a policy allowing backup software may activate
at night, or a remote address may be allowed for testing purposes and a schedule provides a test window.

DO NOT REPRINT
FORTINET

Firewall Policies

Another criterion that FortiGate uses to match policies is the packets service.
At the IP layer, protocol numbers (for TCP, UDP, SCTP, etc.) and source and destination ports together
define each network service. Generally, only a destination port (that is, the servers listening port) is
defined. Some legacy applications may use a specific source port, but in most modern applications, the
source port is randomly determined at transmission time, and therefore is not a reliable way to define the
service.
For example, the predefined service object named HTTP is TCP destination port 80; HTTPS is TCP
destination port 443. However, the source ports are ephemeral, and therefore not defined.

DO NOT REPRINT
FORTINET

Firewall Policies

Weve just shown several component objects that can be re-used as you make policies. What if you want
to delete an object?
If its being used, you cant. First, you must reconfigure the objects that are currently using it. The GUI
provides a simple way to find out where in the FortiGates configuration an object is being referenced. See
the numbers in the Ref. column? They are the number of places where that object is being used. The
number is actually a link, so if you click it, you can see which objects use it.

DO NOT REPRINT
FORTINET

Firewall Policies

Weve just shown how policies are matched. Lets look a little beyond that now, to slightly before policies,
and to the scans they can use, as well as packet egress.
What happens when a packet first arrives on a FortiGate network interface?
Step 1 is packet ingress.
If a Denial of Service sensor is selected in the policy, it takes effect. Because its applied so early, DoS
packets dont receive other scans, and therefore dont consume unnecessary CPU or RAM.
At the IP layer, the packets CRC is checked for a match with the CRC in the header to make sure that
the packet wasnt corrupted in transmission.
IPSec session-related packets are sent to either the kernel or hardware for payload decryption.
Destination NAT is applied before routing.
If this is a new session, or routing information has changed, FortiGate will make a routing lookup.

DO NOT REPRINT
FORTINET

Firewall Policies

Step 2 is stateful inspection.

Is this traffic destined for the FortiGate itself, such as the administrative GUI, SSL VPN, authentication,
DNS quers, or FortiGuard?
Is this traffic that should be forwarded by a policys established session, or that should be checked for a
policy match?
Does the traffic require a session helper to open dynamic ports, rewrite addresses in application layer
headers, etc.?

DO NOT REPRINT
FORTINET

Firewall Policies

Step 3 is content inspection. FortiGate applies the security profiles that you selected in the policy here.
There are two mains types of content inspection:
Flow-based
Proxy-based
The order of inspection is important. The next step applies only if traffic is not blocked by the previous step.

DO NOT REPRINT
FORTINET

Firewall Policies

Step 4 is packet egress.

Should FortiGate route the packet to an IPsec VPN virtual interface, before it is rerouted to a physical
interface?
Should FortiGate apply source NAT?
Which interface should the packet depart from?

DO NOT REPRINT
FORTINET

Firewall Policies

If you enable session starts, FortiGate will create a traffic log when the session begins. But remember that
increasing logging decreases performance. So use it only where necessary.
Once a firewall policy closes an IP session, if you have enabled logging in the policy, FortiGate will
generate traffic logs.
During the session, if a security profile detects a violation, FortiGate will record the attack log immediately.
To reduce the amount of log messages generated and improve performance, you can enable a session
table entry of dropped traffic. This option is in the CLI, and is called ses-denied-traffic.
If the GUI option session starts is not displayed, your FortiGate device does not have internal storage. This
option is in the CLI, regardless of internal storage, and is called set logtraffic-start enable.

DO NOT REPRINT
FORTINET

Firewall Policies

Once the first packet assuming it is not dropped establishes an IP session, FortiGate enters it in its
session table. If subsequent packets are received before the session times out, hashing function lookups
up the applicable policy for scans or NAT that it should apply to incoming packets.
You can use the monitor section in order to determine how much traffic is matching each firewall policy.

DO NOT REPRINT
FORTINET

Firewall Policies

The session table can also be viewed from the CLI.

Firewall performance of connections per session and maximum number of connections are indicated by
the session table. But keep in mind that if your FortiGate contains FortiASIC NP chips designed to
accelerate processing, without loading the CPU, this may not be completely accurate. The session table
reflects what is known to and processed by the CPU.

DO NOT REPRINT
FORTINET

Firewall Policies

Since the session table has a finite amount of RAM that it can use on your FortiGate, adjusting the session
time to live (TTL) can improve performance. There are global default timers, session state timers, and
timers configurable in firewall objects.

DO NOT REPRINT
FORTINET

Firewall Policies

In this example, you can see the session TTL, which reflects how long FortiGate can receive no packets
until it will remove the session from its table.
Proto_state for TCP is taken from its state machine, which well talk about next.
Traffic shaping manages your bandwidth. Traffic counters are the overall counters for the session, and
determine how much data was sent and received.
NAT actions are also tracked.

DO NOT REPRINT
FORTINET

Firewall Policies

In the previous slide, remember that the session table contained a number that indicated the connections
current TCP state. These are the states of the TCP state machine. They are single digit values, but
proto_state is always shown as two digits. This is because when proxy based inspection is used, which is
discussed later, two connections are establish with the proxy: one to the client, and one to the server. If
there are too many connections in the SYN state for long periods of time, this indicates a SYN flood, which
you can mitigate with DoS policies.
UDP is a stateless protocol. So it doesnt technically have states like TCP. However, the session table
does use the state column to track unidirectional UDP as state 0, and bidirectional USP as state 1.

DO NOT REPRINT
FORTINET

Firewall Policies

Before looking at the session table, first build a filter. To look at our test connection you can filter on dst
10.200.1.254 and dport 80.

DO NOT REPRINT
FORTINET

Firewall Policies

Here we see the corresponding session table entry. Here you can see the routing and NAT actions that
apply to the traffic.

DO NOT REPRINT
FORTINET

Firewall Policies

In addition to security scans, firewall policies also determine what network address (NAT) or port address
translation (PAT) to apply to each packet.
NAT and PAT, also known as NAPT, translate internal, typically private, IP addresses, to external, typically
public or Internet, IP addresses.
In FortiOS, NAT and traffic forwarding are configured in the same firewall policy. However, diagnostics
clearly show NAT and forwarding as separate actions. The NAT option in a firewall policy, and IP Pools,
are source NAT settings and objects. Virtual IPs are destination NAT objects.

DO NOT REPRINT
FORTINET

Firewall Policies

The default source NAT option uses the egress interface address. This is a many-to-one NAT. In other
words, port address translation is used and connections are tracked using the original source address and
source port combinations, and allocated source port. This is the same behavior as the overload IP Pool
type, discussed later.
Optionally, you may select fixed port in which case the source port translation is disabled. With fixed port,
if two or more connections require the same source port for a single IP address, only one connection can
establish.

DO NOT REPRINT
FORTINET

Firewall Policies

If you use an IP pool, the source address is translated to an address from that pool rather than the egress
interface address. The larger the number of addresses in the pool, the greater the number of connections
can be supported.
The default IP pool type is overload, here there is a many-to-one/few relationship and port translation is
used.

DO NOT REPRINT
FORTINET

Firewall Policies

One-to-one differs in the sense that there is a single mapping of an internal address to external address.
Port address translation is not required in this case. See the circled example showing the same source
ports on ingress and egress?
Mappings are not fixed. They are allocated on a first-come first-serve basis. If there are no more
addresses available, a connection will be refused as shown in the debug flow.

DO NOT REPRINT
FORTINET

Firewall Policies

This example uses a fixed port range IP pool.

The internal address range 10.0.1.10-10.0.1.11 maps to the external address range 10.200.1.7-10.200.1.8.
This configuration provides an explicit relationship between internal and external ranges, and disables port
address translation.

DO NOT REPRINT
FORTINET

Firewall Policies

These two CLI outputs illustrate the behavior difference between the port block allocation type, and the
default overload type.
Using hping, a rogue client generates many SYN packets per second. In the first example, the port block
allocation type limits the client to 64 connections for that IP pool. Other users will not be impacted by the
rogue client.
In the second example, the overload type imposes no limits, and the rogue client uses many more
connections in the session table. Other users will now be impacted.

DO NOT REPRINT
FORTINET

Firewall Policies

Virtual IPs (VIPs) are destination NAT objects. For sessions matching a VIP, the destination address is
translated: usually a public Internet address is translated to a servers private network address. Select
VIPs in the firewall policys destination address field.
The default VIP type is static NAT. This is a one-to-one mapping which applies for incoming and outgoing
connections. That is, an outgoing policy with NAT enabled would use the VIP address instead of the
egress interface address. This behavior, however, can be overridden by use of an IP pool.
The static NAT VIP can be restricted to forward only certain ports. For example, connections to the
external IP on port 8080 map to the internal IP on port 80.
From the CLI, you can select the NAT type to load-balance and server-load-balance. Plain load balancing
distributes connections from an external IP address to multiple internal addresses. The later builds on that
mechanism, using a virtual server and real servers, and provides session persistence and server
availability check mechanisms.
VIPs should be routable to the external facing (ingress) interface. FortiOS responds to ARP requests for
VIP, and IP Pool, objects. ARP responses are configurable.

DO NOT REPRINT
FORTINET

Firewall Policies

In this example, connections to the VIP 200.200.200.222 are NATed to the internal host 10.10.10.10.
Because this is static NAT, all NATed outgoing connections from 10.10.10.10 will use the VIP address in
the packets destination field, not the egress interfaces address.

DO NOT REPRINT
FORTINET

Firewall Policies

For feature completeness, you can use a central NAT table. This is disabled by default. To enable it from
the GUI, go to System > Config > Features. In the CLI, use:
conf sys global
set gui-central-nat-table enable
end
In this case, the source NAT action is defined in a central table. If no central NAT rule exists, then the
default action of destination interface address is used.
Central NAT rules also allow control over source port usage.

DO NOT REPRINT
FORTINET

Firewall Policies

Some application layer protocols are not fully independent of the lower layers such as the network or
transport layer. If the session helper detects a such a pattern, it may make changes to the application
headers or create expected secondary connections.
A good example is where an application has both a control and a data/media channel, such as with FTP.
Firewalls will typically allow the control channel and rely on the session helpers to handle the dynamic
data/media transmission connections.
When more advanced application tracking and control is required, an Application Layer Gateway (ALG)
can be used. The VoIP profile is an example of an ALG.

DO NOT REPRINT
FORTINET

Firewall Policies

In this example, the media recipient address in the SIP SDP payload is modified to reflected the NATed IP
address.

DO NOT REPRINT
FORTINET

Firewall Policies

Traffic shaping (also called quality of service (QoS)) can be applied in firewall policy and used to manage
the bandwidth used by each service or application. FortiGate can count the packet rates of ingress and
egress to police traffic. Note that these apply equally to TCP and UDP, and UDP protocols may not
recover as gracefully from packet loss.
ToS/DSCP flags, if used, can map packets to a specific transmission queue. For additional information,
see the Traffic Shaping FortiOS Handbook.

DO NOT REPRINT
FORTINET

Firewall Policies

Two types of traffic shapers can be configured: Shared and Per-IP.

A shared shaper applies a total bandwidth to all traffic using that shaper: The scope can be per-policy or
for all policies referencing that shaper.

DO NOT REPRINT
FORTINET

Firewall Policies

FortiGates equipped with Network Processors (NP) offload packet handling from the CPU. For each new
IP session, the first packet always goes to the CPU. If the session can be offloaded to an available NP,
the kernel sends session information to the NP. All subsequent packets in that session are forwarded by
the NP and not the CPU, so their transmission is accelerated. When the last packet is sent or received,
such as a TCP FIN or TCP RST signal, the NP returns this session to the CPU, which handles tear down.
Non-eligible sessions remain on the CPU. Typically, this includes policies that have a security profile
enabled. IP fragments are also non-eligible.
diagnose CLI commands, such as diag packet sniff and diag debug flow, run on the CPU. They will
not show packets handled by an NP. To ensure accurate output for these commands, you can temporarily
disable NPU offload in each firewall policy so that the packets are handled by the CPU and therefore
received by the troubleshooting command.

DO NOT REPRINT
FORTINET

Firewall Policies

As a UTM, one of the most important features that a firewall policy can apply is security profiles such as
IPS and antivirus. These profiles inspect each packet in traffic flows where the session has already been
conditionally accepted by the firewall policy.
When inspecting traffic, FortiGate can use one of two methods: flow- or proxy-based. Different security
features are supported by each type.

DO NOT REPRINT
FORTINET

Firewall Policies

In proxy-based scans, were typically meaning a transparent proxy. Its called transparent because at the
IP layer, FortiGate is not the destination address, yet FortiGate intercepts the traffic anyway.
In TCP connections, FortiGates proxy generates the SYN ACK to the client and completes the three-way
handshake with the client before creating a second, new connection to the server. If the payload is less
than the oversize limit, the proxy buffers transmitted files/email for inspection before continuing
transmission. The proxy analyzes and may change headers such as HTTP Host: and URI for web
filtering. If a security profile decides to block the connection, the proxy can send a replacement message to
the client.
This adds latency to the overall transmission speed.

DO NOT REPRINT
FORTINET

Firewall Policies

Proxy options affect the content inspection proxy. Settings include port numbers, oversize file action and
threshold, and client comforting (where the proxy transmits packets slowly while it continues to buffer and
scan).

DO NOT REPRINT
FORTINET

Firewall Policies

How are flow-based scans different?

There is no proxy. If you are familiar with the TCP flow analysis of Wireshark, then that is essentially what
the flow engine sees. Packets are buffered, analyzed, and forwarded as they are received. The same
signatures used for proxy-based techniques apply to flow-based, therefore the detection rate is potentially
the same. Original traffic is unaltered consequently advanced features which modify content, such as safe
search enforcement, are not supported.

DO NOT REPRINT
FORTINET

Firewall Policies

A SSL/SSH inspection profile contains settings for decrypting these protocols, which is required in order to
scan their content. Otherwise, viruses could be transmitted via HTTPS or SMTPS, for example, without
detection.
For SSH, inspection allows the FortiGate to intercept connections and control protocol commands. For
example, using an SSH tunnel, a client could port forward any other protocol across an SSH connection.
Using an SSH profile, FortiGate can block the Port-Forward command.

DO NOT REPRINT
FORTINET

Firewall Policies

When troubleshooting firewall policies, you need to understand how the traffic should flow.
Typically there are many firewall policies. What is the ingress/egress interface? What is actually happening
to the traffic/application? Is it slow? Is it failing to connect? These can help to define which
troubleshooting steps you need to take.

DO NOT REPRINT
FORTINET

Firewall Policies

One of the most fundamental network debugging tools is packet capture, or sniffing.
The syntax of the CLI command is diag sniff packet interface filter level. The interface is the name of the
physical or logical interface; if your account has the access profile super_admin, you can specify the any
interface. The filters are similar to tcpdump on Linux. For level, you can choose from 1 to 6 depending
on your requirements.
The only output options are the payloads in ASCII and Hexadecimal format. To completely decode the
packet and view its content, save the output to a plain text file, convert it to .pcap format, then open it with
Wireshark.

DO NOT REPRINT
FORTINET

Firewall Policies

Here are some general examples. Much more can be learnt by reading the man page for tcpdump.

DO NOT REPRINT
FORTINET

Firewall Policies

If your model of FortiGate has internal storage, you can capture packets from the GUI. Looking at the
content of the packets can help you to see what is abnormal. The options in the GUI are the same as
those from the CLI. To run a trace, specify a source interface and a filter.
What is the main advantage over the CLI? You can download the output in a file format which can be read
by Wireshark, without having to use a conversion script.
Any packet capture filter should be very specific in order to avoid writing large amounts of data to disk
which will affect performance.

DO NOT REPRINT
FORTINET

Firewall Policies

Before, we mentioned that a packet capture does not show why FortiGate may have dropped a packet.
This is the purpose of the packet flow.
This is an example of diag debug flow. The first lines enable it, and enable it to print to console. Next,
the filters define which IP address and port numbers to trace the flow fow; addr implies both source and
destination, and port 80 typically captures HTTP.

DO NOT REPRINT
FORTINET

Firewall Policies

Here is output for the previous example, for the three way handshake.
Virtual domain root receives a packet: the protocol is TCP; destination port 80; source IP 10.0.1.10;
destination IP 10.200.1.1. The packet is received on interface port3.
FortiOS identifies this a new session because it does not match any entries in its current session table.
FortiOS performs a routing lookup, as this the first packet of the connection; gateway 10.200.1.254 (in
this case the destination) is found on interface port1.
For the firewall policy match, the interfaces are port3 to port1. The hashing function is used for the
policy lookup.
The connection matches policy ID 1 with source NAT enabled. The source address and port for all
packets in this connection will NAT to 10.200.1.1:39738.
The packet is sent to IPS module. In this case, the IPS security profile is enabled on the firewall policy.
Next, the reply (SYN/ACK) is received. This is identified as reply traffic for an existing connection. For
the first reply packet, a routing lookup occurs.
Next, the client send the ACK. This is identified as belonging to an existing connection.

DO NOT REPRINT
FORTINET

Firewall Policies

The retransmission of SYN packets is a good indicator of the firewall blocking a connection. However, we
dont know for sure. We could look at the traffic logs, if logging was enabled for the deny policy. What else
could we use, though? The packet flow.

DO NOT REPRINT
FORTINET

Firewall Policies

Combining debug flow and packet sniffer, we now see which firewall action is blocking this traffic.

DO NOT REPRINT
FORTINET

To review, heres all the topics we covered in this lesson.

Firewall Policies