VPN disconnections

[Jesus_Cano]

We are having vpn disconnections in our platform. At the beginning of this issue, we had vpn disconnections every hour. VPN Phase 2 fell and the other end (CISCO) did not notice, not renegotiating phase 2.

We have changed the timers for both end-devices VPN to 8 hours and now the issue occurs every 8 hours. When the error happens, the messages are: "Unknown SPIs appear".

Why these errors are being showed? ANy idea about solve it?

Gaia R80.10

[Jerry]

double check | in detail | the whole Crypto Suite params and it's compatibility, some ASA's for example on an old IOS does not accept or even play with AES128 or higher. Sometimes you need to follow best practice from both vendors though.
I'd say that IKE "match" or rather mismatch is the cause most likely and based on my experience I can only tell you one thing then:
- analyze SPI messages
- see logs for details
- debug vpn on both platforms
- check the matching Proxy-ID's / IKE ID's
- check encryption domain params and the PFS if on both or not etc.

proper t-shooting and you'll be good to go 🙂

[Markus_Genser]

If you use IKEv2, check with the peer if they're using a set of different encryption parameter for the VPN tunnel.

I noticed that Check Point gateways have an issue with more than 3 different proposals and will drop the tunnel after phase 2 re-negotiation.

A solution would be to either remove the not needed parameter on the ASA or set the tunnel parameter on the Check Point to the first matching ASA set.

Markus

[Timothy_Hall]

Stop all interesting traffic on both sides, then clear the tunnels on both ends with vpn tu and clear crypto isakmp sa and clear crypto ipsec sa.

Now try initiating interesting traffic from the Check Point side only, do all needed tunnels come up and work?

Again stop all interesting traffic on both sides, then clear the tunnels on both ends with vpn tu and clear crypto isakmp sa and clear crypto ipsec sa.

Now try initiating interesting traffic from the Cisco side only, do all needed tunnels come up and work?  My guess is one or the other of these tests will fail which indicates a Phase 2 subnet/Proxy-ID negotiation mismatch.  You need to ensure that either end can successfully initiate all needed tunnels to the other end.