- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Hi, guys nice to be part of this community.
This is my first time with checkpoint and I'm facing bizarre behavior.
We have a Check Point Gaia R81.10 cloud version running on AWS; on the other hand, a Cluster XL 81.10.
Both of them have multiple (at least 5) IPsec VPN tunnels to different non-checkpoint gateways that are working without any problem. We use those tunnels to share BGP routes between the gw and CP-FWs
The issue starts when we try to create a VPN tunnel with the CP on AWS and the Cluster using the next config.
VPN COMMUNITY: TEST
Star Community
center: CP-AWS Satellite: CP-CLUSTER XL
VPN domain route-based,
allow traffic,
any encryption,
tunnel management per gateway no permanent
and then everything by default
As soon as we create the tunnel we saw in the Checkpoint smartview Monitor that the tunnel was created with the incorrect members.
Like: on TEST community CP-CLUSTER XL to NONCPGW(an interoperable device)
They are not (CP-AWS and the NONCPGW) in the same subnet or something similar, the only thing that they share is that both of the CP-FW have a tunnel and a session BGP to this NONCPGW.
Did you face this behavior before? maybe an SK related?
Thank you
You definitely want to consider calling TAC to verify your configuration. At first glance, this looks like you are running into the known collision between route-based VPN and domain-based VPN (VPN encryption domain groups). To work around this, you can define VPN domains-per-community for each gateway. Be sure you have an empty object group (yep, a group with zero objects in it). Edit the community, select the center and start gateways, then edit the VPN domain on each gateway to use the empty group object.
I'd also suggest unchecking "allow all encrypted traffic" in the community. This could lead to these sorts of unintended consequences, but you can try with/without it.
Typically, for route-based VPNs, you need to use VPN Directional match in the rules. You first need to enable directional match in Global Properties - VPN - Advanced. In a given VPN rule for those gateways, edit the VPN column, and choose "Directional match" option, and create three separate entries:
internal_clear -> <community name>
<community name> -> internal_clear
<community name> -> <community name>
You said you have BGP between VPN peers, so I presume you have VTIs configured and operational. You will want to review your route-maps to make sure you are dong AS PATH filtering, possibly pre-pending, to make sure you don't have one gateway end up being an inadvertent hub (unless you want that; but then you have to edit your VPN directional match rules to allow traffic to flow correctly).
Good luck!
I agree with @Duane_Toler , he brought up very good points. You also need to consider the following things...
-empty enc domain for the 3rd party
-VTI (virtual tunnel interface) config
-vpn config file from AWS side
Check out below post where I provided some info, hope it helps. If you need clarification, happy to help you. I get its CP to CP, but since AWS platform is involved, it may have to route based.
Andy
Not sure how the gateway would handle getting the same set of routes from multiple gateways with Route-Based VPN.
The only thing I can suggest outside of a TAC case is to filter the relevant routes from the other peer.
You definitely want to consider calling TAC to verify your configuration. At first glance, this looks like you are running into the known collision between route-based VPN and domain-based VPN (VPN encryption domain groups). To work around this, you can define VPN domains-per-community for each gateway. Be sure you have an empty object group (yep, a group with zero objects in it). Edit the community, select the center and start gateways, then edit the VPN domain on each gateway to use the empty group object.
I'd also suggest unchecking "allow all encrypted traffic" in the community. This could lead to these sorts of unintended consequences, but you can try with/without it.
Typically, for route-based VPNs, you need to use VPN Directional match in the rules. You first need to enable directional match in Global Properties - VPN - Advanced. In a given VPN rule for those gateways, edit the VPN column, and choose "Directional match" option, and create three separate entries:
internal_clear -> <community name>
<community name> -> internal_clear
<community name> -> <community name>
You said you have BGP between VPN peers, so I presume you have VTIs configured and operational. You will want to review your route-maps to make sure you are dong AS PATH filtering, possibly pre-pending, to make sure you don't have one gateway end up being an inadvertent hub (unless you want that; but then you have to edit your VPN directional match rules to allow traffic to flow correctly).
Good luck!
I agree with @Duane_Toler , he brought up very good points. You also need to consider the following things...
-empty enc domain for the 3rd party
-VTI (virtual tunnel interface) config
-vpn config file from AWS side
Check out below post where I provided some info, hope it helps. If you need clarification, happy to help you. I get its CP to CP, but since AWS platform is involved, it may have to route based.
Andy
Thank you guys, your clarifications are very useful!
Agreed with all your comments I will follow this with the TAC. I find a workaround, using ike2 only but is not a solution for me.
Thanks again
Glad the post helped you. As I said, if you need more clarification, let me know!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 7 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
Tue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY