Restricting Remote Access by IPv4 Address

[Robert_Ellis1]

Objective: 

Permit Chekpoint Endpoint Security VPN clients to establish a connection only if those clients are connecting from a known a selection of IPv4 addresses. 

Clients are secured using Certificates issued by the Checkpoint Appliance but we do not want them to be able to connect unless they are being used from specific locations (and therefore are using known public IP addresses).

Our methodology:

-Disabled the Implied Rule "Accept Remote Access Control Connections"

-Other Implied Rules for "Control Connections" remain Enabled

-Configured appliance for Remote Access using Office Mode 

-Configured an Explicit rule for RA Connections:

 SOURCE = (Known group of IP addresses)

 DEST = External interface of Appliance

 Service = ESP, TCP18231,500,264,443, UDP500,4500,259,2746

 Action = ACCEPT 

Expected Result: 

-Endpoint clients with a Certificate AND inside private networks NAT'd out from one of the Known IPs can establish the VPN connection

-Otherwise no connection possible

Actual Result:

-Any client with a Certificate can establish the VPN connection from any source IP address

For verification, we have disabled the Explicit Rule for RA Connections (described above) (and left the Implied Rule "Accept Remote Access Control Connections" disabled) and even then, any client with a Certificate can still establish a connection successfully. 

The Implied Rule "Accept Web and SSH connections" is Enabled

This is using GAIA R77.3

Any advice gratefully received.

[PhoneBoy]

Where is the rule you describe into relation to the rule that permits access from the Remote Access clients? (Rule numbers)

Also which Remote Access clients are you using here? 

[Robert_Ellis1]

Explicit Rules 

...

#4 - the Rule I describe above (i.e. 

{ SOURCE = (Known group of IP addresses), DEST = External interface of Appliance } 

    (n.b. VPN = "Any traffic", because this is intended to Control the establishment of the tunnel)

#5 - Stealth Rule (Drop traffic to Appliance)

...

Numerous other rules...

#20 & 21     Rules that specify VPN = "x-RemoteAccess" to control client access through the tunnel.

The client is Checkpoint Secure Endpoint E80.72 Build 986005008

(I'm not sure of the relevance to the problem of the relative positioning of #4 and #s 20 & 21 - presumably the latter pair are only evaluated by the Appliance once the tunnel has been established... but I'll defer to expertise!   Do let me know please if I have misunderstood your question)

[PhoneBoy]

You understood the question perfectly.

If the rules were swapped in order, I may have thought the VPN rule was enabling the needed traffic.

After thinking about it more, what I suspect is happening is that the VPN traffic is actually being accepted by a different implied rule.

And, in fact, if you show the Implied Rules in the policy, you'll see rules for IKE and NAT Traversal there.

And this is even with the option you chose disabled:

From looking at $FWDIR/lib/implied_rules.def on the management, I'm thinking the two lines you will need to comment out are:

#define ENABLE_IKE

#define ENABLE_NATT

In other words, replace the above two lines with:

/* #define ENABLE_IKE

#define ENABLE_NATT */

And install the security policy.

In general, though, one should be careful about disabling all implied rules.

See: How to completely disable FireWall Implied Rules 

[Robert_Ellis1]

Thanks for this

Disabling any more of Implied Rules does make me nervous, particularly IKE, because we are also running other Site-to-Site VPNs which I do not want to break.

So I may have to stick another firewall in front of the Checkpoint to get exactly what I want

Thanks for your time and help! 

[PhoneBoy]

In terms of implied rules that can be disabled, these have a much lower impact than, say, disabling FireWall-1 Control Connections.

Also, if you go down this road, it's worth pointing out this is most likely a change that won't be preserved on upgrades. 

[Robert_Ellis1]

Tried to disable the Implied Rules: as predicted, all of the Site-to-Site VPN connections came crashing down (this, even with explicit rules in place to compensate).

Have also tried putting a firewall in front of the Checkpoint and NATTing the Remote Access connections through, but it all got too messy and unworkable. (I have discovered the limitations of Checkpoint Policy Based Routing along the way).

Now reaching out to Checkpoint Support for guidance.

What a wasted weekend LOL

[PhoneBoy]

Not sure why I didn't think of it before, but you can restrict the sources the user is allowed from in the user profile itself.

This won't block IKE traffic from unallowed sources, but it will prevent the specific users from authenticating if they are not at an allowed location.

[Robert_Ellis1]

I assumed that those referred to IP topology zones as seen from the perspective of being inside the tunnel.

It would be quite hilarious if this was the solution, given the amount of time I have spent on this.

I'll try it. If it applies to the "plain" (outer) connection, then it will probably be good enough, if not ideal.

Thanks.

[Robert_Ellis1]

Yea, so based on a quick test, the settings you are looking at have nothing to do with whether or not the tunnel can be established.

Authentication works independently of these settings.

These settings are controlling traffic inside the tunnel once it has been established (much like standard Policy)

[PhoneBoy]

If you're not using Office Mode on your VPN clients, then this can work.

Granted, it will still allow tunnel establishment, but they won't allow any traffic to flow through.

In any case, it was worth a shot. 

[PhoneBoy]

Try creating an Access Role for your VPN users.

Ensure that access role is limited to the specific IP addresses.

Use that as the "Source" for your Remote Access rules.

[Robert_Ellis1]

It seems fairly unlikely to me that that will work. I strongly suspect that it's just an extension of the functionality we have already discussed - don't you?

I may give it a try tomorrow. It's spectacularly late here.

Another option has occurred to me which is to place a firewall bridge in front of the CP instead of a routing firewall. This would allow me to filter but without needing any additional awkward routing requirements on the CP itself.

