- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Site to Site VPN - Check Point R80.10 to Cisco ASA...
- 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
Site to Site VPN - Check Point R80.10 to Cisco ASA - Troubleshooting
Moderators Note: the original poster removed the origins content of this post. However, the replies to this post may be useful if you're trying to troubleshoot a VPN between Check Point and Cisco.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some additional debugging steps here: VPN Site-to-Site with 3rd party
In general, if you can establish tunnels one way but not the other, this points to a difference in how each side is defining it's encryption domain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As a quick test, try setting VPN Tunnel Sharing to "pair of hosts" in the Community settings and reinstalling policy. If A can now initiate to B it is definitely a subnet/Proxy-ID/encryption domain issue in IKE Phase 2. However just because this setting makes it work DOES NOT mean you should just leave it set to that and call it good, as this setting can result in a very large number of Phase2/IPSec tunnels being formed. Set it back to "pair of subnets" then take a look at Scenario 1 in the SK Phoneboy posted.
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
Exclusively at CPX 2025 Las Vegas Tuesday Feb 25th @ 1:00pm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't count how many times, especially CP vs Cisco ASA this fixed the problem - changing from "tunnel per subnet" to "tunnel per hosts" . The drawback is it does create lots of tunnels this way loading the firewall.
And by the way I saw it happening just out of the blue - no config changes on either side, encryption domains match 1 to 1, still either one direction of VPN stops working, or even some specific hosts in the same network get dropped.
PS For advocates of "it is a hack!" , "quick fixes are bad", "you should debug the issue, recompile the firewall code, fix the bug" - (if you come from another planet) in the capitalism, who pays the money decides what is good for him/her, and when presented with either quick fix or fundamental/taking from hours to days debug the client still wants 'quick-fix' - you do what the client asks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Timothy.
Please look at sk108600 scenario 1. I think it will solve your problem . If you have additional 3rd party issues I will be glad to assist.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey.
Its interesting that checkpoint is doing nat.
can you please check what are the values that you have in this setting:
Advanced NAT-T Configuration
These variables are defined for each gateway and control NAT-T for site-to-site VPN:
Item | Description | Default Value |
---|---|---|
offer_nat_t_initator | Initiator sends NAT-T traffic | true |
offer_nat_t_responder_for_known_gw | Responder accepts NAT-T traffic from known gateways | true |
force_nat_t | Force NAT-T even if there is no NAT-T device | false |
The variables can be viewed or changed in GuiDBedit under:
TABLE > Network Objects > network_objects > <gateway_object> > VPN.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some things to considere:
- Check Point VPN-1 can supernet networks and this is not accepted by most other parties. (Documented in Secure Knowledge)
- Cisco ASA can accept things in phase 2 which are not right on initial contact but refuse them later on when it is time to rekey. (Thanks for Cisco TAC engineer for sharing that gold nugget of wisdom as it is not documented.)
While none of these may apply it is good to understand that every vendor has it's little features to make troubleshooting interesting.
