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
I was back on the tools again today setting up FortiGate Port Forwarding! This was for one of our partners that I have to do some remote work for, so I temporarily needed to get onto their servers. Normally I’d just SSLVPN in, (but that’s what I’m setting up!) So to get onto their servers I had to setup a port forward for RDP.
WARNING: Port forwarding RDP from ALL / Any is a BAD IDEA (Cryptolocker anyone?) So if you must port forward RDP, then lock it down to a particular source IP like I’m about to do.
Fortigate Port Forwarding
The Process is;
Setup a ‘Virtual IP’ (with port forward enabled)
Create a ‘Virtual IP Group‘
Allow traffic to the Virtual IP Group.
FortiGate Port Forwarding: Create a Virtual IP
Policy and Objects >Virtual IPs > Create New > Virtual IP.
Give it a sensible name > Set the interface to the outside/WAN interface > External IP set to the public IP address of the firewall* > Mapped IP address, set to the internal IP address of the server you are forwarding to > Enable ‘Port forwarding’ > Select TCP or UDP > Type in the port(s) you want to forward. Forwarding a range of ports is much easier on a FortiGate than ‘some other’ vendors! > OK.
*Note: I’m assuming if you are port forwarding you only have one public IP, (or you’ve ran out).
FortiGate Port Forwarding: Create a Virtual IP Group
From the Virtual IP menu > Create New > Virtual IP Group.
Give the group a name > Select the outside/WAN interface > Add in the Virtual IP you created above > OK.
FortiGate Port Forwarding: Fortigate Add an ‘Address’
If you are port forwarding something like HTTP/HTTPS to a web server, or SMTP to a mail server you can skip this step. As per my warning above I’m restricting public access to one single public IP (mine). For most port forwarding scenarios you would set the source to ‘ALL‘.
Anyway for completeness here’s how to create an Address object. Policy & Objects > Addresses > Create New > Address.
Give it a recognisable name > Type=Subnet > Type the IP into the IP range box > Set the interface to outside/WAN > OK.
FortiGate Port Forwarding: Allow Port Forwarded Traffic
Policy and Objects > IPv4 Policy (or Firewall Policy on the newer firmware) > Create New.
Name: Something identifiable
Incoming Interface: Outside / WAN
Source: For RDP specify the single address you created above for all other port forwarding simply use ALL instead.
Destination: Your Virtual IP Group
Schedule: Always
Service: RDP (or the port you are forwarding if different)
Allow: Accept
Click OK.
FortiGate Port Forwarding: Troubleshooting Port Forwarding
You can see what’s going on by using the packet sniffer in the firewall.
[box]
diagnose sniffer packet {interface} 'host {External IP} and port {Port Number}' 4
e.g.
diagnose sniffer packet wan 'host 234.234.234.234 and port 3389' 4
[/box]
Note: In the example above I’m getting no return (ACK) traffic, (because the Windows firewall was on and dropping the traffic!) I diagnosed that by attempting to ping the server from the firewall (execute ping {internal IP address}) and failing to see a response!
Related Articles, References, Credits, or External Links
So my aim was to setup FortiGate High Availability failover in Active / Passive mode. I’m setting this up in EVE-NG and here’s what my lab looks like;
Note: Im using TWO connections for Heartbeat/Failover, you can simply use one if you prefer.
FortiGate High Availability (Pre-Requisites)
Obviously the firewalls need to be the same! For physical firewalls that’s straightforward, but be careful if you are using virtual FortiGates, make sure they are the same hardware and licence versions!
As you can see in my topology (above), each port needs to be connected to the same network on BOTH firewalls.
Make sure both firewalls are running the SAME firmware.
Make sure the interfaces are not getting their IP addresses from DHCP, or PPPoE.
I’m assuming the primary firewall is all setup and configured properly, the secondary firewall then needs to be built, licensed, and internet connected (so it can update etc). Note: It will take it’s config from the primary firewall when configured.
FortiGate High Availability (Active Passive) From Command Line
I know, Fortinet like to say that there’s no need to be working at command line these days, but when you see how easy it is to setup from CLI, you might choose to do it that way instead.
Primary FortiGate High Availability Setup
FortiGate uses priority to set the primary firewall, by default it sets the value to 128. So I’m going to set my Primary firewall to 200 and my Secondary firewall to 100.
Here are the commands you can simply copy and paste;
[box]
config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set override enable
set override-wait-time 10
set priority 200
end
[/box]
What does all that mean? The Group ID and Group Name, are shared by all firewalls in the cluster. (Yes cluster, you can scale this up to more firewalls). Mode simply sets the mode to a-p (active passive). Hbdev denotes the interfaces used for the heartbeat network, (the zeros denote that they will be used equally). Session-pickup allows the firewalls to share the session state table for your clients, (i.e. provides seamless TCP session failover). Override is enabled, this will fail back the the primary firewall when it becomes available. Note: wait-time is enabled and set to 10 seconds to avoid any ‘flap / stutter’ that may cause disconnections when executing the override. Then finally the priority is set to 200.
Secondary FortiGate Hight Availability Setup
Practically the same, but you don’t need to set override, and the priority will be lower (100).
[box]
config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set priority 100
end
[/box]
FortiGate HA Monitor and TroubleShooting
At this point go and have a coffee, the config needs replicating from the primary to the secondary, and this can take a few minutes. Use the following command to check;
[box]
get system ha status
[/box]
You want to see them both ‘in-sync‘.
To troubleshoot, use;
[box]
diagnose system ha status
[/box]
FortiGate Failover (Active Passive) From GUI
On the Primary (pre configured) firewall, System > HA > Change the drop down to Active-Passive.
Monitor Interfaces: {you can leave this blank, unless you only want to monitor certain interfaces}.
Heartbeat Interfaces: {enter one or more interfaces}.
What’s Management interface Reservation? : You can use this to have separate management for each firewall, (usually you can’t get to the standby/secondary firewall for GUI/SSH management etc).
Clock OK when complete
You should see something like this;
Jump onto the Secondary firewall, and set it the same, (with the exception of the priority).
Note: Override (Fail Back) cannot currently be set in the GUI.
Wait a while and hit refresh, you should see both firewalls in Sync
Possible Bug in 6.4.4 build 1803 (GA)
When carrying out the above procedure (from the web management console), my firewalls did not sync, while trouble shooting at command line they were both set as primary and appeared not to be able to see the other, they were saying;
{Firewall Serial Number}is selected as the master because it’s the only member in the cluster.
Despite many hours of troubleshooting/rebuilding, this kept happening, it worked fine when configured from command line, but not from the GUI. When I checked the commands after using the GUI I noticed that “set group-id {number}” was missing from the config. If I added this manually it started syncing straight away?
Related Articles, References, Credits, or External Links
Thanks to the good folk at Fortinet for sending me some licences to test this (much appreciated).
Do you inspect the traffic on your network? You have a firewall? Maybe an IDS appliance? That’s good news, do you inspect HTTPS traffic? In most cases the answer is no. Because either you do not have the capability, or enabling SSL Inspection will degrade the firewall’s performance so much that you accept the risk.
At time of writing (Early 2021) it’s estimated that 85% of all web traffic is now encrypted. Let that sink in, 85% of the web traffic traversing your firewalls and security appliances is potentially not even getting looked at, because it’s encrypted.
Probably over ten years ago I was at a security convention, and the speaker asked the crowd “What’s TCP Port 443?”, This prompted the obvious answer of “It’s HTTPS!” No, its the universal hacking and exploitation port!
Do something ‘Nefarious‘ and it’s best to do it over HTTPS, (or protect it with SSL encryption.) The last time I was asked to look at inspecting HTTPS traffic, it had such an adverse affect on the firewalls performance, the client looked at extra hardware (SourceFire at the time,) to do this instead of the firewalls, and the firewalls in question were a pair of ASA-5585 SSP40’s (that’s a 6 FIGURE price tag!).
When I saw the comparison of degradation between firewall vendors I was somewhat skeptical, but Fortinet do make some bold claims. Typically their marketing and sales ‘Battlecards’ show about 15% degradation with SSL inspection enabled, (that’s on a 500E) and that is typically compared to 73% degradation on a Cisco Firepower (4000 series), or 79% on a Palo Alto (5220), or 79% on a Check Point (15600). Note: I’ve not checked these figures.
So how easy is it to setup? Well to be honest it’s painfully simple, just bear in mind on a FortiGate there’s two ‘Types’ of SSL Inspection;
SSL Certificate Inspection: The FortiGate Checks the certificates presented to ensure the common name is correct, (resolvable) and checks it against a database of problem URLs and certificates.
SSL Full Inspection (Deep Packet Inspection): The Fortigate ‘Brokers the SSL traffic’ and sits in the middle, it decrypts and re-enrypts the traffic before sending it onto the end user, or the remote server. To do this it needs to be able to generate and sign certificates for any domain, and you need to trust it to do so.
If you are already running a FortiGate, you probably already have SSL certificate inspection enabled on your default internet access policy and didn’t even realise it! Below we will look at deep packet inspection.
FortiGate SSL Inspection (Simply)
WARNING: Read the whole article first, simply turning this on without some forethought and planning (in production) will result in bad things happening! Remember your clients’ have to trust the Firewall and at the moment they probably do not!
The FortiGare has its own built in Certification Authority, initially I’ll use that (below I’ll demonstrate how I would do this with a ‘proper’ domain PKI deployment). From the firewalls management page System > Certificates > Locate the Fortigate_CA_SSL certificate and download it.
Put that certificate on one of your client machines and then import/trust it. Below I’m making things as difficult as possible, and using Kali Linux, on a Windows box, double click the cert import it, and manually place it into ‘Trusted Root Authorities’ store.
Note: If you use Firefox as a browser, you will need to take extra steps see this article.
Now on the ‘Policy’ that’s being applied to your web traffic, we need to alter the SSL inspection. Policy & Options > Firewall Policy (or IPv4 Policy on older models) > Locate your policy for normal web traffic and edit it.
Change SSL Inspection to ‘deep-inspection’ > OK
Note: In the example shown below, I have AntiVirus inspection enabled, I mention this because that’s what I will use to test that SSL inspection is working.
So now when my clients go to any https:// website, the certificate that the client sees, is actually signed by the firewall NOT a publicly signed certificate vendor.
To ‘Test’ that you can go to the Eicar website (if you didn’t know Eicar produce files for testing AntiVirus and AntiMalware solutions) and attempt to download one of the files (Note: MAKLE SURE you attempt to download from the HTTPS section!)
What Next?
Well that was easy! Now for a real world deployment. Your problem is getting your client to trust the firewalls CA Signing certificate. You have THREE OPTIONS
Option 1: Manually install the certificate on your clients, if you have a small organisation then that might be a good option, the built in cert lasts ten years, you will probably have a new firewall before that certificate expires.
Option 2: Distribute the FortiGates CA signing certificate by Group Policy. For medium sized deployments, of if you are one of those that’s typically terrified of certificates, this might be your option.
Option 3: You have a properly deployed Certificate Services PKI deployment already, you can issue a SubCA certificate to the firewall to do the signing with, and your domain clients will trust it automatically.
I wont insult your intelligence explaining Option 1, but Options 2 and 3 I will outline below.
Deploying FortiGate CA Signing Certificate By Group Policy
On the Fortigate you need to download a copy of the CA certificate it uses, typically it is called Fortigate_CA_SSL. From the management GUI > System > Certificates > Select Fortigate_CA_SSL > Download > Save a copy somewhere you can get to it.
On a domain controller > Administrative tools >Group Policyy Management > Create a new policy (or you can edit an existing one.) Below I’m linking mine to the root of my domain, you may want to link yours to the OUs that your computer objets are in.
Follow the wizard, navigate to and select the certificate from the FortiGate > Make sure that it gets put in the Trusted Root Certification Authority store!
Replace FortiGate SSL Inspection CA Cert with a Microsoft Certificate Services SubCA Cert
This would be my preferred choice, if you have a proper PKI deployment in your domain your client will already trust it, so all you have to do is use a SubCA cert to the firewall. If you don’t have a PKI deployment yet, but this is the correct route to take run though the following first to get up and running;
Even with your own Microsoft Certificate Services deployment, it’s just worth a quick check that you already have a template for ‘Subordinate Certification Authority‘. (it’s typically deployed by default).
I’m going to apply for my certificate using the ‘Certificate Authority Web Enrollment Role’ (this is an additional role you can add to Certificate Services to give you this nice web portal for getting certificates). Web browse to https://(FQDN-of-Certificate-Server}/Certsrv (Note: yours may be on http://) > Request a Certificate > Advanced Certificate Request > Create and Submit a Request to this CA.
Template: Subordinate Certification Authority
Name: The FQDN of the firewall (must be resolvable in DNS!)
Email to Country/Region: Fill out as applicable
Key Size: 2048
Mark keys as exportable: Ticked
Submit.
Install this certificate.
Use MMC to Inspect User Certificates
This will have dropped the certificate in YOUR user certificate container, we now need to locate and export it.
Windows Key +R > mmc.exe > File > Add/Remove Snap-in > Certificates > Add > Select User Account.
Expand Certificates – Current User > Personal > Certificates > Locate the certificate > All Tasks > Export.
Next > Yes: Export the private key > Next > Personal Information Exchange (PFX) > Next > Password (Type and confirm password you will remember) > Change the encryption to AES256–SHA256 > Next > Select a location to save the certificate > Next > Finish.
Back at the FortiGate > System >Certificates > Import Local Certificate.
Type: PKCS # 12 > Upload > Locate and select the certificate you exported above > Enter The password > Upload > OK.
Give the policy a sensible name > Change the CA Certificate to the one you just uploaded > OK.
To use that Profile in your web access policy, Policy & Objects > Firewall Policy > Locate the policy that defines web traffic and edit it.
Change the SSL Inspection to use your new profile > OK.
Now you can test the deployment by going to an https secure website (like this one!) and taking a look at the certificate, it should have been issued by your SubCA/Firewall.
Related Articles, References, Credits, or External Links
Continuing with my ‘Learn some Fortigate‘ theme’. One of the basic requirements of any edge firewall is site to site VPN. As the bulk of my knowledge is Cisco ASA it seems sensible for me to work out how to VPN both those firewalls together, like so;
Well that’s the pretty picture, I’m building this EVE-NG so here’s what my workbench topology looks like;
Disclaimer (Read First! Especially before posting any comments!)
Fortinet prides itself on you not needing to use the CLI, (until you actually need to use the CLI of course!) But both ends are configured using the GUI and ASDM. This is designed for the ‘Let’s just make it work, who cares what’s going on under the hood‘ generation. Which means it enables IKEv1NOTIKEv2 on the Fortigate, and BOTH IKEv1 and IKEv2 gets enabled on the Cisco ASA. Couple that with all the weak Crypto sets that get enabled, because someone might have a hardware firewall from 1981 or something! So in production I’d consider doing things a little more manually. I will post another article on the same subject, but then I’ll make the tunnel as secure as I can, (watch this space). This is an exercise in getting the tunnel up and making it work.
Tech Note: If you just use both wizards it wont work, thankfully I could debug the tunnel on the Cisco ASA to work out why. Fortinet sets all the DH groups to 5, and Cisco sets them all to 2. And Fortinet enables PFS and Cisco don’t. (They do on older versions of the OS, but not on the newer ones).
Create IKE/IPSec VPN Tunnel On Fortigate
From the web management portal > VPN > IPSec Wizard > Give the tunnel a name > Change the remote device type to Cisco > Next.
Give it the ‘public’ IP of the Cisco ASA > Set the port to the ‘outside’ port on the Fortigate > Enter a pre-shared key, (text string, you will need to enter this on the Cisco ASA as well, so paste it into Notepad or something for later) > Next.
Local interface will be in the ‘inside’ interface on the Fortigate > Enter the local subnet(s) > Enter the remote (behind the ASA) subnet(s) > Next.
Review the settings > Create.
Select IPSec Tunnels > Select the new tunnel > Edit.
Connect to the ASDM > Wizards > VPN Wizards > Site-to-Site VPN Wizard > Next.
You should already have an object for your Local Network add that in > Then add in a new Network Object for the remote (behind the Fortigate) subnet. MAKE SURE that the new object is selected as the Remote Network > Next.
Enter the Pre-Shared key you used (above) > Next > Tick to DISABLENAT > Next > Finish.
Tech Note: Look at all those Ciphers/Hashing/Additional Protocols that are about to be turned on! 🙁 That’s why I work at command line.
Finally you will need to send some traffic over the tunnel to ‘bring it up’.
If you have a problem, see the debugging/troubleshooting links below.
Related Articles, References, Credits, or External Links
The firm I work for are looking at a replacement for Cisco ASA as their preferred firewall of choice. We are looking at Fortinet to fill this gap, but as a product/solution it’s something I know very little about.
So the best way to learn is to deploy and play with, and the test bench weapon of choice for discerning technical types is EVE-NG. So can I deploy the newest (v6.4.2 at time of writing) Fortigate firewall into EVE-NG? Indeed, read on.
Solution
Getting the VM is pretty easy, Fortinet allows you to create a free login account, and download the trial version. REMEMBER you want the KVM version of the appliance!
If you didn’t know EVE-NG (and the Qemu software that runs inside it) needs to have its images in certain named folders. So log into your EVE-NG appliance and create a new folder;
Note: fortinet-xxxxxxxxxx is the correct naming convention 🙂
Now copy your downloaded image into this folder, I use WinSCP, but FileZilla is also free. Remember that your transfer method should be set to ‘binary’.
Back in the EVE-NG console, you need to unzip the appliance, then rename it (EVE-NG also needs the images to have certain names). Then you can delete the original Zip file, and make sure the permissions are set correctly.
[box]
cd /opt/unetlab/addons/qemu/fortinet-FGT-v6.4.2
unzip FGT_VM64_KVM-v6-build1778-FORTINET.out.kvm.zip
mv fortios.qcow2 virtioa.qcow2
rm FGT_VM64_KVM-v6-build1778-FORTINET.out.kvm.zip
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions
[/box]
That’s the hard part done. Log into EVE-NG create a new lab and drop a Fortigate device into the workspace. (Note: You can raise the RAM to 2048 to get it to perform a little better, but no higher though, as only 2GB is permitted with the trial licence).
Allow Web Management Of Fortigate VM
I’ve included this bit because most articles don’t, and if I’m unfamiliar with Fortigate, then some of you will be also. Essentially you setup the interface that you will be using as the inside interface with a static IP and allow web management via HTTP. (Note: First you will be asked to change the Admin password).
[box]
config system interface
edit port1
set mode static
set ip 192.168.1.1 255.255.255.0
set allowaccess http
end
[/box]
Then from a management VM, (on the same network segment) connect to the appliance and log in.
If you just see a blank screen with no logon options see this article.
Related Articles, References, Credits, or External Links
I was having some problems setting up a Fortigate (VM64-KVM) firewall, and I needed to know, (at command line,) how to view the address that had been assigned to it via DHCP.
View Fortigate DHCP address (from CLI)
The syntax required is;
[box]
config system interface
edit ?
[/box]
Note: Dont Forget the “?” at the end, it will not show onscreen as seen below.
View Fortigate DHCP address (from GUI)
If the GUI/Web access is working, simply go to Network > Interfaces.
Related Articles, References, Credits, or External Links
