Category Archives: Fortigate

Fortigate – Ping and Traceroute options

Within the Fortigate firewall you can modify many ping and traceroute options to suite what needs you might have. For example, if you need to modify the source IP address for a ping or trace you have that option and many more. Both ping and traceroute are crucial network troubleshooting  tools. Many times I need to ping through a VPN tunnel  using my internal interface, which is in the encryption domain to make sure the tunnel is up and working. or make sure the source of my ping or traceroute are on a local subnet to rule out routing/gateway issues.

The list below shows the table of ping options available:

Fortigate-Firewal # exe ping-options
adaptive-ping Adaptive ping <enable|disable>.
data-size Integer value to specify datagram size in bytes.
df-bit Set DF bit in IP header <yes | no>.
interface Auto | <outgoing interface>.
interval Integer value to specify seconds between two pings.
pattern Hex format of pattern, e.g. 00ffaabb.
repeat-count Integer value to specify how many times to repeat PING.
reset Reset settings.
source Auto | <source interface IP>.
timeout Integer value to specify timeout in seconds.
tos IP type-of-service option.
ttl Integer value to specify time-to-live.
validate-reply Validate reply data <yes | no>.
view-settings View the current settings for PING option.

So to highlight a few of these options – Lets modify the source address we are pinging from, increase the amount of pings and then show the settings to confirm all is set.

Fortigate-Firewall# exe ping-options source
Fortigate-Firewall# exe ping-options repeat-count 1000
Fortigate-Firewall# exe ping-options view-settings

Ping Options:
Repeat Count: 1000
Data Size: 56
Timeout: 2
Interface: auto
Interval: 1
TTL: 64
TOS: 0
DF bit: unset
Source Address:
Pattern Size in Bytes: 0
Validate Reply: no
Adaptive Ping: disable

I removed the default settings it spits out for brevity. That’s it though, we now have changed the source and the repeat count. Lots of other cool settings like ToS and size available.

Now on for Traceroute – You have less options, but the main two that I use – modifying the source IP or interface and setting the amount of hops it will go.

Fortigate-Firewall # exe traceroute-options
device Auto | <ifname>.
queries Integer value to specify number of queries per hop.
source Auto | <source interface IP>.
view-settings View the current options of traceroute.

Lets set the source for the traceroute to and then check the settings.

Fortigate-Firewall# exe traceroute-options source

Fortigate-Firewall# exe traceroute-options view-settings
Traceroute Options:
Number of probes per hop: 3
Source Address:
Device: auto

Thats it! now we are modifying our source IP for both ping and Traceroute.


Fortigate SSL VPN issues – Forticlient

Recently I had an issue with a SSL VPN user who could not connect to the Fortigate. This problem started after upgrading the Fortigate from a very old 5.2.3 to the latest 5.4 firmware – 5.4.7.

Everything went great with the upgrade,but the client would bomb out at 40 percent with “VPN server maybe unreachable” when attempting to connect. After some diagnostics on the firewall I found the user could authenticate, and reach the FW. I then debugged the SSL VPN application and found that the following logs appeared. Note – I changed the IP from the real to

