How to hide internal IP networks attached to Security Gateways from the Mobile Access users

[ramon_efca]

Hi Check Point colleagues,

We have configured remote access in a Security Gateway with 81.10. We followed the common steps creating users, groups, access rules, etc, and also configured a VPN Community with topology "Remote Access" and VPN Domain all internal networks that can be accessible from MA users. It is important to note that MA users can only access to networks allowed in the Access control policies that applied to each of them.

The problem is that any MA user connected to the SSL VPN can list all these VPN Domain networks just running "route print".

How can I hide VPN Domain networks from MA users and show only networks allowed in the policies?

Thanks in advantage.

[_Val_ · Accepted solution]

Change your VPN domain object and list only networks allowed by the policy and not all internal networks. Reinstall policy, then it should be okay.

[ramon_efca]

Thanks for your answers, but it is a little bit complex. We have 6 different user groups, with 6 different access roles. Each of these access roles has an specific policy to allow access to 6 different internal network ranges.

The problem I found is that I can only have one "Remote Access" VPN community, and only one VPN Domain associated to the participating Gateway. So I have to add the 6 different internal network ranges to this VPN Domain.

[the_rock · Accepted solution]

There was never a way to add more than one RA community, not possible.

Andy

[the_rock]

What @_Val_ said 100% makes perfect sense, thats what you need to do.

Andy

[PhoneBoy]

All users who connect to your gateway will receive routes for all configured networks in your RemoteAccess encryption domain.
This is expected behavior at current.

[the_rock]

I think its been that way since long time ago. Not sure what @ramon_efca wants to do is even possible...

Andy

[ramon_efca]

OK, probably. This is my first time with Mobile Access. I have experience with other VPN SSL providers that you can define different "realms", with completely isolated accesses. I thought the Check Point equivalent would be Remote Access VPN Communities, but if you can only have one, I see no alternatives.

Thanks!

[the_rock]

Yea, sorry, it was never possible to have more than one.

Andy

[PhoneBoy]

With Traditional Mode VPN (deprecated in R60), I believe it actually was possible to do something like this.

Note that you can still restrict access to the various subnets today, just not prevent the inaccessible subnets from showing up in the client's routing table.

[the_rock]

Hey Ramon,

Just to make sure and please forgive me if Im way off here when I say this, but sounds like you want to do something along the lines where say different users can be assigned to different realms?

This was the answer I got from TAC on January 6th 2022, but does not appear this is still possible.

******************************

Hello Andy, 

After consulting with escalations, assigning specific users to desired authentication method in Check Point Multiple Login Options is not a supported feature yet, and there is already an existing RFE submitted for that. However, you can configure only RADIUS authentication, and have the RADIUS server determine who gets MFA or who does not, meaning configure the MFA on the RADIUS server/Using DUO or some other MFA services on the account itself instead of having the gateway to do the MFA. 

[ramon_efca]

Yes, I would like to create different isolated realms with different groups of users, and different internal network access. For example, if I want to have group1 with access to internal network1, and group2 with access to internal network2, I do not want that user1 from group1 could see network2 on his device (with SSL Network Extender client)  just executing "route print", and vice versa. But if I need to add network1 and network2 to the only VPN Domain that I can associate to the Gateway in the RA VPN Community, it seems that it could not be possible.

The answer you got is related to authentication method, but for me, in this case it is not a problem.

Thanks.

[the_rock]

K, got it. 

Andy