Reflexion will be End-of-life on March 31,2023. See Sophos Reflexion EoL FAQs to learn more.
I had a S2S VPN between a XGS2100 (18.5.3) and XG125 (19.0.1)
After upgrading both Sites for 19.5 GA the VPN connection crashes 2-3 times a week.The VPN is up and connected, but no traffic is routed from S2S, only a manual disconnect and reconnect will fix this.
Where do i start to fix a random S2S VPN error / routing error / etc... ?
Can i switch strongswan into debug mode for a week and wait for the next bug?
Or is there any way to find this inside the normal logs?
Can you disable IPsec acceleration on the console?
OK, i did disable IPsec (users will kill me) ...
Is there any log, that will show the culprit now?
Isn´t the XGS designed to use IPSec acceleration in Hardware and shouldn´t 19.5 using it now?
Hey JuergenB ,Please refer the Architecture for offloading this might provide a clarity in understanding.
Thanks & Regards,_______________________________________________________________
Vivek Jagad | Team Lead, Global Support & Services
Sophos Community | Product Documentation | Sophos Techvids | SMSIf a post solves your question please use the 'Verify Answer' button.
so 18.5 has not used IPsec acceleration and was solid...and 19.5 still needs some fixes ...
V19.5 can potentially cause problems with the engine. If you want to investigate this issue further, you can create a support case and DEV can take a look at your setup to find a matching bug id. If you want to apply the workaround by disable the fast path for ipsec, you can do it via console switch.
Hi JuergenB ,
Apologies to hear this unfortunate issue you bumped into, to echo what Lucar Toni mentioned above, if you want this to be further investigated kindly file a support ticket: https://secure2.sophos.com/en-us/support/open-a-support-case.aspx then please feel free to let us know of the would be generated caseID via DM or by replying to this thread, so we can track progress on our end.
Many thanks for your time and patience and thank you for choosing Sophos
Raphael AlganesCommunity Support Engineer | Sophos Technical SupportSophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS AlertsIf a post solves your question use the 'Verify Answer' link.
even with IPSec acceleration it crashed again. (S2S with 2 Sophos Devices)
In the log i see this message
2023-01-24 14:16:22 IPSec Failed HO-1 - IKE message retransmission timed out. (Remote: IP BO)
2023-01-24 14:16:12 IPSec Deny Received IKE message with invalid SPI (9F437ECA) from the remote gateway.
Any idea why this happens?
If this does not help, you have to raise a Support Case: https://support.sophos.com/support/s/article/KB-000038566?language=en_US
I see that the new 19.5 offers a newIPSec Profile 'Branch office (IKEv2) 'with invalid naming convention.
But with IKeV2 and the Rock Solid S2S Tunnel still has the old 'Branch office (IKEv1)' Profile.
Is this a new stable profile?
so you are saying, we changed your profile after the update? And the new profile is not working? Did you or the upgrade migrate the profile?
No, there is no change in the profile during the update process.
I only see new IKEv2 Profiles, i think they are new and maybe they are more stable in 19.5 than the old default profiles.I might swap the profile for my VPN Tunnel HO-BO and use IKEv2
We had default HO/BO profile for IKEv1 so far and only one IKEv2 profile.
The customer uses same (IKEv2) profile for HO and BO both locations, which leads to re-key collision in some cases and hence we have introduced a new default IKEv2 profile for HO and BO with similar fine tuning of re-key timer/DPD action etc.
If you are running IKEv1 based HO/BO profile its fine, recommendation is to switch to new IKEv2 HO/BO policy if you are currently using Default IKEv2 policy on both end.
Hope this helps.
I used default IKEv1 on both sides and it was stable until 19.5
So i will switch to IKEv2 and see.
Thanks for reply, there is no issue if you keep using IKEv1policy in v19.5.
We may need to get this investigated, if you have already opened support case let me know the case ID.
If you can open support access to both your devices and PM me the access IDs, I can get this investigated by our engineering team.