IPSEC Phase 2 Rekey Tunnel Goes Down and Won't Come Back Up

[sx8n20394]

I have been having an extremely hard time setting up a new  site-to-site VPN between our 1535 Quantum Spark appliance and a Cisco ASA appliance.

Details:

The client will only accept WAN IP addresses when setting up the encryption domains on both sides. We originally had an encryption domain issue that was resolved on a call with the client tech support. We don't have any other WAN IP addresses other than our main WAN connection so I told them to use that address. After they reset the tunnel on their end, the tunnel came up and we thought we were good to go. After an hour, I got the following notification:

Informational exchange: Received delete IPsec SA request for: 0x0c3ed3e0.

After this alert, the tunnel went down and would not come back up. I cleared all IKE+IPSEC SAs via CLI and the tunnel refused to come up and I now get the same error I received before we fixed the encryption domains.

Initial exchange: Exchange failed: timeout reached & Auth exchange: Received notification from peer: Traffic selectors unacceptable

Also this:  Informational exchange: Sending notification to peer: Invalid IKE SPI IKE SPIs

Why was the tunnel able to come up and work fine then not be able to rekey on Phase 2 after the 3600 seconds?

Unfortunately, Checkpoint support hasn't been very helpful and I honestly don't expect them to be since this may be the result of us trying to connect to a 3rd party gateway.

Does anyone have any helpful tips?

[AkosBakos]

Hi @sx8n20394 

I suppose that, there are mismatch between the two authentication config. Especially I suppose that the phase2 renegotiate timer mismatch.

Here is a screenshot of a config from a SmartConsole. Yes I know tat, you have locally management Spark appliance, but there are the same settings avaialble

Double check the timers (and the unit of the mesure). As you can see on the screenshot, there are seconds, and minutes are in use on a same pane.

Akos

[sx8n20394]

Everything matches for each phase.

[CaseyB]

You guys have a mismatch of encryption domains, it is telling you that with the error:

• Initial exchange: Exchange failed: timeout reached & Auth exchange: Received notification from peer: Traffic selectors unacceptable
  • Cisco is rejecting your offer because it doesn't match what they have defined for you.

Sometimes you might see this a lot:

• Cisco -> CheckPoint (Phase 2 accepted)
• Cisco -> CheckPoint (Phase 2 accepted)
• Cisco -> CheckPoint (Phase 2 accepted)
• CheckPoint -> Cisco (Rejected)

So, depending on who is always doing the traffic initiation, you might get the false impression that the tunnel is working properly when it is not. I find that due to the way Check Point handles encryption domains by default, it is pretty promiscuous when building tunnel traffic as opposed to other third-parties.

[sx8n20394]

Well the tunnel was up and we were able to send traffic which is why we thought it was all set. It became a problem after the Phase 2 rekey which brought the tunnel down. I honestly don't know what to do because we only have 1 WAN IP and that is what the client has on their side. All of the domains they sent over are correct, I just don't know about my own encryption domain because I never setup S2S with WAN IPs in the encryption domain.

[CaseyB]

Can you provide some more information on this VPN?

Is the Cisco side hosting a service you are accessing? I assume they are not accessing resources on your end? I am asking since you are only proving the 1 IP address on your end.

So with these assumptions:

• NAT should be enabled for this tunnel.
• Some sort of HIDE NAT needs to be in place for your side. I am not quite sure how a locally managed 1500 handles this, but you might need to create a NAT rule for that. Here is an example:

• Manually configure a local encryption domain - I would do this for this specific tunnel. 
• In that group you want your local networks that you are hiding plus the public IP:
  • Example: 10.10.10.0/24, 192.168.0.0/23, and 3.3.3.4/32
• Tunnel sharing mode should be host to host.

That setup should initial traffic using the public IP address. I am a bit out of my wheelhouse for locally managed 1500 stuff, but the concepts are the same, I hope this helps.

[sx8n20394]

No, they will be accessing resources on our end. I was just planning on tackling that after we get the  tunnel up. Will this NAT rule help establish the tunnel or is this just something to consider after the fact?

[sx8n20394]

If you have any tips on any other way I should set this up that would be great. They have other available WAN IPs I just don't know how to utilize them in this case. The original setup was 3 different WAN IPs in our remote encryption domain on the client side but I didn't have access to the original firewall configuration so I kind of just removed those from the equation. 

[CaseyB]

Ah, alright, well them needing to access your resources changes things. NAT will need to be used in general because of the public IP requirement. You will need to provide STATIC NATs (1-to-1) for resources they need to access on your end. Hide NAT would be if you want like 50 different computers on your side to access 1 web server on their end.

Your NAT rules would look something like this:

You can get creative with how these are defined; this is just a simple example since I don't know the specifics of your VPN.

[sx8n20394]

Lets say my WAN IP is 99.99.99.1 and I have two spare WAN IPs 99.99.99.2 and 99.99.99.3. How would I add those to my local encryption domain? Should I let checkpoint handle that automatically or define it in the manually defined encryption domains? My problem is that what if I need another tunnel where those IPs aren't needed in the encryption domain such as a site-to-site with a branch office that uses local ips in the encryption domain. Thanks for the help.

[CaseyB]

For this tunnel, you would want to define the local encryption domain manually. As long as those objects are only assigned to this Cisco VPN site, it should not have any effect on other tunnels using the automatic method.

[sx8n20394]

Unfortunately on Locally Managed you don't have an option to select. It is either Global Manual or Automatic.. Also, our tunnel came up after figuring out checking off Permanent Tunnels was the issue. I don't like that I need to send a continuous ping to keep the tunnel up but it is better than what I was dealing with before.