Sie sind auf Seite 1von 18

Check the High Availability state

to get the High Availability state info with get command:

myfirewall1 # get sys ha status

to create a new firewall policy

config firewall policy

edit 1
set srcintf “internal”
set dstintf “wan1″
set srcaddr “all”
set dstaddr “all”
set action accept
set schedule “always”
set service “ANY”
set nat enable

myfirewall1 # show full-configuration system ha

with the diagnose command the state again:

myfirewall1 # diagnose sys ha status HA information Statistics

myfirewall1 # diagnose hardware deviceinfo nic internal

4.0 VPN Troubleshooting

The most significant part for vpn is the time on the devices. The check the time use the
following command:
myfirewall1 # get sys status
Change the tunnel state
Bring up a vpn tunnel manually. No traffic required.
myfirewall # diag vpn tunnel up phase2-name phase1-name
Shut down a vpn tunnel manually.
myfirewall # diag vpn tunnel down phase2-name phase1-name
Check the tunnel state
If there is no SA that means the tunnel is down and does not work. To see if the tunnel is up
we need to check if any SA exist.
To see if the tunnel is up you can use the diagnose vpn tunnel list name or diagnose vpn
tunnel dumpsa command.
Tunnel state is down
Tunnel does not exist if there is no output of the commands below:
myfirewall1 # diagnose vpn tunnel list name myphase1 list ipsec tunnel by names in vd 0
with the dumpsa command:
myfirewall1 # diag vpn tunnel dumpsa
The output of the command below shows zero sa (no security association)
myfirewall3 # diagnose vpn tunnel stat

Tunnel state is up
Informations from the output of the command below:
– vpn peers
– encrypted traffic (source and destination)
– traffic counters for encrypted traffic
– SPI for encrypt and decrypt
– Encryption method
In the following output the second tunnel with the name fortigw-311b-wlan-ph2 is down.
with the diagnose command:
myfirewall1 # diagnose vpn tunnel stat
Check packet counters for the tunnel
To see if the encryption and decryption of the packages works use 2 or more times the
diagnose vpn ipsec status or the diagnose vpn tunnel list command and compare the values.
On the second and third outputs the counter should show larger number.

myfirewall1 # diag vpn tunnel list

5.0 sniffertrace
The basic command is “diagnose sniffer packet”, after that you have to define the interface*
(or the keyword any):
myfirewall1 # diagnose sniffer packet the network interface to sniff (or "any")
*Looks like you cannot filter explicitly on tunnel interface, you have to use any in that case
and define a filter string.
And the tcpdump like filter string (or the keyword none):
myfirewall1 # diagnose sniffer packet any
diagnose sniffer packet port 1

6.0 View logging on cli

There are some fields that you wont ever see in webui as in the column setting you cannot
choose them. Just an example for this is a false pre-shared key, the field that tells you what
the problem is, called “error_reason”.
The buffer size is limited and if the buffer is full the old logs will be overwritten.
To check your buffer size issue the following command:
myfirewall # get log memory global-setting
Configure logging
To view the logs on the CLI issue the following commands (it is better to use a syslog server as
checking the logs from memory, it is slow).
myfirewall # execute log filter device memory
myfirewall # execute log filter start-line 1
myfirewall # execute log filter view-lines 10
myfirewall # execute log filter category event
Check if that is correct for you.
myfirewall # execute log filter dump

7.0 Backup and Restore

Backup command with tftp server:
myfirewall # execute backup full-config tftp <full-config-filename> <tftp server ip>
With an example:
myfirewall1 # execute backup full-config tftp myfirewall1_full_config

Restore command with tftp server:

myfirewall # execute restore config tftp <full-config-filename> <tftp server ip>
Example Restore:
myfirewall1 # execute restore config tftp myfirewall1_full_config

diagnose hardware deviceinfo nic

 Equivalent to show interface

diagnose system session list

 Show the excisting translations

diagnose system session clear

 Clears all xlate/translations

diagnose ip arp list

 Shows the arp table of connected hosts

diagnose system top

 Show System Processes running with PIDs

diagnose system kill 9 <id>

 Kill the specific PID

diag test auth ldap <server_name> <username> <password>

 Ldap test query from the Forti to the AD

diag debug enable” – This will enable debug logging

“diag debug disable” – This will turn off debug logging

“diag debug reset” – This will reset the debug logging

