I don’t know if its’ just bad coding, or an attempt at security, but the fact that the ‘uninstall’ option is missing from add remove programs for the FortiClient is a bit annoying.
Remove FortiClient Solution
While attempting to remedy this I came across the following command, which is supposed to remove the client software, which it did NOT do, but it did give me the option to uninstall back again.
[box]
wmic product where "name like 'Forti%%'" call uninstall /nointeractive
[/box]
Now we can uninstall.
Related Articles, References, Credits, or External Links
More and more people are using Azure as their primary identity provider, thanks in no small part to the massive success of Office/Windows 365. So if you want to provide a FortiGate/FortiClient SSL remote access VPN solution then securing it via Azure makes a lot of sense.
Multi Factor Authentication: If you have MFA on your Azure accounts then that’s a big box ticked for your accreditations and digital liability insurance also. This article does not cover enabling MFA in Azure, we are assuming you already have that enabled. I’ve covered that in other articles anyway, (use the search box above!)
Essentially your firewall will redirect authentication (via SAML) to Azure when you attempt to connect either via the web or tunnelled with the FortiClient.
You will need an Azure subscription (a trial one is fine), obviously a FortiGate firewall, and a publicly signed certificate for the firewall (see below).
Note: Stop asking if you can use self signed certs – this one cost me six dollars! It needs to be publicly signed so Azure trusts it!
Add and Configure the FortiGate SSL VPN Application
From within your Azure tenancy, locate Enterprise applications and choose to add a new one.
Do a search for Forti and you should see the FortiGate SSL VPN application, select it.
In the setup single sign on section, click ‘Get Started’.
Select SAML.
The ‘Vast Majority’ of the work that needs to be done will be done in here. In Section 1 (Basic SAML Configuration) you will enter FOURURLs (these URLs will reside on your FortiGate).
Change the values in red to match your own publicly resolvable FQDN, (which will match the CN on your certificate).
Identifier (Entity-ID)
[box]
https://vpn.petenetlive.com/remote/saml/metadata
[/box]
Reply URL (Assertion Consumer Service URL)
[box]
https://vpn.petenetlive.com/remote/saml/login
[/box]
Sign on URL (Yes it’s the same as the one above!)
[box]
https://vpn.petenetlive.com/remote/saml/login
[/box]
Then scroll down.
Log out URL
[box]
https://vpn.petenetlive.com/remote/saml/logout
[/box]
Then SAVE.
Section 2: Attributes and Claims, click edit.
Add a new claim.
Name = username, Source attribute = user.userprinciplename> Save.
Select the existing user.groups value > Change it to ‘All Groups’ > Tick ‘Customise the same of the group claim’ > Set the name to group > Save.
Note: It can take little while for the main page to refresh .
Section 3: SAML Signing Certificate. Download the Base64version of the certificate.
Back on your FortiGate > System > Certificates > Import > Remote Certificate.
Browse to and upload the certificate you just dowloaded.
Make a note of the certificate name, in this case it’s REMOTE_Cert_2 (You will need this later).
Section 4: Setup FortiGate SSL VPN. In this section there are three URLs that you need to take a copy of (they are used in the code block you will post into the FortiGate.
You now have all the elements you need to paste the following code block into your FortiGate, the following elements IN RED should be changed to match yours.
set-cert is the NAME that the FortiGate has given to its public cert, (mine’s the same as its common name, yours may be something else!)
entity-id, single-sign-on-url, and single-log-out-url are the URLs you pasted into section 1 (above).
idp-entity-id, idp-single-sign-on-url, and idp-single-log-out-url are the URLs you copied out of section 4 (above).
idp-cert is the NAME that the FortiGate has given to the cert you dowloaded from section 3 (above)
user-name and group-name are the attributes and claims you setup in section 2 (above).
[box]
config user saml
edit SSL-Azure-SAML
set cert vpn.petenetlive.com
set entity-id https://vpn.petenetlive.com/remote/saml/metadata
set single-sign-on-url https://vpn.petenetlive.com/remote/saml/login
set single-logout-url https://vpn.petenetlive.com/remote/saml/logout
set idp-entity-id https://sts.windows.net/de742342-edf0-49e7-8ca3-1402fddc17bc/
set idp-single-sign-on-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-single-logout-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-cert REMOTE_Cert_2
set user-name username
set group-name group
next
end
[/box]
Azure Groups
You will need a group in Azure created with the users that you wish to be able to authenicate into to the remote VPN. Take a copy of its Object ID (you will need that shortly).
With that object ID you can create a ‘Group’ on the FortiGate with the following code block
[box]
config user group
edit AAD-Remote-VPN
set member SSL-Azure-SAML
config match
edit 1
set server-name SSL-Azure-SAML
set group-name 02f047b1-8db2-4474-84df-21af6a16204c
next
end
next
end
[/box]
You will also need to add this group (In Azure) into the FortiGate SSL VPN application > users and groups > add user/group.
Click ‘None Selected” > Select your user group > Select.
Heed the warning! No nested groups, which is a little annoying, but you can’t say they didn’t warn you > Accept.
FortiGate SSL VPN
I’m going to use the basic settings to get this up and running, VPN > SSL VPN Settings > Listen on Interfaces (set to the outside facing interface (that the certificate name points to!) Server Certificate set to your publicly signed certificate > Scroll down.
Note: If you see a warning about not having configured SSL policy, dont worry we will fix that in a moment.
Create New.
Select the AAD user group (we created with the second code block) and set the Portal, (here I’m using full access so the remote client can use the web, or full tunnel options) > OK.
Policy & Objects > Firewall Policy > Create New.
Give the policy a sensible name > Incoming Interface will be SSL-VPN (Not outside!) > Outgoing interface is usually the inside (unless you have DMZs etc) > Source, add in All and your AAD-Group you created with the second code block above > DISABLE NAT > Scroll down.
Change Logging to ‘All sessions’ (Note: once fully deployed, you can change this to security events) > OK.
Note: It may error at this point if the portal you have chosen, (in this case full-access) has split tunnelling enabled, you can either disable split tunnelling on the portal, or change All in the destination section to a particular subnet on the the LAN).
Testing Forti Web SSL With Azure
From an external client connect the web address of your FortiGate, all being well it should redirect you to Azure, (or your ADFS portal if you use ADFS).
Provision authentication is successful, you should see something like this.
Testing FortiClient Azure SSL VPN With Azure
Install the FortiClient, (here I’m using the VPN only version). Give the connect a sensible name > Set the gateway to your public FQDN, and tick ‘Enable Single Sign On (SSO) for VPN Tunnel > Save.
SAML Login
After your Microsoft authentication prompt appears, the client should connect successfully.
Related Articles, References, Credits, or External Links
A colleague rang to ask if I had any thoughts about a problem that they were having, we do a lot of VMware VCSA upgrades for customers, the process fails if there is no DNS resolution of the FQDN during the upgrade process. We had tried to fix the problem by creating hosts records (typically we don’t have access to the client’s DNS servers that run in the virtual environment). I had thought (wrongly) that it simply needed to lookup the FQDN, but I’m told it also needs to do a reverse lookup (locate a PTR record).
We could of course just spin up either a Windows server and put DNS on it, or a Linux BIND server, but what if we could use the firewall? With Cisco this is a non starter, but what about the clients that have FortiGate?
FortiGate DNS
By default the feature isn’t enabled, you need to go to System > Feature Visibility > DNS Database > Enable it > Apply.
Network > DNS Servers > Create New.
Select the interface that will serve DNS queries > OK.
Back at the min page under DNS Database > Create New > Give the zone a sensible name > Set the domain name > Under DNS Entries > Create New.
First create a host (A Record) that will point the FQDN to the correct IP address.
Then create a pointer (PTR Record) that will point the IP address back to the FQDN.
It should look something like this > OK.
Then test from a client that’s connected to the Interface serving DNS requests.
Related Articles, References, Credits, or External Links
I have a FortiGate/FortiClient test bench setup for testing, and its to been used for a while. When I attempted to use it this happened;
Unable to logon to the server. Your username or password may not be configured properly for this connection. (-12)
While messing around trying to fix it I also got this error;
Unable to establish the VPN connection. The VPN server may be unreachable. (-14)
Disclaimer: That second error can also be caused if the FortiClient is unlicensed (which you can clearly see, it is.) So this might be a red herring.
VPN Error: Solution
This took ages for me to fix. The common consensus is this is usually caused by a setting in the machines internet properties. Open an administrative command windows and run inetcpl.cpl The firs this I was asked to do was > Advanced > Reset > Tick Delete Personal Settings > Reset.
Security > Trusted Sites (set slider to Medium) > Sites > Add in the URL my FortiClient was trying to reach, (yours will be a public IP or DNS name) > Close.
Advanced Tab > Security > Tick Use SSL 3.0 > Apply > OK.
In my case all of these DID NOT solve my problem, I’ve seen strange errors with LDAP username and passwords, so I made sure the firewall could ping the FQDN of the LDAP server, and it successfully authenticated me (I’ve seen the GUI auth test work, and the command line one fail in the past).
Then I debugged the SSL VPN and got the following error;
Removed for tunnel connection setup timeout.
In the end I changed TWO things and it started to work. Firstly I uninstalled the FortiClient, and installed the latest version.
Secondly I looked at my SSL VPN Settings and noticed the group was set to a firewall group and NOT my LDAP (Active Directory) group. which I changed.
Other possible fixes I found on my trawl – that were not applicable to me;
Active Directory User Account (Account or Password Expired)
Theres no firewall policy for the SSL VPN Traffic (See this article).
Your AD password is using some ‘Odd Characters“, (test with an alphameric password).
Your AD user has “user must change the password on next login” enabled.
You’re trying to cone too eh SSL VPN fro BEHIND the FortiGate (not outside).
So this seems like a very generic error. If you come up with a different fix, or one that didn’t work for me, but worked for you. Please take the time to post below to help the next technical traveller.
Related Articles, References, Credits, or External Links
While recently needing to add a new AD group to my firewalls FSSO setup, (to be used in a policy.) The new group could not bee seen (it’s called GS-Web-Block-Override).
FSSO Force Sync
The common fix for this is to create a filter on your FSSO agent server, that will ONLY look of the groups you specify like so.
However, in my case that didn’t work either! I spent ages trawling Forti pages and Reddit, until I came across the following command. (I’ve lost the original link so I can’t credit the poster).
[box]
execute fsso refresh
[/box]
Then, as if by magic, my group appeared!
Related Articles, References, Credits, or External Links
A colleague messaged me last week because he could not import a certificate on a FortiGate (that had been exported from a Cisco ASA). He was seeing this error;
Incorrect certificate file format for CA/LOCAL/CRL/REMOTE cert.
FortiGate Certificate Problems
A brief Google led me to ask “Is the FortGate licensed or on a Free/Trial license?” As that can produce this error {apparently}. But for us this was not the problem.
This was happening because the ASA (like Windows) exports its certificates in ‘base64‘ encoding and the FortiGate does not like that, so it throws its toys out of the pram. Firstly ENSURE you exported the certificate as a PKCS12 file like so,
Otherwise the certificate will NOT be exported with its private key, and if you import a certificate into a FortiGate without the private key you will get this error;
Certificate file is duplicated for CA/LOCAL./REMOTE/CRL cert.
We now have a copy of our exported ‘base64 encoded’ certificate. (Note: It has no file extension, don’t panic!) If it was extracted from Windows, it might have a .PFX extension. If yours does, simply use the following commands with that file extension.
And put it on a machine that has OpenSSL installed, or if like me you’re a macOS user copy it there, (OpenSSL is installed by default). Firstly we have to decode the extracted certificate;
I know FortiGate prides itself on being able to do everything from the GUI, but if you can only get in at CLI and need to take a backup then you need to go old school. Recently I had an HA Pair of Fortis, the primary had broken and I could not get access to the GUI on the standby. My plan was to get a backup, blow both (virtual Firewalls) away, deploy two new ones, and restore the config.
What about Licenses? Licences are handled separately (to the config) on FortiGate
In all honesty, enabling Web Filtering on your FortiGate really could not be simpler, you can simply enable it on your default users outbound policy, and select one of the three ‘pre-canned’ profiles, job done!
But most companies not only want to filter their web traffic they want to see who is getting blocked, and what are users trying to get access to. Most businesses now have ‘an acceptable use policy‘ for their IT, and if you don’t, get it sorted or when you want to sack “Creepy Dave” because he’s been frequenting ‘dodgy‘ websites you might be on a sticky wicket.
So before you even think about enabling Web Filtering you may want to roll out FSSO, so the firewall knows who everybody is, and what machines they are logged into.
As with any Advanced Threat Protection product, you need to have a license for Web Filtering, let’s check that first > Dashboard > Status.
Then let’s make sure our definitions are up to date and the FortiGate is happy > System > FortiGuard > Web Filtering.
You can find the three ‘pre-canned‘ profiles under Security Profiles > Web Filter
Edit the policy, some of the things that are ‘allowed’, might raise an eyebrow, so block anything you consider to be inappropriate for your workplace.
Then locate the policy object that your users are using to browse the web (under Policy & Objects > Firewall Policy) > Scroll down and enable Web Filtering > Select the correct Profile > OK > OK.
Note: If you are just rolling this out it might be worth using the Monitor All policy first for a while, just so you can get a handle on what your users are doing, and how much data there will be to trawl though.
Then if your users attempt to go to a site that’s blocked, they will see something like the screen below.
Technical Tip: When testing Web filtering I use www.page3.com, (for my friends over the pond, in the 70’s, 80’s, and 90’s one of the UK “newspapers” used to have a scantily clad, (usually topless) lady on page 3. In modern society we frown on exploiting these girls, and making them multi millionaires now). However the domain still exists, and (if it were not blocked), it just redirects to the “newspapers” home page now. So if someone is looking over your shoulder they will not get an eyeful of nakedness (there’s a phrase I never though I’d be writing on PNL).
FortiGate Web Filtering: Whitelist a Blocked URL
The system is pretty robust, but you may sometimes want to allow a particular blocked URL, as you can see (above users can apply from the block page to have that URL unblocked if it’s been blocked in error. But what if you want to explicitly allow a URL thats getting blocked, (I had to do this a lot when I worked in the health sector for example).
Go to the Profile thats applying the block > Edit > > Enable URL Filter > Create New > Type in the URL you want to unblock > Note: I’m selecting Exempt NOT Allow, (theres three hours I’ll never get back) > OK > OK.
FortiGate Web Filtering: Enable Password Override
You can (if you wish create a group that can manually override the block screen (Note: It will still get logged). So here I’ve created a Domain Security Group.
Then I can use FSSO, to enable that group on my FortiGate.
Create a new Profile > Give it a sensible name > Enable “Allow users to override blocked categories”.
Add in the FSSO Group you created above, then in the profile section select the profile you want to ‘Switch‘ them to, and select ‘Monitor-all” > OK.
Now create an outbound policy for web traffic > Add your FSSO users and ALL to the source, and make sure you enable the password override policy.
Note: Make sure this rule comes BEFORE your normal web traffic rule.
Now when those users are blocked, they get the option to “Proceed“.
FortiGate Web Filtering (Viewing User Activity)
On my little test bench my firewalls are logging to FortiCloud. If you have FortiManager or FortiAnalizer then head in that direction for your reports, but for small deployments like this > Log & Report > Web Filter. Here you can see the block action that was taken above for example.
Related Articles, References, Credits, or External Links
If you are applying polices with your FortiGate, e.g. Web Filtering or IPS, then the ability to track actual users rather than IP addresses is advantageous, it’s all very well blocking access to adult material or gambling sites, from the corporate network, but most companies want to know WHO is attempting to connect to what and when.
To do that the firewall needs to learn what users are where, we can make all users actively authenticate to the firewall as they attempt to get on the web, but that does not make for a great user experience, it’s better to passively learn where your users are, and what machines they are using, then we can the use that in a policy. (let’s not get to far ahead for the moment).
Q. How do we learn where your users are, and what machines they are on?
A. FSSO
To enable FSSO you need to understand the difference between two pieces of software, the FSSO Collector, and FSSO DC Agent. The DCAgent (as the name implies) run on each of your DCs, it captures login events and then does DNS lookups to see what machines people are using. The Collector takes the output from one or more DC Agents and collates it for the firewall, it does not have to run on a domain controller (but it can).
I only have one server! Well thats OK, both the collector and agent can be on the same box
However most networks will have multiple Domain Controllers, so your FSSO topology may look a little more like this.
Or if you have an even larger network, you may want to build in a backup collector(s)
Deploy FSSO
In my small test environment I’m going to put the collector and agent on a single DC. Your first challenge is actually getting the FSSO software. Log into your FortiCloud portal and proceed as if you want to download some FortiGate firmware.
Then in the version of FortiGate firmware that matches your firewall you will find an FSSO directory, (unless your’e in the dark ages your domain controllers will be x64 bit) so in my case I want FSSO_Setup5.0.0306_x64.exe (that will download the collector setup, that also includes the DC Agent software as well, which you can also download separately if you wish).
Install Collector
Accept the EULA, change the install directory if you don’t want it on the C: Drive > Enter some administrative credentials > Next.
My FortiGate has LDAPS Lookups so I’m going for Advanced > Next.
Install > When complete, Im installing the DC Agent on the same server so MAKE SURE ‘Launch DC Agent Install Wizard” IS ticked, and click finish.
Warning: Installing a DC Agent will result in the reboot of this DC, (you might want to do the next step out of hours).
Install DC Agent
Accept the defaults > Next > Select the Domain > Next > Select any user(s) you want to be exempt > Next.
Select DC Agent Mode > Next > It will prompt for a reboot, let it do so.
Post reboot launch FortiGate Single Sign On Agent Configuration > And change the password to something memorable, (you will need to enter this onto the FortiGate in a minute).
Register FSSO on FortiGate
Back on the Fortigate > Security Fabric EXTERNAL Connectors > FSSO Agent on Windows AD.
Give it a sensible name > Enter the IP address and the password you set above > Apply and Refresh > OK.
You will know it’s working because it will give you a free up arrow (it can take a little while, be patient).
Create FSSO Groups
Now you can add GROUPs based on FSSO learned groups, like so.
Once you have the FSSO groups defined, you can use them in policies. Below I’ve added Domain Users to my default outbound policy.
WARNING: If you have any devices, or assets that need access out you will need to add a new rule to alow them out explicitly before this rule, or their internet access will suddenly stop.
Monitor FSSO Events
To make sure the system is working you can go to Events > User Events > Make sure your user logon activity is getting logged.
Related Articles, References, Credits, or External Links
If you want to employ the IPS service of a FortiGate firewall then you need a license for that privilege. At the time of writing you can get IPS as part of the following subscription licenses;
Enterprise Protection
SMB Protection (Only on firewalls SMALLER than 100F)
Unified Threat Protection (UTP)
Advanced Threat Protection (ATP)
But Forti love to change the names of things, so double check with your vendor.
Fortigate IPS (A Quick Tour)
OK let’s see if we have a valid IPS Licence. Dashboard > Status > Licences > IPS > If it’s green and ticked we are good.
Now let’s make sure all our Intrusion Prevention definitions and engines etc are all up to date.
Note: Notice the Malicious URLs – I’ll mention that again in a minute.
The next couple of steps are purely informational, (so you can understand how IPS works, and how everything hangs together). Go to Security Profiles > IPS Signatures. Spend a few minutes looking at this page so you will better understand how they are applied. First each one is assigned a Severity,
1. Informational (green) 2. Low (blue) 3. Medium (yellow) 4. High (orange) 5. Critical (red).
In addition it’s given a Target (Server, Client , or BOTH), and an applicable OS, Action is set by default to BLOCK or PASS
Note: You can also find specific CVE-IDs (if applicable) for each signature, this will hyperlink to the info for that CVE, but also lets you quickly check you are protected against a new CVE, (you can type them in the search section).
Why is all that important? Well if you know that then, how the IPS profiles work is pretty self explanatory, it uses all the above to group signatures together by severity, target and OS, which enable you to make your own very granular profiles (if you wanted to).
So let’s have a look at them, Security Profiles > Intrusion Protection.
To take a look at each one, select it and edit, to be honest most of the time you will be wanting default or all_defaultthough (as you can see there are specific profiles for web servers and mail servers etc.
Note: Remember I mentioned the Suspicious URLs above? This is where you can enable that if you wish, be aware this is a dynamic list of URLs that you cannot edit (or whitelist) you need to make a request to FortiNet if you want to remove a URL from it. The documentation says;
“To use this IPS signature to block malicious URLs, select Block malicious URLs. This feature uses a local malicious URL database on the FortiGate to assist in drive-by exploits detection. The database contains all malicious URLs active in the last one month, and all drive-by exploit URLs active in the last three months. The number of URLs controlled are in the one million range.“
Also Note: Logging is disabled by default, (more on that in a minute).
Enable FortiGate IPS
To actually enable IPS is simple, in any normal Firewall Policy (or IPv4 Policy if you’re on ‘old code’) you enable the IPS Policy you require inside it like so.
Testing FortiGate IPS
Do a search for this and the web is full of articles on creating a custom signature adding that to a policy then testing it, which is a bit ‘bobbins’ IMHO. It’s an IPS, let’s put on our black hat and do something nefarious to make sure it’s working, (obviously ask a grown ups permission before launching attacks on your own network, and don’t send your IT security manager to PeteNetLive to complain, because I’ll just laugh at them).
OK, really straight forward, I’ve got KALI Linux running Armitage (a Metasploit tool) on my LAN. Which I’m going to use to attack a Windows server that’s sat just outside my FortiGate. Using a known RDP vulnerability. But first let’s enable logging on our IPS Profile.
Edit the policy (make sure it’s the one that’s actually getting inspected!) Enable packet logging > OK.
Launch Armitage, connect using the default settings, search for MS12_020 and you should see it listed (as shown) > Double click it > Enter the IP of the server to attack > Launch. After some code scrolls by eventually it will probably say ‘RDP service unreachable‘ (because our IPS has earned its wages).
Note: At this point I’d say go and have a coffee, IPS blocks instantaneously, but it takes a couple of minutes for it to appear in the logs.
Log and Report > Intrusion Prevention > Boom ‘time for tea and medals!’ (remember give it a few minutes). Dont forget to go back and disable logging on your IDS Policy.
Related Articles, References, Credits, or External Links
