- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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
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).
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.
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)
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 ?
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.
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...
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
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,
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.
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.
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?
Please see my response above to hmramos.
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
Thanks, I need to do this, will look at this now.
Can you PM me?
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
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
19 | |
12 | |
8 | |
7 | |
7 | |
6 | |
6 | |
4 | |
4 | |
3 |
Thu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAMon 22 Sep 2025 @ 02:00 PM (EDT)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security AMERThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY