Category Archives: Fortigate

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.


Fortigate: GRE tunnel creation

A GRE (Genereic Routing Encapsulation) is a tunneling protocol that allows data to be encapsulated and sent over a simulated point-to-point link. The beauty of it is that it will encapsulate many different types of traffic and De-encapsulate it on the other. This basically means any traffic sent to the tunnel interface will be stuffed it in a envelope and sent to the remote gateway, removed from the envelope,  and forwarded normally. The network which the traffic is being routed across  only sees GRE and not the individual IP header. A GRE tunnel can be used with or without IPSEC for encryption. This blog entry creates a tunnel WITHOUT IPSEC.

This is not only a one of the only ways to get Routing updates/traffic such as OSPF across a IPSEC VPN, but also is a wonderful troubleshooting option.I have seen this be a great troubleshooting tool when an MPLS might be blocking traffic.

Recently I have utilized a GRE tunnel  to tunnel all multicast traffic across a MPLS network that does not support multicast. By tunneling all the Mulicast data, the MPLS only saw GRE packets and the multicast streams worked great.

In this post I will demonstrate how to create a GRE tunnel between two Fortigate firewalls. Traffic will then be encapsulated from the source and de-encapsulated and forwarded normally on the remote end point. Most of the GRE configuration within the Fortigate is CLI only and not something that can be configured in the GUI.

Steps needed

  • Create System GRE tunnel, Assign local and remote gateways (WAN IPs)
  • Modify system interface GRE settings and assign local/remote tunnel IPs (Tunnel IPs)
  • Create Firewall policies to allow traffic
  • Create routes to remote side of the tunnel , and select GRE tunnel as destination interface
  • Test

The process is relatively straight forward and simple. First we need to create our GRE tunnel. The two sites we will be creating the tunnel on are Site-A, and Site-B.

Here is an overview of the network


Site A

CLI commandsconfig system gre-tunnel
edit “GRE-to-SITEB”
set interface “WAN1”
set remote-gw    — Remote firewall WAN IP
set local-gw          — Local FW WAN1 IP

config system interface
edit “GRE-to-SiteB”
set vdom “root”
set ip    — Local Tunnel IP
set allowaccess ping
set type tunnel
set remote-ip                  — Remote Tunnel Endpoint IP
set snmp-index 65
set interface “WAN1”

Route CreationGRE-overview.JPG

