Blog: Fortigate

Part 1: When installing the Fortigate Single Sign-On Agent you need to configure the service account as a local admin on the server where it's being installed.  Fortinet support states that the account has to be a domain admin, but I have confirmed that it only needs local admin rights, and not domain admin rights. 

Part 2:  When installing the Duo Authentication agent on a server to use multi-factor authentication with a Fortigate, it uses port 1812 to communicate with the Fortigate for Radius authentication.  If you have already installed the Fortigate SSO Agent on that same server it will already be using port 1812 to communicate with DCs on the network.  This will cause the Duo agent to fail to start each time you attempt to start the service.There are a couple of possible fixes to this:

  1. Change the port on the Fortigate SSO agent to another port (1813).  This will also require that you specify that port on the Fortigate DC Agents installed on your domain controllers.
  2. Change the port used by the Duo agent to another port.  This can be done in the configuration file found in the Duo installation directory.  This will also require that you change the default Radius port on the Fortigate via CLI to match what you specified in the Duo configuration.  This may cause issues if your Fortigate uses multiple Radius clients/agents.

 

 

Recently I was troubleshooting an issue with a customer who was having issues with their VPN connection from a Fedline Fortigate appliance through a Cisco ASA firewall. After taking a packet capture I saw that the Fortigate was responding to the ASA’s ARPs, but the ASA was ignoring them:

I turned on ARP debugging on the ASA and saw the following:

arp-in: response at dmz from 10.x.x.10 085b.xxxx.xxxx for 10.x.x.254 885a.xxxx.xxxx having smac 085b.xxxx.xxxx dmac 885a.xxxx.xxxx

arp-in: src ip is same as one of nat mapped address 10.x.x.10 .Consuming the packet

 

A search led me to an email in the cisco-nsp mailing list email and Cisco Bug ID CSCuc11186 (Cisco login required). If you don't have a Cisco account, the relevant line from the bug report is:

NOTE: The fix for this issue may cause the ASA to not reply to ARP requests if the Source IP in the ARP request overlaps with a NAT rule on the ASA. This may occur when the NAT configuration line is overly broad (such as an all zeros configuration, or any. To workaround this, add the keyword "no-proxy-arp" to the nat config line.

 

The issue wasn’t due to the bug itself, but due to how the bug was fixed. Similar to the post in teh cisco-nsp group proxy ARP was disabled on the DMZ interface. However, proxy ARP was not turned off on the NAT rule. 

 

Changing the NAT rule to ‘nat (inside,dmz) source static any unidirectional no-proxy-arp’ fixed the problem.