Traffic behavior over an IPsec VPN.

[Matlu]

Hello, everybody.

I have a curiosity, which I would like to clarify.
I have a S2S VPN against a third party, so far, everything is working "fine".
VPN is up, and the traffic flows from my side, to the remote end (It is a decision of the bosses, only one way).

My curiosity is about what I "see" in the logs, because, although it is true, the VPN works, and I see "ENCRYPTED" traffic from my side, for example, when I do a PING from my side, to the remote end, not only I get "logs" related to the VPN, but also, logs related to the "APLICATION CONTROL" blade, with an "Accept" action, and my curiosity, is "IF THIS IS NORMAL ????".

Not only is it supposed to show only traffic related to the VPN blade, and with the action, in my case, of "Encrypt"????

Why does the same traffic that we tested call another blade?

Thanks for any comments you can provide.

Cheers. 🙂

[SSlater]

Strict Mode Policy Requirements.  We require that it's explicitly allowed in your policy. --- Encrypt, as well as Accept.

Please reference the discussion here, they hash it out in detail, with a few examples:

https://community.checkpoint.com/t5/SMB-Gateways-Spark/Application-Control-Bug/td-p/33513

[Matlu]

Hello,

How can I validate, if I am working with the "strict policy mode"????

If I decide to change the "working" mode, can there be impact of everything in general?

Cheers.

[SSlater]

The long answer is in the other community post. -- The short answer is everything is running by design, you have the application control blade's functionality, and you don't need to change anything if it's allowing the traffic as expected.

Application control can be leveraged in the future if needed, but for now your policy is allowing the traffic as required. -- This is Normal.

[Matlu]

So, it is an "expected behavior", the fact that my traffic passing through the VPN tunnel, also "relates" to an open policy I have in my "Application Control" layer ??????.

What if I don't have any explicit policy for my IP, in the application layer, and the implicit application layer rule is set to "DROP" mode, this could directly impact my VPN traffic S2S?????

Thanks for your comments.

[SSlater]

If I'm understanding correctly, Yes to both questions.

[Matlu]

I can't understand Checkpoint's behavior.

In summary, when building a S2S VPN, I need to have explicit rules in both layers (Firewall and APCL/URLF).

This is for any kind of scenario????

Or is it that, the Firewall layer, for certain "scenarios" will be able to work, without the need to "remember" that it also has to have a rule in the APCL/URLF layer????

[PhoneBoy]

Because you are using ordered policy layers, all traffic passing the gateway will need to match an Accept rule in each ordered layer.
In your specific case, it means matching a rule in the Firewall layer and a rule in the App Control/URLF Layer.
This is true whether VPN is involved or not.

Most likely, the reason you are seeing "applications" in your logs is because of the rules in the App Control/URLF layer.
You should see exactly what rules in each layer are being matched by reviewing the full log card, but may need to review earlier rules in the policy to understand why. 
See also: https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/m-p/9888#M1... 

[CheckPointerXL]

Build a inline layer and drop off the APPC/URLF blade from the layers with vpn traffic

Of cours you need to re-design the whole policy package to reach the goal to delete the ApplC Layer

[Matlu]

Hello,

With the design that we have now, for the traffic of a S2S VPN to work well, you must have explicit rules, in both layers in a mandatory way????

It is not enough to have a security rule in the Firewall blade layer, at least for S2S VPN scenarios????.

[the_rock]

Hey bro,

So, I will tell you how we do it for every CP customer. We always create rules on the top of the rulebase (geo block, VPN rules, generic block rules), BEFORE any inline layers. That way, say for vpn rules, if it hits one of those rules and traffic is accepted, then no one really cares how inline layers are configured.

Below reference explains that really well.

Hope it makes sense. At the end of the day, all you have to remember is this...traffic HAS TO be accepted on EVERY ordered layer (that is if you use ordered layers), but if not, then following link still applies...if traffic hits specific "parent" rule (inline layer), then one of "child" rules is hit and thats it, traffic accepted. If not, then it goes on, checkes every inline layer, and if none hit, traffic is dropped at the bottom, on implicit clean up rule.

