Assume I have a working site to site IPsec VPN between sites A and B (both Fortigate firewalls). Policies are in place, and traffic was passing successfully.
Then site A changes ISP, so gets a new public IP.
If I change the Remote Gateway IP of the vpn on site B to the new public IP of site A, would you expect the VPN to just come up (after initiating some ‘interesting traffic’ that should pass over the VPN) ?
I have access to the Fortigate at site B, and have changed the VPN remote gateway IP address to the new public IP of site A, and attempting to ping A resources from site B (to create the interesting traffic), but VPN is not coming up.
Where it’s failing ? Is tunnel coming up but no traffic ? If tunnel is not coming up what phase is it failing ?
Can anyone recommend any CLI commands I could run to try and diagnose further?
Many thanks for any help.
I have two run-ins with this in which changes to the tunnels settings related to peering (chnage of public IP, chnage of interface) resulted in an issue in which the tunnel wont establish despite all settings being correct
notice in the traffic logs that traffic destined to the vpn interface gets routed to the wan interface, (despite having a static route to the vpn interface). debugging also shows that indeed traffic is directed to the wrong interface despite having the correct route
In both cases, opened TAC
In both cases, deleting and recreating the tunnel was the fix. TAC was the one recommending we recreate it even.
in both cases no RCA but TAC does agree it a buggy behavior
Encountered on firmware 7.0.10 and 7.0.13
You have to change the remote and local gateway respectively for each site with the new public IP
I had some trouble with this recently, and it’s almost like the fortigate in question never quite updated something in it’s outbound attempts when switching to the new line.
Because you can’t shut down phase1/bring down the whole tunnel when phase 2 isn’t up, I ended up changing the interface in the VPN connection settings to just any random one that wasn’t connected. Then changed it back to WAN and the tunnel came up straight away.
Thanks for all input.
It turns out, after excruciating questioning, that the new office does not in fact have a direct ISP connection - rather they are piggy backing off the building ISP which is NATting their traffic before it gets to them.
Hence Internet traffic works, yet ipsec VPNs are screwed.
Moral of the story is to not believe what you are initially told, and to ask more questions.
They’ll be getting their own direct fiber in a couple of weeks, and I assume things should work as I expect.
You could try enabling nat traversal as part of your config at the site where the change was made. I’ve seen this resolve issues with tunnels both passing traffic and even establishing in general.
In System Events->VPN (on site B), I can see Phase 1 successfully negotiating (which is what I would expect), but I can’t see any Phase 2 events (success or fail) which I find odd.
I don’t currently have visibility of the site A Fortigate, but as it was apparently working (before I joined, and when it was on previous ISP), I’m assuming the correct Phase 2 selectors are in place at site A (they are present on Site B).
I should be able to get someone provide me a remote session to site A Fortigate tomorrow, but have limited time so am trying to understand as much as possible before then).
Yes, we have a new public IP at the site with new ISP, and users at that site can access Internet already successfully.
On my side, if I select the VPN in question and click the ‘Show Matching Logs’ link, I can see logs every 30 seconds, with message “progress IPsec phase 1”, Action “negotiate”, and Status “success”.
However I’m pinging from my side to a resource on other side (that matches one of the Phase2 Selectors), and not seeing any reference to Phase2 logs at all.
This and possibly proxy address depending on the tunnel configuration.
Edit: check to make sure the tunnel is on the same WAN link. Not sure if they lifted cable and used same port or setup second interface.
Is rebooting a possibility ?
Probably at site A (when I have someone on site there tomorrow), but definitely not at site B (which is what I currently have access to).