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!
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 10.56.0.0/22 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.
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
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.
I have been working with Fortigate for a long time now, one thing that bugged the life out of me (and most clients I work with) is that Fortigate’s SSL VPN feature would not allow you to specify certain settings per portal or group. For example DNS servers and Domain suffixes. Most firewall/router vendors have been able to do this for years and with no problem.
Starting in firmware 5.2.2 you can now specify individual DNS servers per portal! That’s right, if I have two different domains using the SSL VPN and I specify individual user groups and portals, now I can give each side their own specific DNS servers.
The DNS setting per portal is CLI only as of firmware 5.5.5 – I see this changing in future firmwares (Still has not changed in 5.4.1 either) . The modification is under the VPN – SSL – Web portal options. You can also specify individual WINS servers. This entry is written for someone who already has the SSL VPN up and working. Something to note is that these portal settings override the global DNS settings configured under
config vpn ssl web portal
edit “Sales-Portal” set tunnel-mode enable set ip-pools “VPN-Pool” set split-tunneling-routing-address “SSL-VPN-ROUTES” set dns-server1 10.60.134.5 —DNS Server 1 , Overrides global config set dns-server2 10.60.134.6 — DNS Server 2 , Overrides global config next
And there we have it! We then can of course associate the portal with a certain group of users, so for example Domain 1 get Domain 1’s server and same for Domain 2.