Location awareness and EpMaaS - possible?

[Alex-]

We're trying to activate a specific firewall policy when connected or not, having also specified a connected/disconnected rule.

However, the result always seems to be the generic connected firewall rule and never the disconnected state.

The goal is to have a different firewall access at the office than outside.

Is this possible with EpMaaS?

[Don_Paterson]

I don't think that what you are looking for is a dedicated feature/policy option.

Would be nice to have, but an RFE would probably be needed to have it added, sorry to day it (https://support.checkpoint.com/results/sk/sk71840) 

You can always try to ask your SE/Contact at Check Point. 

This thread is related and offers Connection Awareness as a kind of work-around but it's not really the desired feature.

https://community.checkpoint.com/t5/Endpoint/what-is-the-purpose-of-disconnected-policy/td-p/205901 

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_HarmonyEndpointWebManagement_Admin...

The disconnected state description in the documentation seems to need to be revised, and seems more specific to an on-prem Endpoint Management Server (EPMS) solution that is only accessible when connected to the LAN/in the office.

Meaning that the EPMS set up does not include access to the server over the Internet (access when off site via static NAT).

With MaaS always online and reachable, and endpoints almost always online when booted up (apart from the flight mode or similar scenario) the Disconnected state is less likely.

"For example, you can enforce a more restrictive policy if users are working from home and are not protected by organizational resources. You can define a Disconnected policy for only some of the Endpoint Security components."

[Alex-]

Thanks for the detailed answer.

In the client settings, there is still a setting which says "Consider the client connected if", then gives the choice of the management service or some custom targets. As per the documentation, we would expect the firewall blade to support either state but even with that setting set manually, the endpoint client shows a connected status.

There doesn't seem to be monitoring for this either.

[Don_Paterson]

If it is not working as designed then there is a problem that should probably be reported through an SR to TAC.

As long as the custom targets are not reachable/responding the 

The monitoring part makes sense if we consider that the setting is a client side setting (Connection Awareness) and the client can still reach the MaaS even if it can't reach the custom targets, and MaaS is only designed to repost connection state based on heart beats and not Connection Awareness state.

@BarYassure  is this something you can advise on?

For reference:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_HarmonyEndpointWebManagement... 

[Hrvoje_Brlek]

Hi @Don_Paterson @Alex- ,

Just stumbled upon this thread. We are using both EPMS on-prem (for Win notebooks) and EpMaaS in cloud (for MacOS notebooks). 

EPMS:
The on-prem EPMS is being used for years now, with the firewall blade being active in the connected/disconnected state.

The connected state is forced when the EPMS server is reachable by the notebook (meaning the client is connected to VPN or in the physical office). In this state we have configured the inbound/outbound rulebase to allow almost everything (this is the rulebase for the firewall blade only).

The disconnected state is forced when the EPMS is not reachable by the notebook (no client VPN connection or not in the physical office). In this state we have configured the inbound/outbound rulebase to block everything except DNS, DHCP traffic (to allow the notebook to get basic network connectivity) and our public IP range (to allow and force the client to connect to the remote VPN only). This all works like a charm for many years.

EpMaaS:
Recently we started adding MacOS notebooks to our network and started using EpMaaS in the cloud for them. The logic here is similar to the on-prem one, only it seems to be weakly documented an explained. The connection to the EpMaaS seems to always be in the connected state (as long as you have Internet connectivity) and is shown in the client GUI as connected (online) always.  To view the real effective policy of the firewall blade you will need to check in the client GUI under Advanced -> View Policies.

To force the different policy for connected/disconnected state you need to use the option under client settings which says "Consider the client connected if" (as @Alex- wrote above) and add for example some internal resources that are only reachable on your network (example DC, DNS or some other server). Afterwards the policy and logic for the inbound/outbound rulebase in the firewall blade is the same as for the EPMS (for connected/disconnected state). Except the fact that on EPMS (SmartEndpoint) the GUI is more user-friendly and policies are much more visible than on the EpMaaS. 

The "problem" we had, which I think is not visible enough and documented properly, is the Policy Operation Mode. So, on the EpMaaS under Endpoint Settings there is the Policy Operation Mode which is especially important for the Access and Client Settings. If used in Mixed mode it is forced to Users first (in example AD user or group) and Devices afterwards (in example AD machine or group). After setting it to Mixed mode you can change and edit the firewall blade rulebase (under Access & Compliance) for Users and Devices sequentially, like below, this may be the part where your policy isn't being properly matched :

Hope I was helpful and didn't over-complicate it too much 🙂 

 

[Alex-]

In the end we had it working. Finding something to ping reliably was the most challenging part, so we created a dedicated VLAN on the FW with a policy that it's accessible for echo-request only from inside and Remote Access VPN, so users are considered as "connected" there as well. There's now a connected/disconnected policy for the local firewall.

Each station is pinging every 30 seconds the VIP s we don't impact users in case of regular failover and so on. It's not the prettiest but it works.

Thanks for the tip about policy mode, this opens other venues for configuration.