Category: Fortinet

This article does a great job of summarizing this process already, but I wanted to describe a few caveats and explain the formatting of the script a bit clearer:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-send-automated-backups-of-the-configuration/ta-p/198364

Here is an example config of this with all of the required components:

conf system automation-action
	edit AutomatedConfigBackup 
	unset script
	set script "execute backup config ftp \"/Fortinet_Backups/FortigateBackup.conf\" 10.10.10.10 \"Domain\\UserHere\" PasswordHere"
end


config system automation-trigger
	edit "AutomatedConfigBackup"
	set trigger-type scheduled
	set trigger-hour 22
	set trigger-minute 58
	next
end


 edit "AutomatedConfigBackup_FTP"
        set trigger "AutomatedConfigBackup"
        config actions
            edit 1
                set action "AutomatedConfigBackup"
                set required enable
            next
end

All of this is easy enough to follow along, except for the format of the backup script and command itself. Let’s analyze this further to see why it is formatted as such:

set script "execute backup config ftp \"/Fortinet_Backups/FortigateBackup.conf\" 10.10.10.10 \"Domain\\UserHere\" PasswordHere"

With FortiOS and this “set script” command with quotes around it, you have to use the \ character to include the “” around the path and username so it includes it exactly.

You must have quotes around the path for it to work. For Windows use the / slash for the path and \ for the domain\user

From the documentation:

Special characters

The following characters cannot be used in most CLI commands: <, >, (, ), #, ‘, and “

If one of those characters, or a space, needs to be entered as part of a string, it can be entered by using a special command, enclosing the entire string in quotes, or preceding it with an escape character (backslash, ).

To Start the debug:

diagnose wireless-controller wlac sta_filter clear
diagnose wireless-controller wlac sta_filter [MAC address here in format xx:yy] 255
diagnose debug enable
diag debug console timestamp enable

To stop the debug:

diagnose wireless-controller wlac sta_filter clear

diagnose debug disable

diag debug console timestamp disable

If you are using the SSL VPN Web Portal, and you are allowing access to resources that are accessible over a site to site VPN tunnel from the FortiGate, there are several considerations to keep in mind.

With the web portal, the firewall will proxy the connection from the user to the actual resources. If the resource is on the local network and the firewall has a route to the destination, it will source traffic from one of it’s interfaces that is “closest” to the end device. This may be the local LAN/internal interface.

However, if the resource is available only across a site to site VPN tunnel, then the firewall will try and source this traffic from the “closest” IP to the site to site VPN tunnel. If there is no IP address explicitly configured on the VPN tunnel itself, then it will choose the public IP used in the VPN tunnel termination. Many times, the public IP isn’t allowed to pass traffic across the actual VPN, and so this will be rejected.

The best thing to do would be to assign an IP address to the tunnel interface itself. When this is configured, the firewall will use this IP address to proxy and source the traffic from. Additionally, you must make sure that this IP address is allowed on the VPN as far as the proxy-IDs, routes on the other end, and any security rules on both ends that control traffic access.

This article describes how to list all VPN tunnels using SNMP and monitor the status of individual tunnels.

This shows all VPN tunnel names and their corresponding OIDs to then be able to monitor:

snmpwalk -v2c -c string_here 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3

This will monitor one of the VPNs determined from the first output:

snmpwalk -v2c -c Hotlips1 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3.2.1

---

For Interface Monitoring, you’ll need to retrieve the SNMP index number matching the actual interface you want to monitor. Run these commands to see the index numbers and match with the interface:

“config system interface”

“show”

Then take the index number and use this base OID:

.1.3.6.1.2.1.2.2.1.8

That will show all of them, pick the interface with the index you want to monitor.

For example, to monitor interface with index 6 use:

.1.3.6.1.2.1.2.2.1.8.6

By default, the FortiGate does not send the Policy Name or Comments from the policies in logs to FortiAnalyzer or any remote logging server. This makes troubleshooting more difficult.

You must turn this setting on manually from the Fortigate CLI:

config log setting 
set log-policy-comment enable
set log-policy-name enable 
end

The FortiAnalyzer and FortiManager Admin Guides provides great information, but one thing i’ve found it lacking is a concise, quick method of giving a VM a new management IP address through the console so you can manage it through the GUI.

Admin Guide: https://docs.fortinet.com/document/fortianalyzer/6.2.0/administration-guide/