“diag debug flow show console enable” – This will output the debug logs to the CLI
screen so they can been seen

“diag debug flow filter addr <IP address>” – This will show the flow of traffic from a
particular IP address

“diag debug flow filter clear” – This will clear the logs for any flow filter debug command

Let’s say you wanted to see if a particular node was sending pings successfully on any

“diag sniffer packet any ‘icmp and host x.x.x.x’ 4” – If pings are successfully hitting the
appropriate interface, you will see the output on the CLI console

Use “diagnose sniffer packet” commands to capture packets traversing the Fortigate firewall.
diagnose sniffer packet <interface> <filter-argument> <debug level> <packet-count>
– Interface: specify ingress or egress flow interface or just “any” port
– use “filter” to specify source and destination ip/port
– use “packet-count” to specify how many packets to capture
– debug level is 1 to 6 (6 more detailed)
1. capture all traffic from host

2 diagnose sniffer packet any "host" 2
1. capture all UDP port 53 from and to host

2 diagnose sniffer packet port2 "udp and port 53 host" 5
1. capture all SSH traffic from and to host

2 diagnose sniffer packet any “host or host and tcp port 22” <b>4</b>
1. capture all http traffic from host towards
execute start-line:
log filter 15
dump view-lines:

2 diagnose sniffer packet internal “src host and dst host and port 80”


Use “diagnose system session” commands to show all sessions and translations on the
fortigate platform.
diagnose system session filter <filter-argument > : filter session based on destination
diagnose system session list : show sessions
diagnose system session clear : clear filter


Use “diagnose debug flow” commands to verify how traffic is being accepted or denied by a
security policy:
diagnose debug enable
diagnose debug flow show console enable
diagnose debug flow filter “host x.x.x.x”
diagnose debug flow show function-name enable
diagnose debug flow trace start “N” : (where N is the number of flow to show)

Output example:

id=36871 trace_id=1132 msg="vd-root received a packet(proto=17, from
id=36871 trace_id=1132 msg="allocate a new session-00012042"
id=36871 trace_id=1132 msg="find a route: gw- via wan1"
id=36871 trace_id=1132 msg="find SNAT: IP-, port-54409"
id=36871 trace_id=1132 msg="Allowed by Policy-5: SNAT"
id=36871 trace_id=1132 msg="SNAT>"
log filter
log filter Sets the start-line to Line 1
the log
view-lines Sets the number of lines to be displayed as 100
100 Sets the number of lines to be checked as 50000
log filter
Available categories:
16: netscan
10: application control
9: dlp
6: content
5: spam
4: ids
3: webfilter
2: virus
1: event
0: traffic
Displays the
log based on
execute log display
the configured
Sets the
category FORTIGATE-FW-1 # get
as system ha status
execute Model: 300
log filter Replace
category 0 "0" with Mode: a-p
the Group: 0
category Debug: 0
for which Displays the ses_pickup: enable,
log is
required high ses_pickup_delay=disable
Within a cluster, to determine the primary
availability Master:150 FORTIGATE-
get system ha status number of the primary firewall. Then use "
status of the FW-1 AB-
number of current firewall.
Fortigate 5KB3D10700369 1
firewall. Slave :200 FORTIGATE-
FW-2 AB-
5KB3D10800490 0
number of vcluster: 1
vcluster 1: work
Master:0 AB-
Slave :1 AB-
sslvpn-enable : enable
sslv3 : enable
dns-server1 :
dns-server2 :
reqclientcert : disable
sslv2 : disable
force-utf8-login : disable
Displays the
renegotiation: disable
get vpn ssl settings SSL VPN
servercert : self-sign
algorithm : default
idle-timeout : 300
auth-timeout : 28800
wins-server1 :
wins-server2 :
url-obscuration : disable
http-compression :
port : 443

config firewall vip

edit “vip_172.16.1.50”
Displays the
set extip
show firewall vip virtual IP
set extintf “port10”
set mappedip

config vpn ipsec phase1-

