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

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? 

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. 

 Rog163 

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.