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!

[the_rock]

Im not Cisco expert by any means, but having worked on Cisco ASA for few years, Im somewhat familiar with those errors. Plus, it helps when your colleague is a guy who worked for Cisco TAC in India : - )

Anyway, those messages 100% indicate that problem is with phase 2. How is enc domain configured? Do you have PFS enabled? what DF group is used, if any? Is permanent tunnel enabled? Regular domain based or route based? 

Andy

[mfernandez1]

Thank you for replying, the encryption domain is configured as a network group that contains 3 network objects that are 3 different subnets x.x.100.0, x.x.101.0, x.x.102.0 with mask 255.255.255.0. PFS is enabled. DF group 14 (2048 bit). Permanent tunnel is enabled. The access rule is configured as source is our internal user IP subnet range and destination is the encryption domain group with subnets objects inside. They are in the same access rule as the old VPN, I am not sure if that matters. 

I have attached screenshots of the configuration.

Thanks

[AkosBakos]

Hi @mfernandez1 

Did you noticed that at the "Phases and timing" the units are different? (P1 minute, P2 second)? 

Sometimes works sometimes not can be key exchange issues, where the root cause is this (lot of times)

Supernet: https://support.checkpoint.com/results/sk/sk108600

The VPN-peer's config contains this tree /24 subnet? 

Akos

[mfernandez1]

Yes I noticed the difference, it is configured the same way as the old VPN that works fine. I will check out the article, thank you.

[Duane_Toler]

Why do you have the peer's link selection set to "calculate based on topology" ?  This could lead to IKE/phase1 errors when sending IKE ID.