edit “test_vpn”
set interface “port10”
set dhgrp 2
set keylife 3600
set proposal 3des-
sha1 aes128-sha1
Shows the set authmethod psk
phase 1 set dpd disable
show vpn ipsec phase1- interfaces set ike-version 1
interface configured for set ip-version 4
IPSec VPN set keepalive 10
tunnel set mode main
set nattraversal
set remote-gw
set psksecret ENC
config vpn ipsec phase2-
edit “test_vpn_phase2”
set phase1name
Shows the
phase 2
set proposal 3des-
show vpn ipsec phase2- interfaces
sha1 aes128-sha1
interface configured for
set keepalive enable
set pfs enable
set src-addr-type ip
set dst-addr-type ip
set keylifeseconds
set src-start-ip
set dst-start-ip
This command manually activates the phas
Activates the
diagnose vpn tunnel up
phase 2 tunnel
Example: diagnose vpn tunnel up certvideo

The commands below can be used to configure syslog for Fortinet

config log syslogd setting

unset override
set status enable
set port 1300
set server
set csv enable
set reliable disable
set facility local7

Firewall policy commands

3) Open a command prompt on your machine and ping a web address, example: ping

4) Review the output on the FortiGate CLI

5) You’ll see various information about which connection you’re using along with the Policy

Step 2 – Reviewing the Firewall Policy ID

1) Go to the Policy section of your FortiGate

2) Right click the Column Bar and verify ID is selected. Seq.# is not the Policy ID.

3) You can filter the ID for your specific # or go down the list to identify the Policy ID you
found in Step 1.

he IPS engine can be restarted & updated from the CLI by executing the below commands.

You may want to restart the IPS engine if it crashes or to reduce CPU usage.

1. Log into the CLI

2. Restart the ipsmonitor application
 diag test application ipsmonitor 99
3. Update the ipsengine
 exec update-ips
4. Check running processes for ipsengine
 diagnose sys top
A null route or blackhole route is a network route that goes nowhere. Matching packets are
dropped rather than forwarded.

Null routes are often used on high-performance core routes to mitigate large-scale denial-
of-service attacks before the packets reach a bottleneck. There is virtually no performance
impact which is why this is commonly used.

Blackhole filtering can also be abused by malicious attackers on compromised routers to

filter out traffic destined to a certain address.

Enabling blackhole or null route is only available through the CLI of a FortiGate.

Steps to enable a blackhole route:

1. Connect to the CLI
2. Enter the static route configuration:
A. config router static
3. Create a new entry
A. edit “next available # in sequence”
4. Enable blackhole
A. set blackhole enable
5. Set Distance
A. set distance 100
6. Configure IP address you’d like to block
A. set dst “ip address” “mask”

SSL Inspection inadvertently blocks Citrix screen sharing sessions like Gotomeeting and
Gotoassist. This behavior is experienced when SSL Inspection is turned on in the Web
Filtering UTM Control & the firewall policy.

A workaround can be implemented to allow these sessions to connect. Version 5.2 of

FortiOS is revamping the way SSL Inspection is handled and this should not be needed if
you are running 5.2.

Follow the below steps for versions prior to 5.2.

1) Go to Security Profiles > Web Filter > Profiles, select your Web Filter profile.

2) Turn on “Enable Web Site Filter”

3) Add two new wild car entries. You are telling the FortiGate to bypass UTM filtering for
any web pages that contain “gotomeeting” or “citrixonline” in it’s name.

FortiGate – Safely Restarting a HA Cluster

Your FortiGate units should be restarted regularly to ensure stability and maintain

You can safely restart a FortiGate HA Cluster by following the below steps:

Restarting the Master

1) Connect to the CLI

2) run “exec reboot” – This will restart the Master.

Restarting the Slave
1) Connect to the CLI

2) Execute the below commands

# exec ha manage (id of slave) – This is to switch to the slave, press “?/tab” to check
options and choose the slave unit.

get sys status – This is to check whether you are in the Slave or Master

exec reboot

1) Take a fresh backup of your config file prior to restarting.

2) Restart your FortiGate before a Firmware Upgrade to ensure a smooth upgrade.

3) Configure temporary out of band access to the unit if you are restarting remotely.

FortiGate – SSL VPN: DNS Resolution

The key to a smoother user experience is to add the DNS Suffix into the SSL VPN
configuration. This will allow access to resources without having to know the Fully Qualified
Domain Name (FQDN).

The below steps outlines how you can enable DNS Resolution across a FortiGate SSL VPN

Step 1
Set the DNS Server IP Addresses in the Advanced settings of the SSL VPN Config.
Step 2
Launch the CLI and enter the following commands to add a DNS Suffix to the VPN Config:

