- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Check Point Proactive support
Free trial available for 90 Days!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
The 2022 MITRE Engenuity ATT&CK®
Evaluations Results Are In!
Now Available: SmartAwareness Security Training
Training Built to Educate and Engage
MITRE ATT&CK
Inside Check Point products!
CheckFlix!
All Videos In One Space
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.
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.
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
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.
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.
Hey.
Its interesting that checkpoint is doing nat.
can you please check what are the values that you have in this setting:
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.
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY