Newly Created IPsec Tunnels Not Functioning

[rharms_tarc]

I just finished creating a large number of site-to-site IPsec tunnels (approx. 170) using the CLI, but most of them don't seem to be functioning. Only six or eight of them have ever come up and connected.  I can see all of them in the gui, and in a backup of the configuration, so they definitely created.  

At first, I thought it was an issue with the way the PSK had imported from my script, so I went through a number of them and re-entered and saved the PSK from the GUI to ensure that it encrypted correctly, but that didn't seem to remedy the issue.

If I go into the CLI and run 'diagnose vpn ike gateway' I see entries for the 6 or 8 that work, but not for the rest.  If I run the command for a specific tunnel name, I don't get any information back at all.

Something I have noticed in the IPsec dashboard that may or may not be significant, the remote gateway IP addresses are not updating.  All of these tunnels use dynamic DNS hostnames for their remote gateway.  In the dashboard, all of the non-functional tunnels are showing the initial IP I used creating the DNS entries with our DNS provider rather than the correct IP they should be receiving from dynamic DNS.  I've checked the DNS provider's portal, and it is showing the correct IPs, so dynamic is working correctly.  If I try to ping the FQDN from the FortiGate CLI, the ping goes to the correct IP address, so the FortiGate is receiving the correct data from the DNS provider.  It just doesn't seem to be updating the VPN tunnels.

FortiGate is a 300E running v7.4.7 build2731.

[rharms_tarc · Accepted solution]

I found the solution to my issue. It turned out to be that the VPN module wasn't querying DNS to get the correct IP for the dynamic DNS.

The solution was to change the remote gateway FQDN on the tunnel to a different domain for a moment and then change it back to the correct FQDN. That triggered a DNS query, and the tunnel would come right up. I put together a script to go through all of them and do the FQDN changes, and problem solved.

[ede_pfau]

Thanks for sharing your experience.

I wonder if clearing the FQDN cache and requerying it would have had the same effect:

   diag test app dnsproxy 6

to dump the FQDN cache,

   diag test app dnsproxy 4

to clear it,

   diag test app dnsproxy 5

to requery.