Separation of access for RemotaAccess, CRL error

[MiniNinja]

Good afternoon.

I have a cluster of 6700 gateways with version R81.20, with remote access features enabled: IPsec VPN, Mobile access, Identity awareness.

The public IP is not assigned directly to the cluster, but a static route to the internal IP of the cluster is configured from Internet routers. Therefore, the Link selection specifies a Statically nated IP.

Domain integration is already set up, that is:
1) deploy Identity collector;
2) Identity collector to DC and gateway;
3) the DC settings are made according to https://support.checkpoint.com/results/sk/sk60501;
4) An LDAP account unit has been created and configured.

Access under domain accounts is successful.

Goal:
It is necessary to differentiate access for remote users connecting from domain machines and non-domain machines.

That is, to provide access to more resources for remote access users who connect from domain machines, and to provide a minimum access to resources for those connected from non-domain machines.

The first thought was to create:
1) Access role (role_work_pc) and there specifying the network (the pool of addresses issued in office mode - n_VPN_Pool_Remote_Access), the domain group of users (remote access users - checkpoint vpn access), as well as the group containing domain machines (Work_PC).
2) Access role (role_home_pc) and there specifying the network (the pool of addresses issued in office mode - n_VPN_Pool_Remote_Access), the domain group of users (remote access users - checkpoint vpn access).
2 rules have been created for the test: the first allows access for the Access role role_work_pc anywhere, the second for role_home_pc allows access only via RDP to one server.

The gateway did not define/assign a group for the working machine (entered into the domain) and did not determine the name, the result of the check for the test user chkptest (logged in to the test domain machine, via VPN and on the domain machine inside the network), the command:

pep s u q usr chkptest

I tried to use the Identity agent, but it did not want to connect to the gateway even with the VPN connected, which is strange, since the Terminal agent connected successfully on another domain machine inside the network.

But besides that, I would not like to install an agent on the machines.

Then I came across https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RemoteAccessVPN_AdminGuide/C...

And completed the steps except "Optional - UPN with Machine Certificate".

A certificate was requested and installed via a snap-in (mmc) on a Windows 10 domain machine (entered remotely into the domain).

The certificate was issued by a subordinate certification authority, previously both the subordinate and the root certification authority were added via SmartConsole.

Checkpoint VPN 87.50 is installed and a CRL request error occurs when connecting.

The certificate has a standard http CRL distribution point that is created when deploying a Microsoft certification authority.
As an experiment, a NAT rule was created redirecting port 80 to the CRL distribution point from the public IP of the remote access connection, but the result is the same - the error persists.

I turned on the logging of the Implied roles and saw that when trying to connect, a redirect from the gateway to SMS is recorded on port 18264 (this port happens on SMS).

I'm missing something, but I don't understand what, I'd appreciate your help.

[PhoneBoy]

Remote Access is itself an Identity Source, so you should not need to install an agent on a remote PC.
What is the precise URL of the CRL in the certificate?
Is this URL accessible to a client (including DNS resolution) without connecting to the VPN?
I believe this is a requirement.

[MiniNinja]

We have created a public record for accessing the list of revoked certificates leading to the same IP as the VPN.
The certification authority has added a distribution point for this public record.
We have created a NAT for broadcasting port 80 from a public IP to a certification authority and a permissive rule.
There are no problems with access to this point from the inside of the network, but there is a problem from the outside.
I see in the logs that the conversion and NAT are successful.
As a result, the connection situation has not changed.

[Chris_Atkinson]

Have you verified the communication is working bi-directionally with either fw monitor, cppcap (or tcpdump)?

My initial thought when reviewing the details provided was that perhaps multiportal might be absorbing the port 80 request.

[MiniNinja]

I do not exclude that the Mobile portal overlaps, since everything is available from the domain machine inside the network.

[MiniNinja]

Update:

I created a template based on the Workstation template (Microsoft CA), and made it according to the documentation so that the subject's name was in the format:

CN = DESKTOP-12345, OU= Computers, DC = example, DC = com

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RemoteAccessVPN_AdminGuide/C...

A distribution point accessible from outside on port 80 has been added to the certificate, and the CRL is quietly downloaded through the browser.

That is, NAT works, the rules work for the distribution point.

When trying to connect a VPN client and the logging of Implied Roles is enabled, I see calls from the gateway to SMS on port 18264, but it's not clear why, because according to https://support.checkpoint.com/results/sk/sk149253 I added a root certification authority, a subordinate certification authority, and after making a request, I added a certificate.

[MiniNinja]

one more update - log iis

[PhoneBoy]

SIC uses CRLs as well, so seeing traffic on port 18264 between the gateway and SMS isn't out of the question.
Sounds like you might need to have TAC help troubleshoot this: https://help.checkpoint.com 

[MiniNinja]

I managed to defeat the error, I just need to disable the LDAP CRL request in the certification authority object.

At the same time, I see through the pep output (described above) that the role is assigned and the name of the machine is visible.

But there is 1 problem: when logging in from a domain machine, the system assigns 2 roles at once, which is why the rules work randomly.