IPSec VPN Dialup Issue FortiOS 7.0.12 <-> FortiOS 7.0.13 phase2-down

Hello,

Yesterday night I patched our central FortiGate unit (the HUB) to FortiOS 7.0.13. Few seconds/minutes after, I saw all my Dialup VPNs goes down.

phase2-down

The remote peers are still running FortiOS 7.0.12 (the spokes).

Sometimes I saw some few packets in the tunnel (SLA requests for instance). The VPN seems to connect for a brief moment and then drops almost immediately.

Does anynone know a compatibility issue between them? Or VPN changes in the last release?..

Update 1: I updated one remote site to the FortiOS version 7.0.13 with multiple starlinks and now all the Dialup VPN of this site are down… for me there is a bug somewhere…

Update 2: I found the root cause. Our VPN dynamic configurations were incorrect (multiple dynamic VPNs on the “server” side when one per link is sufficient). FortiOS 7.0.13 seems less tolerant of this, so I cleaned it up, and it’s working. And added “set add-route disable”.

I patched about 10 FortiGates over the past day, granted it was the spokes. No issues so far. Have about 65 more to go then doing my hubs. All IPsec minus 4 of them using dial-up.

I have run into the same issue. We have multiple dial up tunnels for various remote sites. Did simply adding “set add-route disable” resolve the issue or were you unable to have multiple dial up tunnels?

Adding in set add-route disable resolves the issue for us. I am running this through support anyways since it seems to be a bug. I got a great support agent, so if anyone runs into this and would like the ticket number let me know.

It seems that they don’t want to mention this on known issues, however: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dialup-IPSEC-issues-after-upgrading-7-2-6-7-0-13/ta-p/283504

I had to do steps 2 and 3 from this link.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dialup-IPSEC-issues-after-upgrading-7-2-6-7-0-13/ta-p/283504

phase 1
set add-route disable

phase 2
set route-overlap allow

There was no way I could delete any type of overlapping SA. I have a requirement that distant ends all get 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 SAs and we use policy ipsec to control which ipsec tunnel is used.

Question, was the VPN reboot / disconnect resistant before the upgrade?

Which versions are you running?

I applied this changed, it works (when using 0.0.0.0/0 as subnet). But, from hub point of view, it was impossible to have multiple VPN up for redundancy. Because of conflict between static routes and sdwan rules, route-based vs policy-based.

So, what I did was to review completely my design which was bad for this type of dynamic VPN. I implemented SD-WAN with BGP+ADVPN and ECMP, much better and now everything is working well as expected. And now I can mix dynamic routing with sdwan rules with multiples starlink links.

Let me know if you want my configuration.

Next step will be to implement/activate shortcuts paths between remote sites.

Hi there, we have the same issues and we solved it by inserting add-route disable. Can you please give me the ticket number so that i can report to the support team? Thnx

Good.

A bug? Maybe. I had the impression that there was a change with FortiOS 7.0.13 that made it less tolerant of this type of configuration. At least, I’ve cleaned things up now, and my new architecture is much better and more resilient than before. Keep us posted; I’m curious.

Good catch, indeed, dishonesty from Fortinet.

7.0.12 and moving to 7.0.13

Hi, please sent my your configuration, very thanks

The support guy said there was no mention of a change in the release notes, so if it was something that worked before (worked since 6.0 for us), it shouldn’t change in a minor release like this.

In the debug logs he observed the Fortigate matching the wrong IDs against tunnels, once you flick the set add-route disable it starts matching the ID properly. I’ll do a reply when I hear back from Fortinet on the debug logs.

0972977

In which release note is bug 0972977 mentioned?

I updated to 7.0.14 and the same thing happened.

I ended up getting told this is actually not a big, but a unannounced change. You need to flip the disable for add route in the VPN config.

If they told me the same thing, indicating it is associated with bug id 0872769 resolved in version 7.0.13.

But what is not clear to me is if the bug was solved because the workaround has to be applied.

It was solved because it wasn’t actually a bug. The work around is now what you need to do going forward.