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

Restrict VPN access by GEO location

I've been tasked with restricting access to our VPN by source country. I've been given a list of "approved countries" to allow, all others are to be denied access. We are currently restricting inbound/outbound Internet access by country (separate gateways from our VPN gateways), which I fully understand and support (especially the outbound!).

Conceptually

What are the benefits or value of restricting access to VPN gateways by source country?

Is the security gain worth the effort when it is fairly easy to circumvent?

Is anyone else doing / trying to do this?

 

Technically

We are currently using the Mobile Access Portal (ssl vpn) for third party access, and Remote Access (client-based) for employee remote access.

Gateways are running R80.40 JHF 91

I've implemented an access control layer with explicit rules using updatable GEO objects. This layer is the first layer of 3, so that it is processed first. However, implied rules take precedent. So in conjunction with the policy, I've implemented configuration based on 2 sk's:

SK105740 - HTTP and HTTPS requests to external interfaces create implied rule 0 accepts in SmartView Tracker (c... - This allows policy to control access to the Mobile Access Portal (clientless). This works brilliantly. We have successfully restricted access based on our "approved countries" list.

SK62692 - Ports used on Security Gateway for SecureClient and Endpoint Security VPN (checkpoint.com) - This was provided to us by TAC and handles the Remote Access configuration. The idea is to disable the "Accept Remote Access control connections" under Global Properties --> Firewall. This SHOULD disable the implied rules and allow explicit rules in policy take over. After implementing this, implied rules are still allowing all connections.

I've updated the TAC case and waiting for further guidance. However, I'm interested in everyone's input, suggestions, recommendations, etc. Especially if you've implemented this in your environment and can share insight on how you have it working.

I'm also very curious about anyone's thoughts around the "conceptual" questions above.

 

Much obliged,

Braden

0 Kudos
13 Replies
PhoneBoy
Admin
Admin

I haven't heard of anyone implementing this for remote access.
The fact disabling the relevant implied rules option isn't working will definitely require some assistance from R&D (possibly a bug).

_Val_
Admin
Admin

Personally, I do not see a point of applying GEO restrictions to RAS VPN. Proper user/endpoint auth should be much more effective when filtering unwanted connections.

(2)
K_montalvo
Advisor

You are right the Geo Policy would be like an additional security control however "malicious actors use VPNS" to bypass such restrictions so i would focus on implementing MFA for the Remote Access VPN primarily if not has been implemented yet.  (You don't want a roaming user connecting from a hotspot that suddenly the routable IP is from that blocked country)

0 Kudos
G_W_Albrecht
Legend Legend
Legend

I can not imagine any gain from using Geo Location restrictions - either the client is allowed to connect or not, that does not depend on the country someone thinks is the location of your IP.  Or are companies all of a sudden receiving masses of  of traffic from Russia and Belarus ?

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0 Kudos
hmramos
Explorer

There some groups that are actively trying to recruit employees from companies and buying their vpn and citrix credentials, and some companies now are requesting that the access should be block by geolocation to minimize the possible impact that this might have.

 

 

0 Kudos
G_W_Albrecht
Legend Legend
Legend

Such groups do use VPN to simulate any location, so this does not make sense if professionals are involved. 2FA using phones with e.g. FaceId or fingerprint are much better ! Also such a config tends to have false positives that are blocked from time to time, and it can take CP 2-5 days to resolve this...

 

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0 Kudos
hmramos
Explorer

Hi Braden,

Just wondering, was the TAC able to help you out with the SK62692 and the implied rules? Im having the same issue.

 

Regards

0 Kudos
Braden_Bersik
Participant

TAC declared this an unsupported configuration. The only workaround would be to disable ALL implied rules and then build a set of explicitly defined rules in policy to allow the gateway to function properly. However, as stated in sk43401, 

"Check Point does not support replacing implied rules with explicit rules."

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

I have since abandoned this endeavor. The amount of effort and lack of security gain is not worth it. I never believed there to be a strong security gain to restricting access based on geolocation given that it is easily circumventable, but sometimes the bosses want you to try anyway. 🙂

MFA should absolutely be employed for ALL Remote/Mobile Access VPN. If you're not doing this now, focus on that. The security gain of MFA is significant.

PhoneBoy
Admin
Admin

This might be something you can implement with SAML based authentication (specifically allowing people only from specific countries).
This would have to be done in the identity provider. 

0 Kudos
K_montalvo
Advisor

Hello Braden,

Have you tried to configured a rule allowing access with a dynamic Object a a source and below another rule below with dynamic Objects that Deny?

 

 

 

0 Kudos
Braden_Bersik
Participant

Please see my response above to hmramos.

0 Kudos
(1)
the_rock
Legend
Legend

I know this is an old post, but I wanted to share method on how I made this work.

Best,

Andy

 

https://community.checkpoint.com/t5/Remote-Access-VPN/Geo-VPN-blocking/m-p/214040#M10593

0 Kudos
(1)
paolozzipointer
Explorer

Thanks, I need to do this, will look at this now.

Can you PM me?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events