Multiple Remote Access Communities (GW Version?)

[Christoph_Holzi]

Hello, when playing around in R80.10-Management today, I discovered that it's now possible to define multiple remote access communities (including defining different vpn domains for each RAC). First of all, thank you CheckPoint - I've been waiting for this feature for so long.  [edit 07.01.: more a bug than a feature, see below]

I couldn't find any hints regarding multiple RACs in the R80.10 Release Notes/HFA Notes/Support-Center.So my questions are:

Is there any official statement whether the GW has to run R80.10 or can this be configured for a R77.30 GW (managed by R80.10 SM) as well?

(added) Any experiences/considerations when using on VSX?

Thanks in advance!
Greetings Christoph

[PhoneBoy]

To be honest, I haven't heard anything about this myself.

I suspect if this were not allowed, you'd have issues pushing policy.

Have you tried doing so?

[Christoph_Holzi]

I can remember that a developer told me about it at CPX, but more as an upcoming R80.20 feature.

No, I didn't have the opportunity yet, but I'll try it next week.

[PhoneBoy]

Curious, how you managed to do this?

I can't get SmartConsole to allow this in R80.10 or R80.20.

[Christoph_Holzi · Accepted solution]

Hi,

to be honest, I didn't have time to test it so far which means that I don't know if the configuration actually verifies or can actually be deployed, but I managed to configure it the following way (R80.10 Smart Console):

Right-click on existing RemoteAccess-Community -> New... (in the objects bar, not the object explorer) - this allows the creation of another RemoteAccess-Community-Object (Maybe this is the part that should not be possible to do as the "standard" menu to create a new object "New... -> More -> VPN Community" does not offer a RemoteAccess-Community). Afterwards you can define different VPN-Domains in the topology settings of the participating gateway object.

[PhoneBoy]

Huh, interesting, that does seem to work. 

From what I know, this isn't supported.

The fact you can create more than one Remote Access community would be considered a bug.

[cezar_varlan1]

Could we get a confirmation if this works to the point where you may also have different rules set up or is it just the fact that you have 2 RACs.

According to the Admin Guide you can create a new Remote Access community but it never mentions how. However it doesn't mention that you can use more than one in the policy. 

There is also a definition of Encryption Domain on the Gateway object itself so having 2 RACs on the Same Gateway would imply using the same Encryption Domain.

[PhoneBoy]

Like I said, the fact the GUI allows you to create more than one Remote Access community is a bug.

Where in the documentation does it state you can create a second Remote Access community?

The only place where I could see it being useful is if you could also define the encryption domain for the different communities.

But since the encryption domain is defined on the gateway, and it would be the same for all communities, I don't see a real benefit to different VPN communities for Remote Access.

[Christoph_Holzi]

Well, the thing is, that the GUI actually allows you to define a separate encryption domain per remote access community. (GW-properties -> Network Management -> VPN Domain -> Set domain for Remote Access Community...). I didn't want to deploy that on productive environment (therefore my question), so I don't know if the policy installation is allowed, but you can configure it in R80.10 SmartConsole (that led me to the assumption that this might be a new feature...).

[cezar_varlan1]

Dameon Welch-Abernathy wrote:

Like I said, the fact the GUI allows you to create more than one Remote Access community is a bug.

Where in the documentation does it state you can create a second Remote Access community?

The only place where I could see it being useful is if you could also define the encryption domain for the different communities.

But since the encryption domain is defined on the gateway, and it would be the same for all communities, I don't see a real benefit to different VPN communities for Remote Access.

Well here is the place it says you can create "a new Remote Access VPN Community" with a different name. This to my understanding is equivalent with a second Remote Access Community as it is new and does not replace the existing one. However it never states anywhere in the manual how to actually create it. I would say it's a more a feature and less a bug.

@Christoph Holzinger i will test this in production and update soon.

[Luigi_Vezzoso1]

HI,

I have just tested this possibility but It's not working!!! The policy installation fail said that we can use ANY or "RemoteAccess" as Community name

Some one know how have the possibility to view just one gateway on the VPN Client instead of all Gateways contained into the community?

Best Regards

[Christoph_Holzi]

ok interesting, thanks for testing.

Regarding your question: If you mean the dropdown that appears after the first successful connect, I think the solution you are looking for is sk78180. (at least it solved the same issue for me ).

[Luigi_Vezzoso1]

I have tried the sk78180.... only on a secondary gateway but  doesn't work? Do I need to implement on all gateways?

My goal is to remove the dropdown list that shows all gateways in the remote community!

