Restrict VPN access by GEO location

[Braden_Bersik]

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

[PhoneBoy]

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_]

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.

[K_montalvo]

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)

[G_W_Albrecht]

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 ?

[hmramos]

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.

[G_W_Albrecht]

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...

[ANARINE]

Fast forward to massive 2026 vpn cve.. this would have provided much needed protection for the early days of this zero day. It is useful. Very.

[ccsjnw]

Many customers have a long list of countries that they block (or a short list they want to allow). It’s a very common and standard security pratice. It’s just annoying that it’s ineffective for Remote Access VPN connections, unless you disable implied rules and make it work the hard way…

Just because you don’t have a use case, doesn’t mean that’s true for many other customers. There are many customers who really want to implement strict GEO controls and compliance teams who demand it.

[Duane_Toler]

IIRC, you can do this, if you turn off VPN and Remote Access VPN Implied Rules and instead build individual rules for the things you want.  Be careful, tho, because you'll need to get the exact groups of services.  For RA VPN specifically, you just need HTTPS and IKE NAT-T to do the initial connection.  Site-to-Site VPN needs many others.

[ccsjnw]

Yes, I’m aware of that. My colleague turned off implied rules and made this work for one company that absolutely had to have GEO blocking enabled due a government mandate, but it’s not a supported configuration and it’s a pain to implement. This just needs to work properly out of the box…

[Duane_Toler]

I presume you've also seen the Geo Protection policy in the Threat Prevention section? This would apply to all traffic, of course, so it may be too aggressive for your needs.  You can still allow exceptions to this policy, tho.

[ccsjnw]

Yes, unfortunately that’s too restrictive.

We need granular control in the Rulebase to only allow or block inbound RemoteAccess VPN connections based on GEO location.

[hmramos]

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

[Braden_Bersik]

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]

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. 

[K_montalvo]

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?

[Braden_Bersik]

Please see my response above to hmramos.

[the_rock]

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

[paolozzipointer]

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

Can you PM me?

[the_rock]

Hey mate,

Im so sorry I only saw this response now, cant believe missed it back in July 😞

In case you did not make it work, let me know and we can do remote.

Thanks @paolozzipointer 

Andy

[ccsjnw]

I know of customers who do this now, but it currently painful because CheckPoint don’t make it easy. Many more customers really want to do this, and would if CheckPoint made it straight forward to implement.

We simply want a very limited GEO allow list, Two (possible three) countries is all we want to allow for Remote Access VPN connections. 

While GEO blocking isn’t a panacea, it is another line of protection. Many would-be attackers don’t fake their GEO location when performing recognisance or IP scanning activities when looking for targets to attack. So if your customer appears invisible to a large junk of the worlds IPv4 address space, there’s a fair chance the bad actors will just move on to someone else…

[Ruan_Kotze]

I realise this not exactly what you are looking for, but if you are using eg. a SAML provider like Entra, you can apply your Geo Controls there. That's the route we took.

[emmap]

I believe you can carefully craft some fwaccel dos drop rules to drop packets by country code and specific ports which would kick in before implied rules, but it's not the most user friendly thing to do.

https://support.checkpoint.com/results/sk/sk182350

[Ruan_Kotze]

Yep, can confirm that. Although have been burned in the past with even just Jumbo's (not to mention Blink upgrades) overwriting config files and then inadvertently broadening your attack surface again.