Despite some popular opinions, FTD doesn't have the exact same VPN code as ASA; it's actually a lot better!  However, it doesn't mean the FTD admins didn't configure things "the ASA way".  They shouldn't include your gateway's interface IPs in their encryption domain group for your peer (hopefully they didn't).

If you still can't get it working, then change the Tunnel Management to one tunnel per pair of hosts.. It's wildly inefficient, but it will get the job done.

You also have DPD (Permanent Tunnels) enabled.  Make sure the remote side has their DPD enabled (for FTD is "ISAKMP keepalive"). 

FTD configuration with FMC site-to-site VPN configuration:

 https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/740/m...

[the_rock]

Thats great point actually, thats probably not accurate, I would leave it as main IP, as long as its corretc and simply put remote enc vpn domain.

@mfernandez1 Can you try that?

Andy

[mfernandez1]

We had it as "Always use this IP address" - Main Address, but we changed it to "calculate based on topology" to test it. I will ask them to send me screenshots of the configuration on their firewall and confirm keepalive is configured. 

[the_rock]

I assume neither one worked then?

Andy

[mfernandez1]

I think I will change it back to "Always use this IP address" because before it at least worked for a day, now it does not work at all, but in the old VPN that is working right now it is set as "calculate based on topology"

[Duane_Toler]

Yeah, "calculate based on topology" is really for Check Point hosts that respond to tunnel_test or (Check Point's) RDP probes.  3rd party peers should be Main Address for PSK.  If you're using certificate authentication, you might can get away with the DNS hostname option, but I've never had a need for that.

[Lesley]

Would be helpfull to see the config of the FTD. Otherwise we all have to guess what could be wrong. 

Just ask for screenshot and they can mark out whatever they want. In the end they did the migration on their part. 

[mfernandez1]

I just sent them an email to see if they can provide screenshots of the configuration and confirm that their encryption domain is set up the same way with the 3 subnets and mask, that they are not including our gateway's interface IPs in their encryption domain group, and that keepalive is configured. Thanks everyone!

[mfernandez1]

This is what they sent me, I dont think it shows everything

[the_rock]

Thats not helpful, sorry.

[mfernandez1]

I came across this menu called traditional mode and see that it does not have anything selected. I have not seen or used it before, could this be the issue?

[Lesley]

Nothing needs to be changed there leave that as it was. 

[Lesley]

Maybe time for vpn debug on our side? And review it in ike view.

the config screenshot does not show a lot. Would be interested in encryption methods and timers. It could be timer issue if you say tunnel works a day and then stops. 

[mfernandez1]

   These are the configurations from FTD side

[mfernandez1]

The last time that the VPN went down we unchecked this option "Disable NAT inside the VPN Community" in our Checkpoint firewall and it started working again but only for 1 day.

[mfernandez1]

Now we get the error "Auth exchange: Received notification from peer: Traffic selectors unacceptable MyTSi: <IPv4 Universal Range> MyTSr: <IPv4 Universal Range>"

[Duane_Toler]

If you don't want a route-based VPN (universal tunnels; "one tunnel per gateway pair"), then you should use the encryption domain-per-community option:

1. Create new object group for the specific networks of the remote peer (which you likely already have for that interoperable device)
2. Create new group object for YOUR specific networks you want to allow through this VPN.  This is not the same as your gateway's own default encryption domain.
3. In the list of center/satellite gateways for the community, edit each gateway and set the VPN domain to be these new groups respectively.
4. Check Tunnel Management and use "one tunnel per subnet pair".
5. Install policy
6. Enjoy (hopefully)

[mfernandez1]

Yes, we are doing policy based. We created the VPN the same way you described, we recently tried creating a new group object for our network to not use the default encryption domain as you mentioned, but that did not work either. The only different thing right now is that its set as One VPN tunnel per Gateway pair, but we have tried one tunnel per subnet pair too.

[Duane_Toler]

While the VPN is down, you can run a few commands to check things:

1. "vpn tu tlist":  Look for the name of the remote FTD's interoperable object and you can see the various IPsec sessions for the matching pairs of traffic selectors in the VPN domain.  You will also see if the session is connected or not.
2. Run a quick debug on the gateway to see some clues about the issue:

fw ctl zdebug -m fw drop |grep <ip of host in the remote vpn domain>

 (apologies to all for yet another 'zdebug')

Don't run this for long, and press Ctrl-C to stop it.    You should get some clue as to why the packets are dropped in the kernel.

If you are having issues after "a couple of hours", this is a timer issue on each side and most often a Phase2 configuration mismatch.  If you have issues "after 1 day", that's a Phase1 issue (peer identities, often with routing on one end or the other).

[Don_Paterson]

Kernel debug.

Might be a good idea to keep an eye on the cpview output on the CLI of the affected gateway before and during any kernel debug.

Grep only helps to filter output but not helpful for kernel debug performance impact.

Setting up filters before the debug might be better.

Kernel Debug Filters, example:

fw ctl set str simple_debug_filter_saddr_1 <Value X>

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityGateway_Guide/Conten...

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_PerformanceTuning_AdminGuide... 

fw ctl zdebug drop will work.

-m fw is not needed in this case because the fw Kernel Module is the default target to set the debug flag (drop).

Did anyone already suggest opening a Service Request with TAC?

They could offer good advice and/or the right troubleshooting and debug procedures, with the relevant warnings (performance impact etc.).

They might suggest procedures and cautions similar to https://support.checkpoint.com/results/sk/sk180488 

Running hcp -r all on the gateway is not a bad idea. Might just expose something interesting.

[CaseyB]

In the "Cisco config.png" you posted back in November there are three /24 networks listed. Are those the networks Cisco is expecting you to send them? If that is the case, you will want to do tunnel sharing mode of "subnet" and not "gateway". Gateway will send 0.0.0.0/0 which would be an invalid traffic selector on their side.

[mfernandez1]

Those 3 are the networks from Cisco side that we are connecting to. We have tried one VPN tunnel per Gateway and also per subnet, but both have stopped working after a couple of hours or a day. I believe that we have not tried one VPN tunnel per each pair of hosts so I might try that today.

[CaseyB]

Cisco should remove the Lifetime Size from the tunnel, unless you have modified that value on the Check Point side, setting it to 0 used to disable that I believe in Cisco.

My Google skills are failing, I cannot find the SK related to ike_p2_rekey_kbytes for IPsec tunnels.

[mfernandez1]

I will ask them to try that, dont really know what that is used for

[the_rock]

For what its worth, maybe make sure below guidbedit settings are se tto FALSE.

Andy

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets