Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
RKinsp
Contributor

Domain based IPSEC VPN with 0.0.0.0 or Route Based (on VSX R81) ?

Jump to solution

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

 

0 Kudos
1 Solution

Accepted Solutions
Bob_Zimmerman
Advisor

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.

View solution in original post

3 Replies
Bob_Zimmerman
Advisor

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.

View solution in original post

RKinsp
Contributor

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!

0 Kudos
Bob_Zimmerman
Advisor

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.