- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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?
Thanks!
RK
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, and nothing else. You cannot use the community in rules, as traffic will never match it.
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, and nothing else. You cannot use the community in rules, as traffic will never match it.
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.
Any thoughts on this?
Thanks!
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.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 20 | |
| 19 | |
| 18 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY