Blog: Fortigate

When a FortiGate is managed via FortiManager, administering the FortiGate outside of FortiManager can cause the configuration to become out of sync. While updating an SSL certificate used for VPN access on a FortiGate for a customer, I found that I was unable to create a certificate signing request from FortiManager. After doing some research, I found a Fortinet cookbook article that explains that the certificate must be requested and the certificate request completed from the FortiGate itself, even if the device is managed via FortiManager. To complete this process, do the following:
  • Login to the FortiGate in read-write mode
    • Create a certificate signing request on the FortiGate
    • Download the certificate signing request from the FortiGate
    • Submit the certificate signing request to the certificate authority
    • Download the issued certificate from the certificate authority
    • Import the certificate on the FortiGate to complete the certificate signing request
  • Login to FortiManager
    • Select the FortiGate in Device Manager and go to the "System: Dashboard" page
    • In the "Configuration and Installation Status" pane, click the "Revision History" (four horizontal lines) icon on the "Total Revisions" line
    • Click the "Retrieve Config" button
    • The current configuration, including the new certificate, will be retrieved.
    • The certificate should now be able to be used in configurations managed in FortiManager
If you are deleting the old certificate, you will need to write the config to the FortiGate from FortiManager so that it is no longer using the old certificate. After the old certificate is no longer in use, you can login to the FortiGate in read-write mode and delete the old certificate. After the old certificate is deleted, you will need to repeat the "Retrieve Config" operation.
 
The Fortinet cookbook article explaining this process can be found at https://kb.fortinet.com/kb/documentLink.do?externalID=FD35142

 

How to initialize a Fortigate UTM appliance for disposal or re-use after it has been replaced by a new Fortigate appliance.

Power up the device. Interrupt boot by pressing a key during boot. A menu will be displayed:

Select "F" to format the boot device, and respond "y" to the next question:

The boot device will be formatted and the appliance is now ready for disposal.


 

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.