I'll see what CP support say too. You'd think that there would be a way of doing this on the CP box - but I'm coming toward the surprising conclusion that there isn't. Perhaps, not many customers have this as a requirement.

[PhoneBoy]

Access Roles are different functionality than what I previously described.

They handle this requirement for non-VPN usage (who, where, on what machine) for sure.

The previous functionality I described has been in the product for a couple of decades now.

Very different use cases

[Robert_Ellis1]

I can confirm that this is not possible, because it isn't possible to use an Access Role in the Source Column of a VPN-specific rule.

Policy fails validation.

[Robert_Ellis1]

Can also confirm that (somewhat unsurprisingly) using an AR in a VPN "Any Traffic" Rule has no effect on policy inside the tunnel (even if the AR includes Users authenticated to establish the tunnel).

[Robert_Ellis1 · Accepted solution]

This is the answer... at last

Network Location Awareness in Global Properties

It had to be something simple!

Thanks again for your assistance.

[PhoneBoy]

Glad you were able to figure it out.

Sorry I wasn't able to provide the correct answer

[Kaloyan_Kirchev]

I see this is pretty old post but I am struggling with Legacy LDAP groups for RA VPN.

I am trying to make a exact VPN user(local/LDAP no matter) to make VPN connections only from specific External IP.

Guys who installed RAVPN used legacy groups in Firewall access policy config. When any group is used @any location it works perfectly.

When I try to use with specific IP....not! It does not match the exact rule.

I tried with Access roles. With separate RAVPN blade(Mobile access enabled) but...same result.

PLEASE HELP!

@Robert_Ellis1 Network location awareness solution is for all RA VPN users I suppose?

[Robert_Ellis1]

Hello

It's been quite a while, so E&OE!

IIRC, NLA is a Global setting; the benefit of NLA is that your Checkpoint VPN users will see their clients activate or deactivate on the basis of the IP addresses at their physical location. This allows you, for example, to seamlessly deactivate the tunnel when the user brings their laptop into the office, and activate it again when they go on the road. NLA works nicely for this purpose, but I'm honestly not too sure about its granularity - I'm not sure it's going to help you in relation to 1 specific user. I would also urge you to exercise some caution when it comes to the notion of relying upon NLA as a security control. I say that because I am unsure if Checkpoint themselves see NLA as a security control or as a useability function, but it seems to me to be presented as more of the latter than the former.

If I understand your problem correctly, you want to determine whether or not a user can establish the VPN connection based upon their source IP address (rather than wanting to control the traffic within an established connection, which is obviously a separate issue and easy enough to manage by policy). In that case,  I have only bad news for you. I have spent an inordinate amount of time investigating this same requirement, including reaching out to quite senior Checkpoint techs here in the UK, only to finally conclude that this control does not exist on Checkpoint. You can turn visitor mode off for everybody (so that no one can connect) or you can turn it on (so that everybody can connect) but you cannot filter this down by source IP, let alone for individual users. I was stunned by this discovery, given Checkpoint's general reputation, but I can confirm that this is indeed the case. 

Obviously this is problematic if you want to deploy a Checkpoint to protect your perimeter network but you would prefer for not everyone to know it is there. It seems that Checkpoint's design assumption is that anyone who needs VPN functionality needs it for roaming users and by extension, must need it to work for any client source IP address anywhere in the World. Meaning that those of us who'd like to use VPN on a less-permissive basis are out of luck. 

It might be possible to "fix" this if you were willing to go beyond the GUI tools, Policy and Implied Policy, and to start messing around with internal network rules inside the boxes themselves, but I wouldn't recommend it and I don't believe it is supported. 

I'm a fan of Checkpoint products generally - I'd say I am 15% more confident using Checkpoint than, say, Fortigate or whomever else. But the fact that you can't make a choice to hide your gateway in this particular respect has always puzzled me and feels like a glaring oversight. 

Sorry I could not be more helpful or offer more encouragement. Best of luck. 

[PhoneBoy]

Is the requirement to not respond at all if they're not coming from the correct IP or is it they can connect, but can't go anywhere unless they are coming from the correct IP?
The former likely cannot be fixed unless you're willing to start hacking .def files to adjust implied rules, but it seems like the latter may be doable using an Access Role, but will admit, haven't tried it yet.

[Kaloyan_Kirchev]

I am using Office mode. So access roles seems fine. BUT I did not succeed as guys are using legacy sources for VPN access.

I have tried using Access Roles...broke all VPN connections...still did no succeed. Also Access Roles requirement is AD(Identity awareness) cannot use it only with local users.

I used separate inline layer for Mobile Access with Access Roles. Also tried to install a SEPARATE policy layer for Mobile access and configure Access roles there..but still without success.

I am trying to make a lab with our oldschool office CP 4800(also R80.30) but cannot use Access roles based on what I wrote(no IA).

Also I am playing with user.def but cannot succeed there. Cannot enable it with "om_use_ip_per_src_range (<value>)" Can you help with that. I tried to enable it in user.def.FW1 but there are another 10 files user.def.*. Also I was playing with objects_5_0.C which seems VERY dangerous to me.

@PhoneBoy I will be very THANKFUL if you help with this.

[Kaloyan_Kirchev]

Wow,

what a reply.

THANKS MAN!

This was stunning. I am Checkpoint certified, cisco certified, a huge PA experience but.....this comes to me a little confusing.

You understand perfectly my question. And this is not my request or will, it is customer requirement.

After drilling down this forum and most of CP guides I found that based on cli .def files you could specify Internal IP by user of by Source.

It is such a pity I did not succeed with source IP. But ipassignment.conf file works perfectly. This for sure does not solve my problem.

I am still trying.

One of our high tech/architects told me...."wait if you want a specific IP it is Site-to-Site :D"

Again thank you for the reply and all the details you provided. It is such a valuable shared experience.