- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- CloudMates General
- :
- Issue with new VPN with new Cisco FTD firewall
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Issue with new VPN with new Cisco FTD firewall
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume neither one worked then?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!