Category: Security

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.