For those who asked, our VPN setup is the result of the intervention of 2 seniors engineers at Sophos, Boston. I normally need no help to setup a IKEv2 VPN. I was doing it with no sweat on any firewall more than a decade ago.
Hello Heiko
I contacted support. They are asking me to run with an IKEv2 setp with DH 31 and 18 removed and with SHA1 activated.
I am no encryption expert, but weakness in SHA1 have been demonstrated more than a decade ago, and Microsoft themselves have been refusing SHA1 certificates for almost two years now. Same with anyone else in the industry. CERT-US have urged anyone to stop using it for years.
Even my dog knows SHA1 is dead !!!
What is going here ? Why are they asking something that outdated and unsecured ?
Paul Jr
Ok ... Sophos support asked me to test this IKEv2 policy.
Exact same behaviour. VPN falls every 4 minutes ... Besides, this policy is absolutely not recommended. SHA1 is dead and buried. Key life is now 15 hours (54000 secondes), DH groups has 31, and 18 disabled. Which in the end means quite an insecure and outdated policy.
But the thing is: reducing encryption load do not change the VPN falling every 4 minutes. The theory that XG and its own routing is guilty is even more probable.
I am now living with VPNs that falls every so often for more than a year now.
Paul Jr
We are going throug lots of problems with VPN Ipsec in the last days, especificaly in the last month.
working with Firmware (SFOS 17.0.8 MR-8)
Every day the tunnel is going down and not connects again, at least whe rebooting both sides. already created a new policy like in the picture, but today same problem, in this case we have no time to tests.
I thought I had posted this somewhere but realized I did not. My IKEV2 tunnels have been very, very stable. I had some issues with one router but it looks like that may be resolved as well. I just checked my logs and I have not had a single site out of 24 drop in the past 7 days. Prior to reconfiguring my tunnels like I am going to show you, they were dropping multiple times every day. This configuration was a lot of work but it appears to have fixed my issue. I worked with support for several hours on this and they were outstanding. I asked if this was documented anywhere and was told that they were in the process of doing this.
You have to create two IPSEC policies. One for initiators, and one for responders. You cannot have two sides set as an initiator or they will continually fight each other to build the tunnel. Sophos' recommendation was to set the smaller site to initiator and the larger (headquarter) site as responder. This is backwards to my thinking but their reasoning is that initiation takes more resources than responders so make the smaller site take that workload.
Here is my IPSEC Policy for Initiators (larger sites) Note only DH Group 14 & 16 are selected for Phase I.
Here are my responder settings:
On the IPsec Connection for initiators, you have to set the gateway type to Initiate the Connection and policy to the initiate policy you previously created.
On the IPsec Connection for responders, you have to set the gateway type to Respond only and policy to the Respond policy you previously created.
Hopefully this resolves your issues like it did mine. We had to modify 24 different routers each with 24 tunnels for a total of 576 connections and knock on wood, so far it has been working very well and was worth the effort. I have restarted multiple routers and have only had a couple of tunnels that didn't come back up. The vast majority came right back up after a minute or two.
