IKEv2 permanent tunnel issue with Cisco ASA

[AaronCP]

Good evening,

I'm experiencing a strange issue with a site-to-site VPN that I've set up between our corporate cluster (15000 appliance - R80.40 T125) and a Cisco ASA (unfortunately I don't have any OS/version info of the peer gateway).

If I configure the tunnel as a permanent tunnel, phase 1 negotiates fine, however the phase 2 exchange fails with the following error: Auth exchange: Received notification from peer: Traffic selectors unacceptable MyTSi: <X.X.X.X> MyTSr: <Y.Y.Y.Y>. If I disable the permanent tunnel, phase 1 & 2 negotiates perfectly. The IPSEC renegotiation is every 8 hours. I left a continuous ping running to keep the tunnel up until renegotiation and it re-keyed perfectly.

Is there a known issue with permanent tunnels between Check Point and Cisco ASA's (or other 3rd parties)?

Some of the things I've tried:

Adding the peer & ranges into the user.def.FW1 file on the Mgmt Server

Changing the keepalive parameter in GuiDBedit to "dpd" instead of "tunnel_test"

Confirmed all IKE phase 1 & 2 parameters match on both sides, as well as our encryption domains/their crypomaps.

NB - I am unable to test/use IKEv1 as the 3rd party company's security policy prohibits the use of this protocol.

Any help/suggestions would be much appreciated.

Thanks,

Aaron.

[Timothy_Hall]

You are going to have to take a IKE debug (vpn debug ikeon) and funnel IKE negotiation debugs into the ikev2.xml file when permanent tunnels is enabled and things are broken, and again when they are disabled and it works.  Then compare the two traces using ikeview.  I don't see how permanent tunnels would impact the traffic selectors like you are describing, but it is possible that feature could be modifying something other than just the proposed subnets such as protocol, source port, and destination port which are normally specified as zero in the selectors to permit everything.

This also sounds a bit like a narrowing issue, see here: sk166417: IKEv2 Site to Site VPN instability when tunnel is narrowed

[AaronCP · Accepted solution]

Hi @Timothy_Hall,

Thanks for the suggestions.

I've done as suggested with regards to the IKE debugs, but the issue persists. I generated some traffic whilst the tunnel was not set to permanent, and I can see the traffic selectors are using the internal IPs defined in the encryption domain. Once I set the tunnels to permanent, the ping failed and the traffic selectors in phase 2 changed to the public IP of both gateways. The "traffic selectors unacceptable" message appeared in the debugs, too.

Once I'd disable the permanent tunnel feature and reset the tunnel, the ping worked and the correct traffic selectors were displayed.

I took a quick look at the SK, but I couldn't see and "Eclipsed" or "Narrowed" message in the vpn tu tlist output for this gateway.

[the_rock]

Im happy to do remote session with you and check this (if you are up for it, message me privately). I have experience setting this up with other vendors...is it permanent tunnel? If so, then you may need to configure VTIs on CP side to get this working.

[AaronCP]

Hey @the_rock,

I will need to check my company policy on a remote session and get back to you - but thanks for the kind offer!

It is supposed to be a permanent tunnel, but this is where we encounter the error. Disable permanent tunnel and it presents the correct traffic selectors and the traffic works fine. Enable permanent tunnels and the public IP of both gateways are presented as the traffic selectors (these are not specified in the encryption domains, btw) and phase 2 fails and traffic does not pass through the tunnel.

I did set up a VTI between both gateways, but this did not help. I also added a static route for the traffic to the VTI and that didn't help, either.

[the_rock]

Ok, so here is the catch. When you set up VTIs, make sure that section in the interface setup in GUI for remote gateway matches EXACTLY what you gave the name of interoperable object in dashboard, otherwise it will never work. Also, make sure that remote address is what it on the other side. As well, ensure that routes you configure reflect remote address IP from VTI...so say if remote address is 169.254.0.55, and you are trying to access network 10.10.50.0, then route on check point should say destination 10.10.50.0 with default gateway of 169.254.0.55. Also confirm when you do create VTIs that when you go to dashboard CP object, you can get interfaces WITHOUT topology on the object ( do NOT get them with topology, as that can mess everything up).

Also, SUPER IMPORTANT...if you are doing permanent tunnel, make sure vpn domains are empty groups on both sides.

You can also refer to below for guidance:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...