[16143:root:2e2e] SSL state:before/accept initialization (
[16143:root:2e2e] SSL state:SSLv2/v3 read client hello A:(null) (
[16143:root:2e2e] SSL_accept failed, 1:unknown protocol

Unknown protocol .. hmmm. After some digging I found that before the upgrade the following protocols were allowed in the SSL-VPN settings in CLI.

Fortigate $ get vpn ssl settings
reqclientcert : disable
sslv2 : disable
sslv3 : disable
tlsv1-0 : enable
tlsv1-1 : enable
tlsv1-2 : enable
ssl-big-buffer : disable
ssl-insert-empty-fragment: enable

After the upgrade here are the settings

Fortigate $ get vpn ssl settings
reqclientcert : disable
sslv3 : disable
tlsv1-0 : disable
tlsv1-1 : enable
tlsv1-2 : enable
ssl-big-buffer : disable
ssl-insert-empty-fragment: enable

Notice that TSLV1-0 is disabled – this great for security as TLS 1 and 2 are much more secure than 0, but in this case the client was not trying to use 1-2 but only 0.


So the Forticlient is using the security settings within Internet Explorer. The fix was to make sure that IE supported the necessary protocols. On the client that was not working I opened up IE – went to settings, then to advanced. Check the settings out –


I enabled TLS 1.2 (you could also do 1.1) and and tried to reconnect – all worked great. Check out the debug after enabling:


[16143:root:2e39]SSL state:SSLv3 read client hello A (
[16143:root:2e39]SSL state:SSLv3 write server hello A (
[16143:root:2e39]SSL state:SSLv3 write certificate A (
[16143:root:2e39]SSL state:SSLv3 write key exchange A (
[16143:root:2e39]SSL state:SSLv3 write server done A (
[16143:root:2e39]SSL state:SSLv3 flush data (
[16143:root:2e39]SSL state:SSL negotiation finished successfully (
[16143:root:2e39]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

Clearing sessions in FortiOS

Fortigate firewalls are stateful by design, this means that when a client behind the firewall talks to lets say Google a session is created – If all security policies are met.  Google’s return traffic can automatically come back into the client, following the same path (Session) without having to explicitly have an access rule that allows that traffic.  This is also very beneficial in security because the firewall keeps track of that session, makes sure all traffic is flowing on the session as it should, and will close the session if needed. When the session is closed Google cannot talk to our internal host anymore without following very specific rules that would allow communication from them.

With remote APs, Video streams, any many more (Specifically UDP streams) I see problems a lot with sessions getting created on the WAN (Default route) for RFC-1918 private subnets. When this happens internal clients – Maybe APs – cannot talk back to the controller or the UDP video encoder cannot find the decoder any more, but other clients can communicate with those devices just fine.

The reason this happens is that most of the time the IPSEC VPN tunnels or MPLS/E-LAN interfaces have static route assigned to them for getting to the other side subnets. If the physical interface or VPN interface drops then what routes exist in the routing table? Thats right – just the default which in turn sends all traffic even for private subnets out to the internet.  Lets take a UDP video Stream  between two locations for example -UDP never needs an acknowledgement of the traffic, so it keeps blasting traffic to the session – when the session gets created to the internet

When those interfaces or tunnels come back online all should work, and will unless traffic never stops flowing, which is where our problem lies.  When traffic tries to flow when all interface routes are down, then the only route left is the default – so the session gets created on the WAN interface.

To clear these sessions and fix the issues there are a few options.

1 – clear all sessions of the firewall

2 – create session filter and only clear the sessions you need to .

There are many other reasons to clear sessions than the reason I mentioned above.  So lets get to commands!

First you can show sessions on the firewall by using:


Status will show you how many active sessions you have on the firewall and List will print out the individual sessions.

When you select list you get the following information


So for this example lets check out the session created from my internal host going to (

list 2

So we see that just by going to it opened 6 session, these are all going to the same destination IP/Port but coming from different source ports. Option 1 was we could clear all sessions from the firewall – the command to do that is:

diag system session clear

In this example, lets say I want to clear only sessions going to IP We need to create a session filter and then clear only those. Here are the following options on creating filters


Lots of options – one of the coolest in my opinion is matching on Protocol! But in this case lets match by destination IP.


Thats it! now we have cleared all sessions going to that IP.


A few things to note – The firewall will clear out a session  if it does not see a keepalive. It will do that every 3600 seconds by default – this means if a voice call is going on through the firewall then it might close the session after 3600 seconds – this can be a big problem. The “dia system session list” is a great way to find a session and see when it will expire. Great way to troubleshoot – you can also use the GREP keyword to help find exactly what you want.




Fortigate VXLAN Encapsulation over IPSEC

VXLAN is a Layer2 overlay scheme over a Layer 3 network. VXLAN uses MAC Address-in-User Datagram Protocol (MAC-in-UDP) encapsulation to provide a means to extend Layer 2 segments across a layer3 segment. This basically means the layer2 packet gets a VXLAN header applied, then that frame gets encapsulated into a UDP IP packet and sent over to the layer3 network.

In later FortiOS 5.4 firmwares VXLAN (Virtual Extensible LAN) encapsulation was added. This is a great technology that can help connect to sites at layer2 over layer3. Something to take note of – as of FortiOS 5.6.2 – lots of improvements and enhancements to VXLAN encapsulation have been made. For example, vlan trunking works well now. Mutlicast also will traverse the VXLAN!

So far I have set this up for two different clients. Both were situations where we had to have layer 2 stretched for a certain purpose. in the last case it was to two different data centers. Below is the scenario and config of the Fortigates as well as show ARP/MAC from the Cisco switch. Fortinet has some great documentation as well on this feature (Links below).

Below shows our simple layout. The red line indicates the VXLAN encapsulation path. Encapsulation only happens at Fortigate firewalls.


Here is a check lists of things that are needed:

  • Create VXLAN VPN
    • Local encap-local-gw4 is the public address on the local FW
    • encap-remote-gw4 is the peer address of the other side
    • remote-gw is the peer address of the other side
  • Then create a new Switch interface
    • Add both the local network, and VXLAN-VPN interface to this switch
  • Create firewall policies allow traffic

Thoughts and observations:

  • Lowering the MTU of the VXLAN/internal interface might be a good idea. The VXLAN encapsulation adds around 50-bytes. Most Cisco documentation will mention increasing the MTU, but since we are going over the net with this, increasing MTU means lots of fragmentation.
  • No IP address on the Switch interface is needed. Actually I have seen small issues when putting an IP address on the interface.
  • In CLI use the commands below to help get broadcasts (be careful) and ARP to go across.
    • config sys int
      • edit VXLAN
        • set l2forward enable
        • set broadcast-foward enable
        • end
      • end
  • In 5.6.2 VLANs tags will pass through the tunnel


SIDE 1 (60D)

config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan2”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4
set encap-remote-gw4
set remote-gw
set psksecret password
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1

config system switch-interface
set vdom “root”
set member “internal1” “internal2” “VXLAN”

Lets look at the Switch in the gui


Then lets check out the Firewall Policies

firewall policies

SIDE 2 (60E)

config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan1”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4
set encap-remote-gw4
set remote-gw
set psksecret password
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1

Lets look at the Switch in the Gui

60-e interface

Next lets check out the Firewall Policies




First make sure the VPN is up and working. Then a simple ping test between two devices on the same subnet will be enough to make sure things are working. TCP is always the best way to test . You can also check and make sure that the ARP/MAC address tables on each side show something on the remote side. For example the below shows the ARP/MAC of the Cisco 3650 switch at the Datacenter side (60D).

Datacenter-Stack#show arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet           0   000c.291c.b2a5  ARPA   Vlan1


Internet           0   000c.2918.b8be  ARPA   Vlan1  – 19.51 lives behind the 60E

Datacenter-Stack#show mac address-table
Mac Address Table

Vlan Mac Address Type Ports
—- ———– ——– —–
1 000c.2918.b8be DYNAMIC Gi1/0/1  — Fortinet 60D is connected to gig 1/0/1



Thats it! VXLAN is an open source protocol that is a great datacenter technology. Fortinet makes it very easy to get this up and going within a few minutes. EB

Fortigate – Finding MTU of an interface

Recently I had the need to show the MTU of an Fortinet Fortigate firewall interface. By default, if there are no changes the MTU will be 1500. But in this case I needed to be able to show that the MTU was 1500.

Few commands I tried did not show the exact info I needed, for example- Get hardware nic port1 – showed lots of great info but not the MTU.

To get this info I needed to do an Ifconfig from the Fortigate. to do this I ran the command:

fnsysctl ifconfig -a port1     Port1 being the port I needed to get the info for. Check out the screenshot below. Lots of other great info such as dropped packets and MAC.



FGT traffic shaping in 5.4 – Per Policy/shared options

The best docs are always at

Fortigate traffic shaping is awesome, lots of options and it all works really well. Going from 5.2 to 5.4/5.6 is quite different due to the creation of policies changing from within the firewall policy, to their own section. Either way, they all work great.

I did notice at least in 5.4 that the option to change how a policy is used do not seem to be in the GUI. Previously there were two options – “Per Policy”, and “all policies using this shaper”. Selecting “all policies using this shaper” would have all policies using that shaper object to share the guaranteed or Max bandwidth settings between all policies using that shaper. Selecting “Per Policy” allows you to dedicate those same settings to each policy referencing the shaper object.

Which gets to my point, in 5.2 you had the options below. Notice the options about how to apply the shaper.


In 5.4.5 at least notice that they are gone. Of course, if you upgraded from 5.2 the options are there.


So as with everything that does not show up in the GUI – you know it is in CLI. So I dropped down to CLI to check if the settings are still there. By editing the shaper, and using the “get” command I could see all settings and their values the policy had to offer. As I thought the option “Per-Policy” is there with the default settings of disabled. So by default, all Shaper policies have  settings shared between different traffic policies referencing that shaper.


So in this case, I want to give the same percentage of bandwidth to each of the traffic shaper policies referencing my shaper object. So I will modify that option.


Now, in the GUI lets check that policy again –


Awesome, now we have the actual options to change.

Fortinet – Common PCI/Security audit issues

This is an ongoing blog, and one that I will update often will things that come up in security audits.

Companies are always getting external audits to make sure they comply with policies and have no outstanding vulnerabilities with their systems. This is great, but sometime the Fortigate will get pinged on SSL/SSH encryption level issues. The following blog is a few helpful commands that can get the Fortinet to pass inspection by disabling the lowest or least secure SSL and SSH protocols. Also below I have put in excerpts from a few scans.

Issue 1:


Error: TLS Version 1 Protocol Detection – So the above was an issue with TLS Version 1.0 being enabled on port 443 (My SSL VPN port). So, we need to remove TLS 1.0 from the accepted protocols on the VPN.

The commands to do that are:

config vpn ssl settings
    set tlsv1-1 disable

The disables TLSv1 from the SSL VPN

Next issue

  • Vulnerability Details 116818

This host is susceptible to the SSL version 3 POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. By using SSL version 3 and CBC Mode ciphers this host can allow an attacker to expose encrypted data in a connection between the client and server. Impact: Over time, an attacker can steal sensitive information between the client and the server using this man in the middle attack. Hosts may default to a more secure protocol (TLS 1.2, for example), but a network attacker could potentially trigger a reconnection causing the browser to retry older protocols (SSL version 3).

The above error basically says that SSL Version 3 was enabled on SSL VPN port. Just like before we will disable that

config vpn ssl settings
    set sslv3 disable
set tlsv1-0 disable
set tlsv1-1 disable

This turns of SSLV3 from the SSL VPN supported protocols.

This Entry will be updated as I find more from going through audits.

Fortigate – Simple device hardening

As always has the best information.

Firewalls almost always interface with the internet, and most of the time we enable remote access from the internet to make our lives easier when troubleshooting an issue, and maybe not being behind the firewall at the time. The best why to secure the device is just not enable access from insecure locations, but some times we have to enable it.

There are a few simple things we can do to help elevate vulnerable spots when allowing access from the internet.

  • Enable a password policy
  • Modify lockout policy/duration if needed
  • Allow admin access from only Trusted hosts
  • Modify default access TCP ports
  • Create a new admin account named something different, and then delete the default admin account.
  • Make sure a log in banner is active – Certain cyber laws need explicit notification that the user attempting login should have authorization.
  • Use dual factor authentication to gain admin access to the device.
  • Logging , always logging!

This blog is written with both 5.2 and 5.4 firmwares.

Enabling a password policy

This is great to do if you have multiple accounts on the device. This way a user cannot change their super complex password to something with 3-4 letters. A password policy enforces certain specifics to the password. For example you can set the character requirements as well as password reuse/expiration. Check out the below images for 5.2 and 5.4. Notice you can enable this for VPN accounts and admin accounts.





Login failure lockout duration and Threshold

When you mistype your password 3 times by default you are locked out of the firewall for 5 minutes (All docs say 60 seconds though). This is a great defense against applications that attempts to brute for the firewall user/pass. Increasing the time the user is locked out can be a good idea to keep the bad guys from knocking, but could also really put a damper in your day if you lock yourself out for X amount of time.

But the commands to lower or increase it are the same in both firmware’s:

config sys global

set admin-lockout-duration X (seconds)


To increase the threshold (how many incorrect login attempts you can have)

config sys global

set admin-lockout-threshold (1-10 attempts)


Only allow logins from Trusted hosts

Why allow logins from anywhere on the internet, when you know if you logged in it would come from only a few sources.


Under the administrators options, you can select the trusted hosts (IP networks) that can login with the Mirazon account in this case. You could also modify the default admin account.




Change default port numbers used for logins

I was in a debate one time about the security of changing default port numbers, and a friend said “Changing your login port numbers is as secure as hiding your keys under the front door mat.” He was most certainly correct, but security by obscurity is better than nothing. By changing the default port numbers from 443,80 some bots that try to log in will not find the open login due to different ports that are not in its scanning script.

In the following examples I am changing the default port of 443 to 8081.






In summary there are tons of things to do to increase device security. One of the most important, if you don’t need to allow remote logins to the device, why even enable it? Disable the login options under the interface. I believe the best practice is to have an out of band management PC that might connect directly into the MGMT port. To access the FW you have to access this machine.

Changing Port numbers and implementing the other options are great ways to help reduce login failure attempts, or unauthorized access. Another great option, not explained here is using dual factor authentication. By default you get two licenses for two factor – why not use it for admin access!

The importance of logging is one thing that cannot be underestimated. When logging is enabled you know exactly what happened – if someone tried to log in, from where, what username, and if they failed or were successful.

These were just a few of the many ways to increase device security.

Link to login banner blog:

Fortigate 5.4 – Named policies

Fortigate has done a great job with the 5.4 firmware. Its a big change from 5.2 but once you get going with it, you will find things are structured very well. For example the “Monitor” category is a great way to get everything you need, instead of going through each individual category.

One feature of 5.4 that really “Grinds my gears” is the named policy feature. The feature itself is awesome, great way to put in a name on a policy such as “Students to internet”.. etc.  But, they make it mandatory to put in a name by default. What’s so aggregating about this is that if you upgrade to 5.4 from 5.2 all of your policies are unnamed, so when you modify one of those existing policies you HAVE to put in a name. The following will show how to turn that feature off, so it is not mandatory you put in a name. You still can, just don’t have to.

Below you will see what happens when you try to create that policy , and the the feature has not been disabled. You get the “This field is required.” error. It will not let you create or modify the policy until that is filled in.


To disable this feature, go to system-Feature select- then check “Allow unnamed policies”. Once you press Apply this will let you bypass the mandatory name feature.