topic Re: Multiple Remote Access Communities (GW Version?) in SASE and Remote Access

Two Gateways Serving the Same Encryption Domain

PointOfChecking — Wed, 26 Apr 2023 18:18:23 GMT

Hey,

We've got 2 GWs at 2 different geographic locations. We want to enable remote access on both of them. The one at HQ is already up and running for a few years.

The new one at our branch site is being set up now. When I try to add the 2nd GW as part of the same RAC, it causes the production one to fail. By "fail", I mean the user can successfully connect, but there would be no traffic through the tunnel. It would then keep asking the user to log in to the VPN again (eventhough it's still connected), this time it shows the 2nd GW name.

If I try to create a second RAC, I can't and you say it's not supported.

How do I go about setting up the 2nd site as a VPN entry point?

Thanks.

R80.40 3800 (HQ)

R80.20 Quantum1800 (Branch)

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Thu, 20 Apr 2023 21:57:38 GMT

Make sure Secondary Connect is properly enabled.
See: https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_RemoteAccessVPN_AdminGuide/Topics-VPNRG/Secondary-Connect.htm

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Fri, 21 Apr 2023 08:23:06 GMT

Thanks, but actually we don't need to allow the dynamic connection to 2 sites. We just need to allow the user to connect to either site.

If I disable secondary connect without configuring the new site yet, would the existing site have any issues?

i.e. As it's a production environment, I want to do testing/configuring one step at a time, so if something goes wrong I know what I should rollback.

Is there a way to check the current status of secondary connect (enabled or disabled).

e.g. is there a get secondary_connect status command? Or just check the trac_client_1.ttm file?

Currently to get the primary site back up and running, I have removed the secondary site from the RAC.

I'm thinking if I disable secondary connect first on all GWs, check that it's all working.

Add the secondary site back to the RAC, check that it's all working.

This would be the safest, with least downtime if it goes awry!

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Fri, 21 Apr 2023 11:47:07 GMT

Secondary Connect isn’t relevant if that’s your goal.
What you probably want is Multiple Entry Point (MEP).
See: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_RemoteAccessVPN_AdminGuide/Topics-VPNRG/MEP.htm

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Fri, 21 Apr 2023 14:39:30 GMT

Is it necessary to use MEP?

Can we keep it simple and not use MEP?

Thanks.

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Fri, 21 Apr 2023 16:14:33 GMT

The only way you can have multiple gateways managed by the same manager serve the same encryption domain is with MEP.

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Fri, 21 Apr 2023 20:47:06 GMT

This is defined in trac_client_1.ttm and is the most appropriate place to check this.
Your approach for testing this seems appropriate.

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Mon, 24 Apr 2023 10:50:37 GMT

For MEP. The description says the three methods/options are:

First to respond
Primary/Backup
Random Selection

We want to use the other site as a backup site, but it's on a different LAN (connected by an MPLS Intranet), to a different internet connection provided by a different ISP.

The most appropriate method looks to me to be the Primary/Backup option. However, having the set up as above, we would like users to manually select the other site, should the primary site go down. The above system would need DDNS or something?

Or the internal probing will push the user to the GW at the other site automatically, i.e:

Even if the user only has siteA.acme.com configured as a site on their machine, it will push them to siteB.acme.com automatically if SiteA is down?

We would rather do it manually (i.e. create 2 sites for the users). If we do do it manually, should we disable MEP?

Currently, we seem to be experiencing the symptoms described in this SK:

https://support.checkpoint.com/results/sk/sk78180

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Tue, 25 Apr 2023 03:06:18 GMT

Unfortunately, a "site" refers to a management domain, not a gateway.
Which means both gateways will show up on your clients when you add one of them.

MEP may not actually be needed here, upon further reflection.
Both gateways need to have the same encryption domain, obviously.
Do they have different Office Mode pools assigned?

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Wed, 26 Apr 2023 14:30:47 GMT

Sorry, I did reply to this on Tuesday, but seems I didn't hit submit to send the message.

Yes, both GWs have separate Office Mode pools.

The primary one has Office Mode pool IPs from the HQ LAN

The new one has Office Mode pool IPs from the branch LAN

We need users who connect to the Branch GW via VPN to be able to access resources on the whole intranet including at HQ

We need users who connect to the HQ GW via VPN to be able to access resources on the whole intranet including at the Branch.

The intranet is connected via an MPLS network.

Thanks.

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Wed, 26 Apr 2023 18:21:00 GMT

As this discussion is clearly unrelated to the original thread this appeared in, I created a new thread and changed the subject.

Regardless, what can you see on the gateway side when the user connects?
Are there any log entries related to the user when the connect?
Have you done any tcpdumps or similar to see if the traffic from the relevant users makes it in/out of the gateway?

Re: Two Gateways Serving the Same Encryption Domain

RS_Daniel — Wed, 26 Apr 2023 19:59:37 GMT

Hello,

We use that configuration with many customers. General steps: disable secondary connect, and disable mep. For second step you can check https://support.checkpoint.com/results/sk/sk78180

With that configuration we are able to connect to each gateway independently. No Active/Backup, no conflicts with encryption domains, they are separeted remote access gateways.

To verify trac_client file you can use this command: vpn check_ttm <trac_client_1.ttm location>

Regards

Re: Two Gateways Serving the Same Encryption Domain

the_rock — Thu, 27 Apr 2023 01:09:05 GMT

Good point. All that is also listed below:

https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_RemoteAccessVPN_AdminGuide/html_frameset.htm?topic=documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_RemoteAccessVPN_AdminGuide/164758

Re: Two Gateways Serving the Same Encryption Domain

garrod — Thu, 27 Apr 2023 08:22:54 GMT

Interesting Discussion here, a definitely MUST have features in Check Point future RFE inside SmartConsole

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Fri, 05 May 2023 07:56:05 GMT

Sorry for the delayed reply. As a new thread was created, I didn't get the email notification.

...So since the last message, I have disabled MEP and Secondary connect.

The original GW VPN is working fine now, even though I add the new GW to the same RAC.

When I connect to the new GW VPN, if I don't add allow rules to the policy then I can see the packets drop in the logs.

However, when I add allow rules to the policy, the drop logs disappear and are replaced with:

tunnel_test (udp/18234) - Decrypted in community RemoteAccess - Implied Rule

However, no traffic passes, all ping/trace tests fail (rules added to allow ICMP).

I'm at a loss now and have no idea where to look.

Thank you.

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Fri, 05 May 2023 22:24:02 GMT

Did you do a tcpdump on the other gateway to see if traffic actually gets there?
In any case, a TAC case is probably warranted here: https://help.checkpoint.com

Re: Two Gateways Serving the Same Encryption Domain

PointOfChecking — Tue, 16 May 2023 07:22:25 GMT

Thanks, I disabled Secondary Connect and MEP still no luck.

I ran the VPN check on all three trac_client_1.ttm files in below locations:

/pfrm2.0/config1/fw1/conf/trac_client_1.ttm
/pfrm2.0/config2/fw1/conf/trac_client_1.ttm
/pfrm2.0/opt/fw1/conf/trac_client_1.ttm

all report back OK:

Summary for the file: trac_client_1.ttm
result: the file passed the check without any problems

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Tue, 16 May 2023 07:48:36 GMT

I'm certain the traffic is reaching the GW because when a packet is blocked it shows up in the tracker. However, once I add the rule to allow the packet then it would change to:

tunnel_test (udp/18234) - Decrypted in community RemoteAccess - Implied Rule

For example, if I try to access an FTP server on the LAN and the rule does not exist, it will show:

From - TO - port -rule

VPN client - FTP Server - 21 -cleanup rule

once I create a rule to allow the packet, then I will see:

From - TO - port - description -rule

VPN client - GW public IP - tunnel_test (udp/18234) - Decrypted in community RemoteAccess -cleanup rule

I've already raised a ticket with TAC over a week a go, but no response. I've got in contact with Checkpoint Account manager, but waiting for a response to that as well.

In the mean time, from the tracker log result above, any idea why?

Thanks.,

Re: Multiple Remote Access Communities (GW Version?)

PhoneBoy — Tue, 16 May 2023 21:55:51 GMT

If it's hitting the cleanup rule, it means there's no matching rule in your rulebase to accept the traffic.
The rules would have to be written in terms of the unencrypted traffic (i.e. what the gateway sees after removing the IPsec headers, etc), possibly matching the RemoteAccess VPN community.

Re: Multiple Remote Access Communities (GW Version?)

PointOfChecking — Wed, 17 May 2023 08:13:35 GMT

Sorry, I realized my table was incorrect.

Thanks, yup I agree with that. When I saw the traffic hit the cleanup rule, I immediately added the rule to allow it.

Once I allowed it, then it no longer hit the cleanup rule, but instead started showing the below hitting the Implied Rule

BEFORE:

From - TO - port -rule

VPN client - FTP Server - 21 -cleanup rule

AFTER:

From - TO - port - description -rule

VPN client - GW public IP - tunnel_test (udp/18234) - Decrypted in community RemoteAccess -Implied Rule