topic Correct way to use VPN communities in Access policy in Firewall and Security Management

Correct way to use VPN communities in Access policy

gryzz — Thu, 27 Oct 2022 05:53:19 GMT

Hello to everyone,

I am trying to understand the logic behind access rules and VPN communities.

I have an example ruleset what regulates traffic between internet / ipsec tunnel / Local VLAN-s

Name	Source	Destination	VPN	Services	Action
users_to_inet	user_address	Internet*	Any *	Any *	Accept
users_to_ipsec	user_address	ipsec_address	ipsec_com	Any *	Accept
users_to_local	user_address ssl_vpn_address	local_services	Any*	Any*	Accept
Cleanup	any*	any*	any*	any*	Drop

I am experiencing an behaviour when traffic destinated to the IPSEC tunnel is going through the "users_to_inet" rule but not through "users_to_ipsec" rule. It seems that the first match is because of the VPN=>Any* but I have no knowledge yet to disable it if it is even possible.

I am experiencing an behaviour when traffic hits "users_to_local" rule the checkpoint tries to create a IPsec tunnel to the remote host , because that the rule has ssl_vpn_address" in the source. Even though the traffic is destinated to a neighbour VLAN and no tunnel should be used.

When moving the priority of the rules, then traffic in some cases are matched the correct rule but some other rules tend to try move through the higher priority ones.

I have read the administration manual, but I find the answers I was looking for.

Can someone please explain to me:

What is the correct way to describe LAN => Internet rule that the VPN communities don't try to go through it.?
What is the correct way to describe VLAN => VLAN rules that the VPN communities don't try to go through it.?
How to disable the use of VPN Communities when creating VLAN => VLAN rules in the firewall.?
What is the correct way to prioritize rules when you have on-prem VLANS and remote IPSEC tunnels where you try to allow and forward traffic.
What is the logic behind the explanation and behaviour of the Checkpoint SGW?

I hope this explanation is enough but feel free to ask me for additional questions if it is too hard to understand. I was working with a fortigate unit for some time and there the logic was a bit different.

Best Regards,

Gryzz

Re: Correct way to use VPN communities in Access policy

PhoneBoy — Thu, 27 Oct 2022 19:45:12 GMT

The VPN column is meant as an additional matching criteria in the rulebase.
It is possible to put a specific VPN Community there, but it is NOT possible to create a rule that only applies to non-VPN traffic.
That means any rule that applies exclusively to VPN traffic should be before rules that could apply to either VPN or non-VPN traffic.

While there are probably some exceptions, generally your rules should be ordered "more specific" to "least specific."
Which means your "users_to_inet" should be listed right before your Cleanup rule in the example rulebase.

Re: Correct way to use VPN communities in Access policy

gryzz — Fri, 28 Oct 2022 07:42:26 GMT

Hello

Thank you. I had a hunch that "VPN=Any" Will also apply to all the defined communities.

But for example when I'll move the "users_to_inet" rule before the cleanup rule and all the "specific" VPN rules have the higher priority. Will the users_to_inet rule will be still hit when higher priority rules won't match, making it the fallback rule.

By that I mean that the higher priority rules should have ip1:1ip and port1:port1: principle on both GW1 and RGW1.

So that it means that I cannot allow in the whole network range inbound on the remote VPN GW because when all the specific conditions don't match then the fallback "users_to_inet" rule would be still matched for inbound traffic in the remote gateway when it's not configured 1:1.

Am I correct?

It might be confusedly explained but I hope that you get my idea.

Re: Correct way to use VPN communities in Access policy

PhoneBoy — Fri, 28 Oct 2022 17:41:24 GMT

To understand how the rulebase works, please refer to the following: https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/m-p/9888#M1693
In general, the rule nearest to the top of the rulebase will apply if multiple rules match (e.g. if rules 2, 4, and 33 potentially match a given connection, rule 2 is applied).