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

Excluding networks from vpn community using crypt.def

This may be an extremely basic question but I wanted to bounce it off of Checkmates in case I am missing something.

We're looking to re-route some traffic so that it is no longer encrypted by our Check Point firewalls, but need to avoid changing our encryption domains. I am wondering if it is possible to perform this by creating a policy based route and excluding the below networks from the crypt.def file. Below is an outline of what we're looking to change:

Firewall A has the 10.100.10.0/24 network in it's encryption domain.
Firewall B has the 10.200.10.0/24 network in it's encryption domain.
They are both in the same VPN community.

Both firewalls are the gateways for those respective networks.  We do have the possibility of changing that but wanted to explore this as a possibility first.

We are looking to re-route traffic between these two networks to use its own private link maintained by the routers. Will a policy based route as well as excluding those networks in the crypt.def file as laid out by sk86582 work?

0 Kudos
2 Replies
Highlighted
Silver

It will WORK

It won't be SUPPORTED

Unfortunately once you start doing PBR then VPN's are not supported.  Routed Or Domain.

However if you simply route the destination so normal route configuration then would be fine.

For other VPN Traffic ie if wanted to VPN to the remote gateway from a different source then as the Source/Destination NOT excluded from the VPN then the VPN would take precedence over the route.

Only traffic matching the crypt.def exclusion would be able to use the normal route as the crypt.def would prevent from going over the VPN.

So traffic from a different source or to a different destination would simply match the encryption domains and be sent over the VPN.

 

 

Highlighted
Gold

Hello Kevin,

if I understand your configuration correct, you have to lines between Firewall A and Firewall B and one of them does not need encryption.

There is a feature called "trusted links" which should be solve your problem and gives you high availability for the connection between A and B. You must define two links for the VPN-connection between A and B and define one line as "trusted".

VPN-traffic going over trusted interfaces is not encrypted.

Have look at How To Create a Redundant, Service-based MPLS/Encrypted Link VPN  (sk56384) for detailed steps of the configuration.

With this configuration you can use both links and prefer your private unencrypted line and if these goes down the encrypted will be used.

sk86582 will too help you to exclude this specific subnets from encryption.

Wolfgang