When a secondary public IP address is utilized for VPN connections, the configuration of an IPSEC VPN versus an SSL VPN is quite different. For an IPSEC VPN, it's as easy as turning flipping a switch and selecting the IP address:
For SSL VPN it takes a couple of steps: First a Virtual IP (VIP) has to be created that points the primary IP at the secondary IP. Additionally include port forwarding for the SSL port to be utilized:
Second, an IPv4 policy needs to be created using the WAN interface for both incoming and outgoing, with the destination being the VIP:
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:
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.