Issue with new VPN with new Cisco FTD firewall

[mfernandez1]

Hello, we are trying to migrate a VPN with one of our vendors because they bought a new firewall (Cisco FTD), they used to have Cisco ASA. The previous VPN with the previous firewall is working fine, but we are running into the following errors when we test the new VPN with their new firewall.


Child SA exchange: Received notification from peer: No proposal chosen MyMethods Phase2: AES-256 + HMAC-SHA2-256, No IPComp, No ESN, Group 14

Auth exchange: Received notification from peer: Traffic selectors unacceptable MyTSi: <our fw's public IP> MyTSr: <their fw's public IP>

Sometimes the VPN is working fine for a day, but the next day it's not and we have to reverse back to the old VPN. The vendor is saying that the VPN configuration in the new firewall is the same as the VPN configuration from their old firewall. 

From their side they get the following error:

Local:TheirFWIP:500 Remote:OurFWIP:500 Username:OurFWIP IKEv2 Tunnel rejected:
Crypto Map Policy not found for remote traffic selector OurFWIP/OurFWIP/0/65535/0 local traffic selector TheirFWIP/TheirFWIP/0/65535/0!

Any help would be greatly appreciated. Thank you!

[CaseyB]

It is just another variable that determines when Phase 2 will re-key. Every tunnel I've ever worked on re-keys on a time interval, so generally every hour for Phase 2, Cisco adds another option that says re-key this tunnel after X amount of traffic has passed, so now your tunnel could either re-key after an hour or X amount of traffic, this doesn't work well when only 1 firewall knows to re-key after X amount of traffic.

[spottex]

For the No proposal 
The only thing that I did not see provided was PFS DH Group 14 on the FTD - but someone has already ask you to confirm.

For the Auth Exchange Traffic selectors - the public IP being used instead of the networks will be the permanent tunnel traffic -turn it off to get rid of that error.

Try testing with IkeV1 - as strange issues can happen with compatibility with IkeV2

Working sometimes, means one side initiating the VPN will complete the negotiation enough to get traffic through. On a future rekey the other has probably initiated and you get the failure (have proved this happens more that once)

We have one VPN that would never connect one way. We had to change the rekey times so the working peer would rekey 2 minutes before the other.

[spottex]

FYI:
Permanent Tunnels can only be established between Check Point Security Gateways.
Ref: https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SitetoSiteVPN_AdminGuide/Topics-VP...

[the_rock]

I know thats what it says, but we had done many permanent tunnels with AWS and Azure, no issues. Im sure lots of other customers do the same.

Andy

[spottex]

If that is the case the FTD would need configuring then to recieve the the public IP's as the Traffic selectors and respond.
I think for Cisco traffic selectors configuration means the public IP's would need to be in the access rule, if I'm not correct??
...or the correct configuration for FTD for perm tunels if I'm inocrrect on that idea to fix it.
But aside from that, it is not needed for the traffic to bring up the tunnel.
Unless - Since the Check Point is not getting a response for the permananet tunnel it is resetting Security Associations. Which means it will drop return traffic which now has deleted Security Associations in the VPN header . Turning off Perm Tunnels would be good to start with. They can configure and turn it back on later.


Update:
From the R81 admin manual
The Check Point can delete SA's in certain circumstance.

Permanent Tunnels: Tunnel Testing
Check Point uses a proprietary protocol to test if VPN tunnels are active, and supports any site-to-site VPN configuration. Tunnel testing requires two Security Gateways, and uses UDP port 18234

Permanent Tunnels: Dead Peer Detection
Dead Peer Detection does support 3rd party Security Gateways and supports permanent tunnels with interoperable devices based on IKEv1/IKEv2 DPD responder mode and Permanent tunnel mode based on DPD

Note - The DPD mechanism is based on IKE SA keys. In some situations, the Check Point Security Gateway deletes IKE SAs, and a VPN peer, usually a 3rd Party gateway, sends DPD requests and does not receive a response. As a result, the VPN peer concludes that the Check Point Security Gateway is down. The VPN peer can then delete the IKE and IPsec keys, which causes encrypted traffic from the Check Point Security Gateway to be dropped by the remote peer.

[the_rock]

See if this link I made last year helps. I know its Azure, but logic is more less the same. Here is all I can say...not sure if this is case with your config, but, if its mix of hosts/subnets, make sure tunnel management is set per gateway.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-tunnel-to-Azure/m-p/206179/emc...

[spottex]

For FTD config:
Google AI response: Take with a grain of salt and do own research:

To configure a Cisco FTD IPsec VPN to create a single tunnel per gateway, rather than per subnet, you need to specify the "gateway IP address" as the protected network on each VPN endpoint, ensuring that each distinct gateway receives its own dedicated tunnel, regardless of the subnets behind it; this is achieved by using a /32 CIDR block for the protected network when defining the VPN tunnel on the FTD device

[the_rock]

I was actually referring to tunnel management on CP side. What I meant was if you use mix of subnets AND hosts on Check Point side, then that option should be selected.

Attached the screenshot.

Andy

[spottex]

Yeah I know:-)
I was trying to be helpful that the otherside needs to be configured to handle it too.

Personally I'd turn it off. If you don't understand it, it will cause you headaches.

[the_rock]

Understood 🙂

I used to work with guy who worked for Cisco TAC in India and he explaied it to me really well once, but I totallly forgot : - (

Will check my notes tomorrow to see if I can find it.

Andy