Here is a quick script you can use for the initial setup after the VM is deployed to get a new management IP setup, default route set, and management protocols enabled:

config system interface
edit port1
set ip 10.10.10.10 255.255.255.0
set allowaccess https ssh
end
config system route
edit 1
set dst 0.0.0.0 0.0.0.0
set device port1
set gateway 10.10.10.1
end

Now you should be able to access FortiAnalyzer or Manager using the GUI with https://10.10.10.10

In a situation where you have a VIP configured to perform Destination NAT for traffic incoming from the Internet to an internal server, and you have a policy “above” the allow policy to the VIP in precedence, you will notice that by default the “above” policy isn’t functioning as expected when traffic is destined to the VIP.

This is extremely frustrating and isn’t how any other firewall i’ve worked on functions, but what happens is that the VIP translation is hit earlier on in the packet processing on the Fortigate so the policy that references the VIP gets used even if it is farther down in precedence than say a geo-filtering policy blocking all incoming traffic (allegedly to all hosts) from China.

That means that even though you think you have policies denying traffic above your VIP rules that it won’t matter. This is very concerning and probably needs to be addressed by Fortinet. Unless you really investigate logs to confirm that the deny rule above your VIP rule is getting used, this may go missed for a while.

The below link from Fortinet describes the problem in more detail and discusses possible solutions.

https://kb.fortinet.com/kb/documentLink.do?externalID=FD36750

The key is that you can add the “set match-vip enable” line to the “above” policy config to make sure that even if a VIP is a destination, that this deny rule gets used instead of the permit rules that the VIP is associated with. Alternatively, you can use the VIP in the “above” deny rule explicitly as the destination.

 config firewall policy 
 edit 36 
 set match-vip enable

When trying to setup a FSSO fabric connector for Active Directory polling or when using LDAP for authentication with Forticlient or firewall administration, and when the AD controller is across a site to site VPN, the fabric connector and LDAP profile will attempt to use the public IP of the firewall for the source IP.

If you only need to send LDAP authentication requests across a VPN, you can simple set the source-IP option when configuring the LDAP profile in the CLI.

In this case, the source IP of 10.255.255.1 resides on the internal interface of the firewall itself and will source all requests to the DC at 10.10.10.100 using 10.255.255.1. You must ensure that 10.255.255.1 is allowed across the VPN and permitted by policy on the other side.

Here is the snippet of the config to use for the LDAP Profile:

config user ldap
    edit "AD Profile"
        set server "10.10.10.100"
        set source-ip 10.255.255.1
        set cnid "sAMAccountName"
        set dn "dc=test,dc=com"
        set type regular
        set username "cn=Administrator,cn=Users,dc=test,dc=com"
    next
end

If you are using FSSO across a VPN, there is an addition consideration that is explained well in the below document. Using the source-IP in the LDAP profile isn’t sufficient and isn’t taken into consideration.

Basically, when using a FSSO Fabric Connector, you must configure an IP address on the tunnel interfaces themselves which forces the Fabric Connector to use that IP address to source the Fabric Connector requests. There isn’t an option to source the Fabric Connector traffic from a specific IP address in the GUI or CLI like you can with the LDAP profile.

Link to Fortinet reference: https://kb.fortinet.com/kb/documentLink.do?externalID=FD41468

The SIP Application Layer Gateway (ALG) is enabled by default on Fortigate firewalls. I have seen a number of phone systems have troubles with phones registering when this is enabled so the following steps can be used to disable the ALG. This is typically for hosted cloud-based phone systems where the phones have to register to a server hosted by a service provider and must traverse the firewall and NAT.

Backup the configuration before making these changes.

Run following commands from Fortigate firewall CLI:

config system settings 
set sip-helper disable 
set sip-nat-trace disable 
set default-voip-alg-mode kernel-helper-based 
end

Next, we need to locate SIP entry in session helper list and delete it

config system session-helper
show

Scroll down until you see an entry for SIP. In most cases I have seen this listed as 13.

delete 13 
end

Here is the original configuration for this block if you have to restore it:

edit 13 set name sip set protocol 17 set port 5060

Finally, we disable the RTP protocol processing on the firewall:

config voip profile 
edit default 
config sip 
set rtp disable 
end 
end

A reboot was required to make this all go into affect. Without the reboot, tests showed the ALG disabled, but calls were not working and phones did not register. This was a Fortigate running 6.0.4. Other times with 6.0.5 I have noticed that the rebooted was not required.