Makes sense?

Andy

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SecurityManagement_AdminGuide/Topi...

[Matlu]

Hey, Bro.

I understand the idea a little better.

In my case, I have the layers "separated", but they are not well "tuned".

I inherited the Cluster management, without many details.

In the Firewall layer, the "Cleanup Rule" is with the "DROP" action, and in the APCL/URLF layer, the "Cleanup Rule" is with an "ALLOW" action.

I think that they did not take good advantage of this way of working of the layers.

I have to "tune" both layers, since, the residue of working with only one layer, gives the client the "fear" that there is a high negative impact on their production environment.

I suppose that if it is decided to work with both layers, as a "Best Practice", both layers should have as "Cleanup Rule" the action of "DROP", right ????.

Cheers 🙂

[the_rock]

I understand. Well, drop rule at the bottom of network layer is a must, but app layer should be allow at the bottom, just drop whatever apps/categories you need to block.

[Matlu]

So as a recommendation, in these environments of having separate "Firewall" and "APCL/URLF" layers, it is ideal that the "Cleanup Rule" of Firewall is set to "Drop", and that of APCL/URLF is set to ALLOW, yes or yes, right?

How could I define a granular rule, with the following scenarios, knowing that I have 2 separate layers????

For example:

SRC IP: 192.168.59.10

DST: INTERNET

SERVICE: ANY

APLICATION: Youtube/Netflix.

It is clear to me that I should create in both layers, but what would be the best way to do it, if you only want to give access to those applications and nothing else.

Maybe you could give me an "idea", highlighting that the "Cleanup Rule" of the APCL/URLF is with the ALLOW action.

[the_rock]

Yes and yes. In your case, allow that traffic on net layer and block it on app layer, thats it!

[the_rock]

Hey bro,

I will take bunch of screenshots from my R81.20 lab Friday and attach word doc here, so if you are not clear on something, you can let me know. It will give you good idea about good way how layers should be configured.

Andy

[Matlu]

Andy,

I would appreciate if you can give me that support.

Maybe with an "example" it will be easier to understand this type of flow.

Giving access to 1 IP/Segment, to certain type of traffic, such as point applications, like Youtube/Netflix/Facebook, when you have "separate layers".

Thanks for your time and consideration.

[the_rock]

Dont worry, will take bunch of screenshots and describe exactly how its configured.

Andy

[the_rock]

Hey bro,

Sorry, I keep calling you bro, since you never told me your first name : - ). Anyway, sorry for delayed response, went with my colleague to get coffee and donuts, that was our breakfast lol.

I attached a word doc with some screenshots that should give you a good idea how I set this up in the lab. Below are blades I have enabled on the firewall at the moment

[Expert@quantum-firewall:0]# enabled_blades
fw vpn cvpn urlf appi ips identityServer SSL_INSPECT mon
[Expert@quantum-firewall:0]#

So, essentially, its exactly what I mentioned to you yesterday. Idea is this...you HAVE TO make sure that traffic is allowed on all ordered layers, otherwise, it will get dropped. So, if you see in example I gave, I have 5 ordered layers (with inline layers inside of them as well) and say IF last rule in final_allow_layer said any any drop, INSTEAD of any any allow (like it does), ALL TRAFFIC would get dropped, reardless of rules before it, since very last one would be any any drop.

So, best way to do this is as follows...make sure that on network layer, you allow and drop as needed with any any drop at the bottom (IMPLICIT clean up rule) and then if you have more ordered layers, you can allow traffic through them as well. For app/urlf layer, I would do how we do it for most customers. Block what has to be blocked, but then allow at the very last rule.

Example...so since I have https inspection enabled in the lab, I allow access to the  Internet on my windows 10 PC behind lab fw, BUT, as you can see, I block access to gambling and few other categories. If anything has to be bypassed, if you use inspection, I would simply do so in https inspection policy. I know there were some posts on here saying that for best practise for https policy, you should use any any bypass, but I always found that bypassing rules first and then inspect at the bottom (default), works the best.

Hope it helps you.

If anything is unclear, please let me know.

Cheers,

Andy