config vpn ssl settings

set dns-suffix “”


Step 3
Connect to your SSL VPN connection and verify you can ping hosts without requiring the

Happy Connecting!!

FortiGate – UTM Troubleshooting: Slow or Blocked

Web Pages

Turning on various UTM features on a FortiGate unit may inadvertently increase latency or
block access to certain webpages.

Websites are becoming increasingly integrated with Social Media, File Sharing Services and
other categories which could be blocked by your security policy.

The below steps demonstrate how you can use the debugging tools in Internet Explorer to
diagnose slow loading web pages.

Step 1
Launch Internet Explorer and press F12 to open the Developer Tools. A box will appear at
the bottom of IE.
Step 2
Select the Network Tab and click Start Capturing. This will capture all network activity that
occurs when visiting a web page.

Step 3
Navigate to the website you are trying to diagnose and launch the page. You should
immediately start seeing data in the capture field. URL’s with a result of “Pending” instead of
“Get” usually points to it being blocked or intercepted. The Timing tab illustrates which
sections of the web page took the longest to load and its latency.
In the example below we are navigating to Social Media is blocked on the
FortiGate Unit. You can see that the Facebook connections are in the “pending” state due
to it being intercepted by the FortiGate.
Following the above steps will help you diagnose these issues very quickly and add
exception rules to enhance user experience!

Happy capturing!

FortiGate – URL Filtering: Exempt vs. Allow vs.

Monitor vs. Block
URL Filtering is a powerful feature on a FortiGate Firewall to prevent users from visiting dangerous or
inappropriate web sites. The 4 options available to filter a website is explained below.

Prevents users from accessing the website by delivering a warning message when access is denied.

Allows user to access a certain website. Traffic is passed on to additional Fortinet security functions for inspection
as needed.

Allows users to access a certain website. Web site traffic is allowed to bypass additional Fortinet security
functions. A log message will be generated each time a matching traffic session is established.
Allows a user to access a certain website. Web site traffic is allowed to bypass additional Fortinet security
functions. Exempt bypasses the entire URL connection and does not require re-scanning while the connection
remains open.
Example -

URL Filter Entry: – Passed without scanning – Passed without scanning – Passed without scanning

 Use Monitor when you are unsure if Exempt is needed.
 Use Exempt only if you trust the content of the site you exempt, otherwise there may be a security risk.

Allow, Block, Exempt, Fortigate, Fortinet, Monitor, URL Filtering, UTM

FortiGate – HA: Active-Active vs. Active-Passive

Posted on April 12, 2014 by Nawaz Alli in Fortinet 4 Comments

There are two modes available to you when configuring HA for a FortiGate Cluster, Active-Active or Active-
Passive. The section below outlines the main differences between the two modes.

 Load balances UTM (Antivirus, IPS, Web Filtering, etc.) packets between all cluster units. This can lead
to overall improvement in UTM performance by sharing the processing load among the cluster units.
 The following sessions are processed by the primary unit & not load balanced: UDP, ICMP, Multicast,
Broadcast, VoIP, IM, P2P, IPSEC VPN, HTTPS, SSL VPN, HTTP Multiplexing, SSL Offloading, WAN
Optimization, Explicit Web Proxy & WCCP sessions.
 TCP traffic is not load balanced by default. It is recommended to test this setting in your environment as it
may degrade performance rather than increase. The overhead required to load balance TCP traffic is as
much as just processing it.
 If the primary unit fails, the other unit negotiates and becomes the primary unit. The remaining unit
continues to function as the primary unit, maintaining the HA virtual MAC address for all of its interfaces.
 Session failover is provided for all TCP sessions except UTM, UDP, ICMP, Multicast & Broadcast
sessions. This requires Session Pickup to be turned on.
 All traffic is processed by the primary FortiGate unit.
 Provides Hot Standby failover protection
 Does not process communication sessions, the configuration is synchronized with the primary unit.
 Can be a more robust session failover solution than Active-Active by handling the failover of UDP, ICMP,
Multicast & Broadcast sessions better. This is very condition specific. The cluster does not specifically
support failover of these packets.
 Utilize Active-Active mode if you are utilizing UTM features.
 Utilize Active-Passive mode if you are not utilizing UTM features.
 Utilize Session Failover to maintain TCP, SIP & IPsec VPN sessions after a failure
Unit in Active-Passive Mode