- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Domain based IPSEC VPN with 0.0.0.0 or Route Based...
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Turn on suggestions Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Are you a member of CheckMates?
×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
RKinsp
Contributor
2021-05-1305:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jump to solution
Domain based IPSEC VPN with 0.0.0.0 or Route Based (on VSX R81) ?
Good morning everyone,
We are migrating from an existing solution that requires IPSEC to a third-party firewall with a "tunnel all" option where the remote end has two phase-2 selectors: 0.0.0.0 and a specific IP (ex. 172.31.0.1).
The local domain is 10.x.x.x. All traffic should be tunneled, including internet traffic.
Currently we are able to get the tunnels up but traffic does not match the access rule when the VPN Community is specified. If we remove the VPN community, traffic is matched but still not encrypted.
Tried switching from On tunnel per subnet to One tunnel per gateway pair. No change in behavior. We believe this might be because partial overlapping domains is not supported, according to sk106837.
Has anyone has successfully used 0.0.0.0 for encryption domain before without using Tunnel Interface?
If not, in case we go with tunnel interface (now supported for VSX), we should just route traffic to the remote tunnel IP and still use the community for rules?
https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_VSX_AdminGuide/Topics-VSXG/CLI/vsx...
Thanks!
RK
- All forum topics
- Previous Topic
- Next Topic
1 Solution
Accepted Solutions
Bob_Zimmerman
Authority
2021-05-1306:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jump to solution
You need to leave the peer's encryption domain set to the exact IP addresses behind that peer from your perspective. This controls the matching logic which causes the traffic to be flagged for encryption to the peer at all. To encrypt Internet traffic to the peer, you will need to build a group which contains all IP addresses except for the addresses behind your firewall, which would be complicated.
You then need to set the community to negotiate one tunnel per pair of gateways. This affects only the negotiation, and causes it to be 0.0.0.0/0 to 0.0.0.0/0.
A route-based VPN will be a much easier solution to set up (no need to make a complicated encryption domain; your default route just points out the VTI), and easier to manage long-term (a VTI acts just like an Ethernet interface with a ludicrously long cable). When using a route-based VPN, the community is used to specify the negotiation parameters for the tunnel, andnothing else. You cannot use the community in rules, as traffic will never match it.
View solution in original post
3 Replies
Bob_Zimmerman
Authority
2021-05-1306:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jump to solution
You need to leave the peer's encryption domain set to the exact IP addresses behind that peer from your perspective. This controls the matching logic which causes the traffic to be flagged for encryption to the peer at all. To encrypt Internet traffic to the peer, you will need to build a group which contains all IP addresses except for the addresses behind your firewall, which would be complicated.
You then need to set the community to negotiate one tunnel per pair of gateways. This affects only the negotiation, and causes it to be 0.0.0.0/0 to 0.0.0.0/0.
A route-based VPN will be a much easier solution to set up (no need to make a complicated encryption domain; your default route just points out the VTI), and easier to manage long-term (a VTI acts just like an Ethernet interface with a ludicrously long cable). When using a route-based VPN, the community is used to specify the negotiation parameters for the tunnel, andnothing else. You cannot use the community in rules, as traffic will never match it.
RKinsp
Contributor
2021-05-1307:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Bob_Zimmerman
Jump to solution
Thanks Bob. We will be testing out VTI with VSX then.
A couple of things we noticed, according to the links below we need to enable "Accept all encrypted traffic." and we can use directional VPN communities in the rules. These options seem contradictory.
https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/VPN-Tun...
Any thoughts on this?
Thanks!
Bob_Zimmerman
Authority
2021-05-1309:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to RKinsp
Jump to solution
Just write your rules like you would if the VPN were a long Ethernet cable plugged into the firewall. You don't put VPN communities in your rules for local traffic, so don't put one in the rules for traffic you want to go over the VPN. Routing will take care of whether something should be encrypted or not.
