I recently had a problem where a customer’s FortiAP 221C AP’s would intermittently stop broadcasting the SSID’s assigned to the 5Ghz Radio.
I had a look at the FortiAP profiles and saw that all channels were selected, including channels 149, 153, 157, 161 and 165. I deselected those so that my configuration was as per below:
Once I did that the AP’s started broadcasting on 5Ghz again. Not sure yet if this is a regulatory limitation due to my country code (ZA) or a bug.
I recently had a Fortigate 1500D become bogged down due to the reporting daemon (reportd) utilizing 100% CPU. I will not go into a lot of detail about diagnosing performance issues, as that is not the topic of this post. Suffice to say that you’ll need to run the following commands to determine which process is misbehaving:
#get sys perf status
#diag sys top
#diag hard sys mem
Typically one would kill and respawn the offending process with the following command, where process_id is obtained via the diag sys top command.
#diag sys kill 11 process_id
Unfortunately in this case the kill command did not actually kill the process, and a reboot was not an option. Fortunately I once had a remote session with Fortinet TAC where I saw them using some hitherto unknown (to me) commands. So what follows is an unsupported way to absolutely kill processes dead.
The command we use is fnsysctl. This command allows us access to a subset of Linux utilities, like cat, ls, kill etc. In this case we’re interested in the kill command:
#fnsysctl kill –9 process_id
I have never had this command fail to kill a process, although I would recommend only using it as a last resort.
Happy Hunting!
There is an potential issue when setting up SSL VPN to listen on multiple interfaces on FortiOS 5.2.2 (have not tested on earlier versions). When you create the first SSL VPN listener the Fortigate will automatically create a policy to allow SSL VPN traffic. Due to the way the information is presented one can be excused for thinking the unit will do it for additional listeners as well. The screenshot below shows how it looks when SSL VPN is enabled on multiple interfaces via the GUI:
These are the relevant bits taken from the configuration file:
config vpn ssl settings
set idle-timeout 900
set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1"
set source-interface "MTN" "MTC"
set source-address "all"
set source-address6 "all"
set default-portal "tunnel-access"
config authentication-rule
edit 1
set source-interface "MTN"
set source-address "all"
set groups "VPN"
set portal "full-access"
next
end
end
From the above it is clear that the listener has been added, but the authentication rule has not been updated. The fix is simple, just add an additional authentication rule via the CLI:
config vpn ssl settings
config authentication-rule
edit 2
set source-interface "MTC"
set source-address "all"
set groups "VPN"
set portal "full-access"
next
end
end
Your SSL VPN clients will now be able to connect on all interfaces specified in the GUI.
Had a scenario recently where a Polycom video conferencing device just wouldn’t work when sat behind a Fortigate firewall. This was despite all the necessary TCP ports being forwarded to the device, as verified by Polycom support.
What we were seeing is that one could dial the VC but it would just ring and never make the connection. Time to debug the traffic on the Fortigate – this is what I saw:
id=13 trace_id=74 msg="vd-root received a packet(proto=6, x.x.x.x:1720->x.x.x.x:63665) from lan."
id=13 trace_id=74 msg="Find an existing session, id-02237475, reply direction"
id=13 trace_id=74 msg="SNAT x.x.x.x->x.x.x.x:1720"
id=13 trace_id=74 msg="run helper-h323(dir=reply)"
The “run helper” sequence kicked in as soon as one attempted to pick up the call on the VC. In Polycom’s case they suggest explicitly disabling any h323 helpers, so that is exactly what I did. I did it like so:
Your h323 and SIP traffic should now traverse your Fortigate without issue. In my experience this has only happened with Polycom devices, Microsoft Lync works fine without modification.
Recently had a customer complain that he cannot access documents on his file server when connected via SSL VPN. Closer inspection showed that the customer was trying to access the fileserver by hostname “\\fileserver” as opposed to “\\fileserver.corp.local”.
The fix seemed to be simple, implement a DNS search suffix. Unfortunately there is no such option in the GUI, so I had to set it via command-line.
config vpn ssl settings
set dns-suffix corp.local
end
Navigate to VPN –> SSL –> Settings –> Tunnel Mode Client Settings. Specify the DNS Server setting and enter the IP addresses of your corporate DNS servers.
Your Fortigate will now append the “corp.local” suffix to all non-qualified hostnames. This was tested on FortiOS 5.06, 5.07 and 5.2
I recently had to configure a FortiGate Active – Passive HA cluster. I did the configuration through the GUI, but no matter what I did it always reverted back to Standalone mode.
I then dropped into jedi (aka the CLI) mode and tried to configure the cluster from there, like so:
-------------------------------------------------------------------------------------------------------------------------------
FORTIGATE # config system ha
FORTIGATE (ha) # set mode
standalone Standalone mode.
The system may run in HA A-A or HA A-P mode only when all interfaces are NOT using DHCP/PPPoE as an addressing mode.
-------------------------------------------------------------------------------------------------------------------------------
And there is our problem – no interfaces are allowed to be set to DHCP if you want to enable HA. I corrected this and then proceeded to configure HA.
FORTIGATE (ha) # set mode a-p
FORTIGATE (ha) #
I tested and was also able to set this via the GUI now. First prize would of course be if FortiNet properly handles the error in the GUI, but nice to know that the proper error message is given the CLI.
Getting AD authentication going on a Fortigate is a slightly finicky, but well documented process and once you get it working it works well. If it’s something you battle with, leave a comment and I’ll do a HowTo.
That said I recently had an issue with a Fortigate unit that absolutely insisted on putting all FSSO users in the FSSO_guest_users group, which means none of my Policies using authentication was working. This is what the Fortigate saw my logged on users as:
The fix in the end was fairly simple, turns out that on the Fortigate I had the groups configured in Advanced mode, like so: CN=Internet Access,OU=Security Groups,OU=Head Office,DC=corp,DC=root.
The Collector Agent, however, was configured to use Standard mode. The fix was to switch the FSSO Collector Agent Directory Access Mode to Advanced Mode.
Once the change was made I refreshed the FSSO groups on the Fortigate via the “execute fsso refresh” command and all was well again.
For those of you keeping notes, the Fortigate was running FortiOS v5 Patch 6 and the FSSO agent was v4.0 MR3 B0151
Fortigate is a deserved market leader in the UTM space, but as with all products there is always room for improvement. Point in case is getting a 3G / LTE connection via a USB dongle up and running. There is minimal support in the GUI, and they’ve removed a lot of options in FortiOS 5.
Fortunately for an old Cisco hack like myself we’ll always have the CLI to fall back to so below are the steps to get it up and running. Note that the below is for a device that is on the Fortigate HCL. If yours is not then you’ll have to configure that first.
config system modem
set status enable (Enables the modem functionality)
set pin-init "at+cpin=1111" (If you have PIN security, I tend to disable the SIM PIN check)
set dial-on-demand enable (self-explanatory)
set phone1 "*99#" (replace *99# with whatever your dial-up number is)
set extra-init1 "at+cgdcont=1,\"ip\",\"internet\"" (replace internet with your APN)
set altmode disable (enable if you're in China, rest of the world disable)
end
