Category Archives: Fortigate

Getting Fortiswitch interface statistics

I am more impressed with Fortiswitches every time I work with them. The ability to implement light NAC features, INTRAvlan firewall policies and overall management really gives these switches a feature set to checkout when deciding on new switches.

Below are the steps to quickly get the interface stats such as errors/packets, etc. The commands are ran on the Fortigate, which in this case is controlling the Fortiswitch.

Drop into CLI on the FGT and check what switches are connected by running the command

get switch-controller managed-switch

This command will bring back the names of the manged switches. Locate the switch you want to check the port stats on. For example, we will use the name “FS1D24T419001174”

the command to get the stats are:

diag switch-controller switch-info port-stats FS1D24T419001174 port1

The output is in the image below:

using the top level command diag switch-controller switch-info you can also get LLDP, Power, and lots more info of the managed switch.

Updating Fortigate certificates

Certificates for VPN, SSL Offloading (if using Load balancing), or a signed device cert expire, we all know this. Up until last week I had never updated a signed certificate, I had just created a new CSR, and rekeyed the cert. Updating the certificate the Fortigate is using is very easy, but I had problems with the syntax so I am documenting it here.

The Fortinet KB article to do it is located here:

I had an issue following the doc so I though I would clear the water and see if I could help someone down the road. Lets say I have that will expire in 2 days – I log into my CA (godaddy in my case) and renew the cert. They send the new cert to me, but what do I do with it…

Open the cert with a text editor – maybe notepad – and copy the cert. you should see —BEGIN CERTIFICATE. Copy everything. Then log into the fortigate VIA cli – Putty or some kind of SSL client is way better for doing this then the web client. Then lets modify the certificate

config vpn certificate local

edit sslvpn (or your cert name)


and Press enter – The issues I had was with the quotes. I tried to first do double quotes, and past the cert in the middle – that does not work. Just simply type in the command set certificate and then a double quote and past the cert whole. After its pastes do the ending quote and press enter. Thats it for modifying the cert – but to enact it we have to remove it from whatever we are using it for, and then add it back. That refreshes the cert. So if your using it for SSL-VPN , go to VPN – SSL-VPN settings – and set the server cert to a different one, press apply, and change it back.

Fortigate: Creating a static route in FortiOS 6.2

This entry details how to create a static route in both the GUI and CLI of the Fortigate firewall. Specifically I am using FortiOS 6.2.4 but its pretty much been the same for years.

Lets start by talking through the things that will be needed to create the static route.

Subnet – this is what we want to route to, for a default route its but if we wanted a more specific route, lets say to

Destination Interface – Next hop interface we want to send traffic out of.

Gateway address – Directly connected interface neighbor that we want the next hop for to be.

Administrative Distance– is a feature used by routers to select the best path to a destination when multiple paths to the same destination are present. Lowest AD wins and will be placed in the routing table.

Advanced optionPriority – To build on AD definition – What if two routes exist in the routing table to the same destination with the same AD? This is where Priority comes in. Lowest priority wins. By selecting a priority you can have multiple routes to the same destination in the routing table, but one would be preferred over the other. This comes in very hand for Reverse Path forwarding issues.

So after all that’s said, we need to route to our LAN interface with a next hop of

First lets create this in the GUI. Navigate to network – static routes – and create a new one.


Now we will just insert the needed info. I am leaving the AD at 10 – which is default.


Press OK – and Bam! route created. We can check that the route has been created and is the routing table by going to monitor – routing monitor.


Next lets do the same thing in CLI.

First route creation. When you create the route edit the next available sequence number. In this case its 46.


You can see if your route is in the routing table in CLI by running the command “get router info routing-table all” but in this case I am using the static option, and grepping just what I need to see.


Fortinac PXE DHCP boot options

Fortinac is built on top of CentOS and is a great product. Recently I needed to have default or isolated vlan support PXE booting as well as isolation. This way if a computer is being imaged we don’t have to worry about hard coding ports with vlans, etc. This is important because the NAC cannot look at the client prior to the OS install.

These settings were added to the dhcpd.conf – they would work for any implementation running dhcpd not just Fortinac.

Below is the conf that works.

# Sample /etc/dhcpd.conf

log-facility local6;
ddns-update-style none;
allow bootp;
allow booting;
class “authenticated_clients”
match pick-first-value (option dhcp-client-identifier, hardware);
# Isolation Scope ISOL_Isolation_blackhole
subnet netmask {
default-lease-time 28800;
max-lease-time 86400;
option domain-name “blackhole.local”;
option domain-name-servers;
option broadcast-address;
option routers;
next-server PXE-SERVER-IP;
filename “SMSBoot\\x64\\file1.efi”; — NOTICE the two slashes that represent the file path – I was missing this, and of course it could not find the file.

The options for next-server and file-name were the options needed to push PXE settings over.

Restart the service after saving the configuration to dhcpd.conf

Fortigate 6.0 Adding and removing IPs from Quarantine list

Starting in 5.4.1 you could “Quarantine” an IP address. This means that the quarantined host cannot communicate through the firewall.

There are many different parts of the firewall the quarantine an IP address. For example the AV and IPS can both automatically quarantine an IP if it meets a defined violation.

In 6.0 you can view the IPs that have been quarantined by going to Monitor- Quarantine. From here you can see what IPs are blocked, and for what reason. As you can see in the image below has been blocked for 26 days by an admin. If an admin blocks an IP address (as we will see) it shows up with “Administrative” as the source.The other IPs have been blocked by the IPS engine. The below image shows the monitor section.


So, lets say that you look into Fortiview and see that a remote IP is sending/receiving a ton of bandwidth and you want make sure that stops. in this example lets quarantine the IP

In this example we can act like I was looking through Fortiview and found an issue that makes me want to block the above IP. You can just click on the IP you would like to block, right click and then select to “quarantine”. When you do this, it will pop up and ask for the length of time you would like to block them for.


The above shows that it will ban the IP from communication for the given period of time.

So, lets say we want to remove an IP address that has been quarantined –  No problem, just need to go to Monitor-Quarantine and click on the IP and delete that individual or click to delete all entries.


You can modify how long and for what reason the IPS/AV quarantine an address for within the policy. For example, below shows modifying the reason/time of quarantine. The AV settings are within the CLI of the AV policy under “nac-quar”. Something to note, sources are not quarantined by default.

FGT’s entry on configuring AV settings:

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.