Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Sophos site to site VPN changes take long to apply, changes dont apply

Hi All - ive had this issue for over 2-3 years now - when trying to make changes on site to site vpns - either the changes take long to apply, dont apply or need to apply several times.

i try to change local ID for example on an existing site to site vpn - after making the change and clicking save - it takes 1-2 minutes then tells me changes not applied either my connection dropped or connection issue, i click site to site vpn again and go to the vpn tat i changed, and no changes applied - will need to do this 3-4 times. I also find just clicking on status form green to red will still show green then 10 minutes later, the VPN is down and disabled.

anyone else had this? 



Edited TAGs
[edited by: Erick Jan at 5:18 AM (GMT -7) on 1 Oct 2024]
Parents
  • so got the following reply from support : 

    . It appears that your device currently has over 3200 Security Associations (SAs), and we've identified multiple duplicate request IDs/SAs. This suggests a potential misconfiguration with the local/remote actions of "initiator/responder."

    Can some shed some light on how to address this? What would cause so many SAs being created? i have around 75 Site to Site VPNS, no VPN has more than 1 to 1 subnet remote and locally - 

    Support didn't give me much details to this - is there a specific VPN that's causing this? which one? Is this due to rekeying settings? I have disabled rekeying on the sophos (Responder) and the rekeying is done by the initiator - (95% of the initiator Devices are Draytek Routers) 

  • Essentially an SA could be a pair of Remote and Local Subnet. 

    Go to the Console and try: ipsec status 
    It should show all SAs (combinations). 

    If you see one messing up and creating a lot of SAs, you should see the name of the tunnel. 

    By the way: Which version are you running? 

    __________________________________________________________________________________________________________________

  • Thanks for the reply- firewall running latest version 20

    with regards to IPsec status- when I run the command there must be thousands of entries- is there a way to stop it or pause it etc. 

  •   

    Had a look at your SFOS where you said save on a tunnel takes long time; tried with couple of tunnels which are in deactivated state (this should not be impacting your setup), did not notice the issue; has anyone cleared the config issue(s) that helped resolve the issue?

    Also, noticed that some tunnels has huge set of duplicate child SAs for the same pair of traffic selectors, this is another issue. On ipsec policy - DRAYTEK_POLICY

    XG135_XN03_SFOS 20.0.2 MR-2-Build378# ipsec statusall | grep  | wc -l
    15

    After about 40 minutes, noticed this count is increasing..

    XG135_XN03_SFOS 20.0.2 MR-2-Build378# ipsec statusall | grep  | wc -l
    88

    XG135_XN03_SFOS 20.0.2 MR-2-Build378# ipsec statusall | grep  | wc -l
    91

    // what it means is system has 91 child SAs, but uses only the latest rekeyed child SA to carry the traffic and rest all Child SAs are not needed, should have been deleted.

    I am assuming, the other end of IPsec gateway is DRAYTEK that is set to Initiator; I see DRAYTEK_POLICY on SFOS is set to responder with rekey disabled; DRAYTEK ipsec gateway being the tunnel initiator and does rekey of tunnel (Child SA), once rekey of Child SA is successful, it is supposed to send DELETE on the old tunnel and this is not happening causing piling up of Child SAs on SFOS. 

    Can you check with DRAYTEK or check the logs on DRAYTEK after the rekey of a given Child SA if the DELETE of old Child SA is happening or not? 

    One such sample given below  where Child SAs are piling up on SFOS (I have removed exact ip addresses being used):

    Also, can you proved the name of the IPsec tunnel that you are seeing huge time to save the config? we will repeat the same and check logs on SFOS side.

    Another point: keep your Phase1 and Phase2 rekey values of Initiator side (whichever is the gateway- Draytek or SFOS or Fortigate) less than Phase1 and Phase2 values used on Responder side; and on both Initiator and Responder nodes Phase2 should be much smaller than Phase1.

  • Hi - i appriciate all the help but Please can you not post Customer/Private information on a community site?? 

  • and also noticed that there are 73 s2s pbvpn ipsec tunnels configured, few of them are not UP (either in deactivated or not connected state) but 'ipsec statusall | grep up' shows 

    Security Associations (244 up, 0 connecting):

    It means, there are plenty of ipsec tunnels duplicated (meaning, with same tunnel name multiple IKEv2 SAs are seen) and remain present; same logic mentioned earlier for Child SAs applicable here as well for IPsec tunnels. This also need to be correlated from Draytek logs on why rekeyed IPsec tunnels are not deleted.

  • Sophos support want to enable rekeying from the Sophos side - So having multiple people looking at this with different suggestions doesn't work for me and confusing things. I think its best I work with them on this for now rather than having multiple solutions thrown at me - Thanks for your help and time - I will update the forum once resolved or if need further help.

Reply Children
No Data