XFRM Interface flapping after HA failover

hi Ben, 
            XFRM interface flaps only if the corresponding IPsec tunnel is flapping.  
Does log viewer (filter on VPN) indicate any VPN tunnel flaps during the issue time?. 
How many IPsec tunnels are active on the Node. 

Also in 19.5 GA there are some IPsec scaling fixes that could be relevant.

https://docs.sophos.com/releasenotes/index.html?productGroupID=nsg&productID=xg&versionID=19.5

Regards,

Vamshi

Hi Vamshi,

while the firewall runs on the 2nd node, I had multiple interface Down and Up events (Message ID 17813) in the system log but no IPSec Terminated (ID 17802) or Established (ID 17801) messages in the VPN log. So, the tunnel itself was stable.

OSPF had starts to work, when I has to switched to the first node. Some tunnels needed to stopped and restarted before OSPF saws the neighbors.

On the XGS5500 are 58 IPSec tunnels terminated.

Ben

My question was about switches "in front" which meant on he WAN side.

We had some scenarios where namely cisco switches caused some troubles after HA failover.

Yes, indeed we have Cisco Switches on the HA link and in front of the Firewall. On the HA ports we disabled strom-control and bpdu guard, which helped a little bit. The update to SFOS 19.5 solved the problem totally. 

So thank you guys for your hints.

Ben

Hi Ben, good to know the update to SFOS 19.5 solved the problem. 

Thanks for the access-id details. Some additional observations based on the Logs .   There are some IKE SA collisions as the IKE and ESP rekeying appears to be triggered simultaneously from the peer node. This is due to the Phase-1 and Phase-2 Lifetime values being configured the same on the peer(Initiator0 and Responder Nodes. 

XGS5500_CI02_SFOS 19.0.1 MR-1-Build365# grep collision /log/charon.log | wc -l

456

The IKE collisions also cause duplicate SAs and the number of SAs increases over time and other issues. 

A suggestion would be to clone or create a similar IPsec Policy/Profile (IKEv2_RSP), but with the increased phase-1 and phase-2 Key lifetime values say by 1/2 hour over the Peer(Initiator Node) IPsec Policy/Profile and use the new IPsec Policy in the IPsec connections.

https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122440/best-practice-for-site-to-site-policy-based-ipsec-vpn#mcetoc_1f5rpj2kd8

Regards,
Vamshi

Hi Ben, good to know the update to SFOS 19.5 solved the problem. 

Thanks for the access-id details. Some additional observations based on the Logs .   There are some IKE SA collisions as the IKE and ESP rekeying appears to be triggered simultaneously from the peer node. This is due to the Phase-1 and Phase-2 Lifetime values being configured the same on the peer(Initiator0 and Responder Nodes. 

XGS5500_CI02_SFOS 19.0.1 MR-1-Build365# grep collision /log/charon.log | wc -l

456

The IKE collisions also cause duplicate SAs and the number of SAs increases over time and other issues. 

A suggestion would be to clone or create a similar IPsec Policy/Profile (IKEv2_RSP), but with the increased phase-1 and phase-2 Key lifetime values say by 1/2 hour over the Peer(Initiator Node) IPsec Policy/Profile and use the new IPsec Policy in the IPsec connections.

https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122440/best-practice-for-site-to-site-policy-based-ipsec-vpn#mcetoc_1f5rpj2kd8

Regards,
Vamshi