Now we can create the static route pointing my remote traffic ( through the GRE-to-SiteB GRE tunnel.


Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.




GRE Tunnel creation

config system gre-tunnel
edit “GRE-to-SITEA”
set interface “wan1”
set remote-gw
set local-gw

config system interface
edit “GRE-to-SITEA”
set vdom “root”
set ip
set allowaccess ping
set type tunnel
set remote-ip
set snmp-index 8
set interface “wan1”

Route Creation

Now we can create the static route pointing my remote traffic ( through the GRE-to-SiteA GRE tunnel.


Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.


That should be it.

Now lets see if we can ping across our tunnel. As shown below pings work great! Pinging both the tunnel interface and across the tunnel are great ways to check if this tunnel is actually working. Odds are if you have enabled ping on the tunnel interface, and cannot ping it from the other side then the tunnel is not working. Also, check the Firewall policy count to make sure it is increasing with traffic – if so everything is working .





Fortigate – Changing outbound nat IP with IP Pools

Sometimes it is necessary to change IP address used to talk with the internet that the internal client is using. For instance it is always important to make sure your SMTP server is using the same outbound IP used for inbound traffic. I have seen this cause a good many mail servers to be blacklisted by ISPs. In the following entry we will change the IP the client is using for outbound nat.

This technique has many awesome benefits, you can nat into this IP (IP pool) only when going to a certain destination.. etc. For example, if you had to change your source IP when accessing a destination across a VPN tunnel. That example might be very important in a medical field where I have found you almost always have to nat your private traffic to a public address when accessing the VPN hosts.

The internal client address is, external IP is In this example I only want this one internal client to be natted out of

So we have to create a Virtual IP pool . We create the Virtual IP pool by going to Policy and objects – objects – IP Pools

IP pool-create

We then can setup the pool. Notice the options

– Overload allows PAT, so many ip addresses, to one public.
– One-to-One allows one IP to that public IP
– We also have the option to nat into a Public Range of addresses

We also want this device to answer VIA Arp for

Now lets create our IPv4 Policy to allow our private IP address to be allowed to the internet (WAN1) and to be natted VIA this IP pool. I created the address object for my private host already.


So after creating our IPV4 policy, we have one thing left to do – make sure this is one of our first policies hit when tries to access the internet. So lets make sure its at the top of our list, or at least above our default nat rule.


That’s it! if you now go to a site such as or you will see if you are coming from

Fortinet – Creating vlans for devices directly connected to device

The other day I had the need to plug a Ruckus Access point directly into the Fortigate firewall. The client only needed 1 AP, and connecting directly into one of the ports on the Fortigate was the best way – PoE was provided by an injector.

The question came up of how to create the Vlan interface when directly connecting the device to Fortigate.

In this example I will create the vlan on the Internal switch “lan”, and control the vlan from the Ruckus Zonedirector. This will create two separate logical interfaces. Internal, and Staff-Wireless, my newly created vlan.  These two interfaces will require IPV4 policies to allow communication. If you have a lot of VLANs it might be a great idea to utilize Zones in the FW to reduce the number of firewall policies needed.

Lets get started

Vlan creation of Fortigate

So, lets create the vlan for “Staff-Wifi” Vlan 200. You can just create


Now lets put in the needed info.


The below shows the status of the interface:


Notice the VLAN ID – this is seen by right clicking the column settings and enabling that.

Thats it! The Ruckus AP will tag “Staff-Wireless” traffic as vlan 200. So, when the FGT sees the vlan tag of 200 on any ports in the lan switch, it will be treated as Staff-Wifi, thus getting all of its network and policies.

To make the AP work correctly, it needs to be plugged directly into the FGT or a switch behind the FGT that has the vlan created and that vlan would need to be tagged on both the AP and uplink to Fortigate.

Below shows the advanced options of my Ruckus  ZD. I am tagging the Staff-Wifi SSID as vlan 200.


Remember on the Ruckus side only vlan 200 is being tagged for Staff-wifi AP management traffic is untagged – so it would be on my “LAN” switch network.


Fortigate – filtering inbound BGP routes from neighbors, including Default

The other night I had need to stop receiving a default route advertised from my BGP peer. I  also thought it would be helpful for anyone that is needing to do this – and to help myself, since I forget often, to write it up.

First thing we need to do is create a Prefix list to either allow or deny the routes we want. In this case I want to filter out the default route that is being propagated to me.

config router prefix-list


The things to note, rule 10 – I match that route exact (default). then in rule 100 I allow any other prefix – hence the “le 32”. that means anything that starts from and since the 0/0 is blocked already in policy 10- everything else is allowed.

The we need to create our Route map to allow these routes on our in bound direction

config router route-map


Then lets apply the route-map to our peer.

config router bgp


After applying the route-map to the inbound direction we need to clear BGP either soft, or full to make our routing changes take effect.

Run this command to check the BGP advertisements for changes, and synchronize after that.

exe router clear bgp all in soft, or clear both directions (softly) with exe router clear bgp all soft

That should do it, and you will see the default route disappear from the routes learned from your peer. You can also do this to filter routes to any destination network.




Blocking geographic regions in Fortigate 5.4

The best docs are always at

Sometimes I get asked by clients how to block know attacking countries like Russia, or China from accessing their websites. I often hear that only US connections would be accessing their services so why allow others who might not be on the up and up.

Of course most attackers might pivot from compromised computers in the US, and thus bypass this security feature, but either way its not a bad idea. The below gives a good example on how to create a firewall “country” group and then block those countries from accessing any services hosted through the firewall. This will be done in Forti-OS 5.4.0. Its really the exact same steps in 5.2.

Also, there are many ways to do this. Instead of blocking Geographic regions you could only allow the ones you want to give access to.

Before beginning it might be a great idea to check out the new Fortiview feature to see what countries access your services the most. Under Fortiview- you can now see the countries tab.



Great, so in this example lets block the region of China – I know its not one of the top countries accessing my services.

First lets create the address object that we want to block. In this case I am setting the name of the address object as the country I am blocking. After creating the country object, I will create an address group call “Country blocks” add this to my firewall policy. That way in the future if I want to block Ireland, I can just add that object in the group and I am done.

Creating the address object for “China”. First go to “Policy & Objects” and create a new object.

create address

Next we will fill in the needed info, and change the address type to “Geography”.


Now lets great that group, and add the “China” object to it.


Awesome, now just one more step – creating the firewall policy to block this address group.


Press OK, move this policy to the top of all WAN-LAN or your interfaces policies. This way it gets hit before anything else.

There are more ways than 1 to do this. when allowing traffic into your VIP or policy you could instead specify only the allowed countries.



Foritgate 5.4- Changing the interface theme

In 5.4 you now have the option to change the interface color. This is a great setting, because I am not a fan of the emerald green interface that’s default.

This is a great option, and easy to change.

To change the color just navigate to System – settings. At the bottom under view settings you will see the option to change the theme. There are currently 4 colors available. Green, red, blue, and my favorite Melongene. Good Job Fortinet!

Below are screenshots of how to do this.

Default color theme:


Changing the theme to Melongene


Fortigate BGP aggregate address

I like to keep routing tables as clean as possible, and if your IP design and structure allows for very classful subnetting then there is no reason, I see to advertise all of your individual subnets when you could just have one aggregate address advertise out instead. Of course there are numerous reasons why you would not want this, route manipulation, etc.. but not in this case.

At this site my networks all fall into the subnet.

As of now, my networks that are broadcasting to my BGP peer look like this:


The commands to enable route aggregation is listed below. What happens is that any networks within our aggregation block will stop advertising and in their place one summary route is added and advertised.


Now a get router info bgp will show that we went down from advertising 5 networks to advertising 2. This might not seem like a big deal, but if you had a large BGP network, with 100 sites like this, then aggregation can make a huge difference in router performance.




Fortigate Radius group authentication

The Fortigate firewall has a limitation of 10 LDAP servers that you can have on one FGT to do look ups. Normally this is not a problem in the least. Unless you have over 10 domains that you need to do lookups on. To get past this limitation there are a few options, one – Fortiauthenticator, or another option is to use Radius, and authenticate against all the domains. The latter is what I chose. I needed this to authenticate many user groups for different domains for the SSL VPN. So this is Radius authentication for the SSL VPN.

So setting up Radius, and the Fortigate to use radius for authentication was no problem. What was a problem though, was sending the group that the user should be in over to the radius server. I found that if I set the remote server group under the user group properties that authentication would fail. If i removed the group all would work perfectly but if you have multiple network policies on the Radius server, and maybe a user lives in two different policies then there’s a chance that it could authenticate incorrectly and give access to a user who should not have it. This could be bad.

After doing a lot of research I found that Fortigate should be sending in the group when configured under the user group as an attribute value pair, and given the NPS server understands how to handle the attribute it should work very nicely. I found the documentation on this KB article to be very old so I am writing my own, which you are reading.

So to recap what the below shows:

  • Creating a radius server int the FGT
  • Creating a user group, which references the Radius server, and then specifying a user group to match in Radius (NPS)
  • Creating the radius policy, with the needed attribute pair within NPS.
  • Results in Wireshark and exactly what is happening

Below are the links from Fortigate:

First lets setup the Radius server in the Fortigate

Below is the image of my Radius server setup – pretty simple. Take note that I changed my authentication method from default to MS-CHAP-V2, this is what I set on my NPS server.


Next lets setup the user group. Notice this is a firewall group. You also have to manually type the user group since it does not exist .


I will omit the sections showing creating the SSL VPN tunnel policy, and the IPV4 policy allowing traffic in.

Now lets modify NPS. We will have to add a vendor specific attribute for the group name, and then match that in our policy.

Fortigate lists their attributes as below. Lots of cool options you could add like Vdom.

VENDOR Fortinet 12356
ATTRIBUTE Fortinet-Group-Name 1 string
ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr
ATTRIBUTE Fortinet-Vdom-Name 3 string
ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets
ATTRIBUTE Fortinet-Interface-Name 5 string
ATTRIBUTE Fortinet-Access-Profile 6 string

In NPS we have create our policy to grant access to the group we want. That’s no problem. I will omit steps to add the Network policy to allow access. After we get all the policy options we want , and select the group we want to grant access to we need to configure a Vendor specific option to match the group to the Fortigate.

Below are the pictures of exactly how to do that.

on the settings part of the Network Policy, click on “Vendor Specific” and select the option to add one.


Add the vendor specific attribute


Now lets configure our needed vendor/attribute. , and set it in the policy. Notice that we are entering the Vendor code that Fortinet gave to us through those links. Then we will configure the attribute itself.


Here we are filling in the values for the attribute. VPN-Users is what I am matching for my attribute string. If the user is not in the group VPN-Users, then it should deny them.


Thats it! our attributes are in and if the user is not specifically in the group VPN-Users then they will be blocked from accessing the VPN.


Under the hood

So what is actually happening here? it seems that when the user attempts to log in, the Fortigate will query the radius server and send the user credentials over and if access is granted – will allow the user to log in.

In Fortinet documentation they show that the Fortigate will be sending the group over to the radius server, if it matches the Vendor attribute we set, then access is granted. This is not what I have found to be the case (could be wrong). What I have seen happen is, the user attempts to login, Fortigate send the user creds to Radius , the Radius server grants access to the user (if the user meets the policies) and sends the group specified in the Vendor attribute back to the fortigate. The Fortigate then checks to see if that attribute matches what is configured in the Fortigate user group. If that matches, it allows the user to login.

To back this up – check out these Wireshark logs.

Fortigate to Radius server –

Notice that the User name is sent, but no group name


Radius response to Fortigate – Notice the group name (which in this case is infosys-VPN) that group is what in this example is being matched by the Fortigate, and the code of Access-Accept.

To go even further I have tested by removing the group or changing it to something other than whats in the Fortigate and it will fail, even though radius said the user was accepted. When running those tests where I change the group that was passed back to the Fortigate, I got an error on the FGT that said the user group was wrong.


So in the end, the Fortigate is making the decision to allow the user to authenticate based on the user group after radius allows the user based on credentials and policy.