Fortigate VPN problems? Tell your Fortigate what to do.
I spent a long while trying to bring up a tunnel to a third party over a dedicated extranet using a Fortigate and a Checkpoint.
The IPsec phase configs were very simple. And we double checked several times that they were the same. I even produced PCAP files at the interface to verify.
The majority of the complexity was in the network configuration.
Basically, our “routing provider” (extranet), by their policy, would not do us the favor of NATing by packet destination address. They would only perform NATing by source address. Since we were using them to inter-connect to two different sites, we had two different NAT address pools to pick from, one that each destination was expecting.
The second, and troublesome, third party we were inter-connecting to required that a VPN be put in place. “No problem!” I thought (of course). But I didn’t foresee how the dumbed-down configuration methods that Fortigate has would so greatly affect the difficulty.
First off, I had to change the source address of the IPsec packets that were destined for this third party (let’s call them Bob). Bob would only accept traffic from 220.127.116.11, and the only way my packets would be NATed to this is if they were tagged with the source address 192.168.115.40. “Simple,” you think. “That’s what a NAT statement at the interface is for!” Wrong. Not on a Fortigate. On a Fortigate, the setting is configured IN the VPN tunnel Phase 1 configuration, and the setting is called “Local Gateway Address.” How is any of this related to a “local gateway?” And why would I be configuring the “local gateway address” to be the source IP of my IPsec packets? What madness!
Anyway, after figuring out this cryptically named setting. I saw the packets… I saw them going… Bob saw them coming… Bob then replied… I saw them coming back… But, yes, after over 10 hours of active troubleshooting, calls to Fortinet (“is this a bug?!”), everyone realized… The Fortigate didn’t know where 192.168.115.40 lived! I really think this is VERY stupid… they make it idiot proof, with their “friendly” “local gateway address” setting (when all I want is to just NAT some damn packets at the interface), but don’t want to make it too idiot-proof and associate a secondary IP with the interface, so the Fortigate knows what that traffic is. But… no. I can’t just add a secondary IP to an interface that’s within a subnet that exists on any interface… there’s a boolean setting for that (per vdom). That setting is:
config system settings set allow-subnet-overlap enable
Once you set this, don’t you dare try to set the secondary IP in the GUI, where there is a nice shiny button… Because, it won’t allow you to set it! You must do that through the CLI as well, the setting is :
config system interface edit [interface name] set secondary-IP
So, all in all, you want something to work? You have to tell it to work.
It’s things like this that make me question why I call myself an infrastructure engineer!
Remember the following things are your friends!
#debug vpn diag debug enable diag debug console timestamp enable diag debug app ike -1 #sniff traffic diag debug enable diag debug console timestamp enable diag sniffer packet any 'host [ip address]' 1 #debug firewall policy packet flow diag debug enable diag debug console timestamp enable diag debug flow filter addr 18.104.22.168 diag debug flow show console enable diag debug flow trace start 1000 #clear all debugging stuff diag debug flow show console disable diag debug flow trace stop diag debug flow filter clear diag debug disable diag debug reset