thaks

[Luigi_Vezzoso1]

I made the change on both gateways....the dropdown list is removed but the client is still connecting to the "primary" site....

[Luigi_Vezzoso1]

I solved with your SK!

Thank You very Much!

[Bob_Delinsky]

Greetings,

Has there been a definitive answer if multiple remote access community, with separate encryption domains applied to each community, and then installed to the same gateway or different gateways is a supported feature? This functionality is something a customer is currently looking for as they want to disable split-tunneling for some users while allowing split tunneling for others. Having only one encryption domain is a limiting factor. Being able to push down a different routing table based on user, say Identity Awareness credentials would be a great option as well. 

Regards

[Bob_Delinsky]

Add on to the above post, for Endpoint there is an option of creating a new *.ttm. file that hands out configurations based on group membership. sk114882.  I haven't found any documents as to how this would be deployed with the Mobility Blade and SSL Extender. Having the capability to assign users to a different remote access community at the management level would be a great feature if it is truly supported.

[PhoneBoy]

As I said previously, even if you could define more than one Remote Access community, there is only one encryption domain.
The fact you can even define a second Remote Access community in a particular circumstance is a bug—I confirmed this with R&D.

[cosmos]

I know this is an old thread but the bug (?) still exists in R80.40 HFA91 - right-click RemoteAccess in the Objects bar and select New. sk160892 states this "problem" was "fixed" in R80.20 - what exactly did this fix entail - enabling support in the software for multiple RACs or remove the option to create a new one in the Objects bar?

My need for multiple RACs relates to a migration PoC I am running for a customer, we have a new cluster we wish to test Remote Access on without existing clients seeing the new gateway (I'm assuming MEP will allow clients to use the new cluster before it is commissioned / 'blessed' with the default RAC, I want to avoid touching the current gateway as much as possible).

[PhoneBoy]

The fix was to prevent you from creating more than one RemoteAccess community.
As of right now, you can only have one RemoteAccess community defined and it needs to be called RemoteAccess.
You'll probably have to use MEP to achieve the requirement at the moment.

[cosmos]

Thanks dude, appears the bug still exists in R80.40:

[PhoneBoy]

Probably needs a TAC case so an appropriate bug can be filed.

[Ilya_Yusupov]

Hi,

Can you please explain the motivation to have 2 different RCA's?

[Bob_Delinsky]

Llya,

The attraction of having multiple Remote Access Communities would be to have different configurations for different user base, including but not limited to different encryption domains, different approved sites or whitelist of sites, rules  based on the community the user joined. Some of this can be accomplished by modifying local .ttm files on the gateway, but this functionality should be part of central management, not custom files on a gateway that has the chance of being overwritten during a fresh install/upgrade.

Current need it to have split tunneling enabled for some remote users but not others, allow a few approved public sites to go local from the remote device (Microsoft Updates for example)  while forcing all other Internet traffic through the tunnel. 

[PhoneBoy]

While I understand most of the other issues, I don't quite get the need for different Remote Access Communities.
What a given user can access is determined entirely by policy, not what the encryption domain is.
Maybe the disclosure of the various subnets is an issue, not sure.

[Robert_Canis]

PB,

First off, cool running into you this summer.

Here's a very specific use case for multiple remote access encryption domains.  We are being required to send all our users data to our gateway BUT we have a few business units that do NOT have this requirement.  Being a very large global company, we use the same gateways for all of our 50 business units.

As you can see, how would you do a remote access community for some people to route all through the gateway and then have a few users here and there route only what is needed (our internal networks) and allow the rest to go out locally?

BTW, one caveat is that we also need to break out skype traffic from going down the tunnel, so we cannot do route all through gateway, we kinda have to do a group with exclusion of 0.0.0.0/0 minus our skype servers if that makes sense.

[PhoneBoy]

The different Remote Access communities can be solved by using VSX to some extent (different termination for different users) or different physical gateways.
You can decide to "route all traffic" based on user group.
See: https://community.checkpoint.com/t5/Remote-Access-Solutions/Exclude-Subnet/m-p/23608

[Eichholz]

Hi, i know its a old Thread but still there a needs for this topic, is there naything new in Year 2023/2024 about htis topic ? We also faced the issue that we need to deploy 2 gateways in order to manage one group of employees to get route all traffic and the other group not to. 

Other Firewall manufacturar got profiles for this and you can manage this thinks you guys brought to the table. We have these different use cases and do not want to deploy 3 different Gateways for it.

[PhoneBoy]

Unfortunately, this has not changed in current versions.