Two Gateways Serving the Same Encryption Domain

[PointOfChecking]

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)

[PhoneBoy]

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

[PointOfChecking]

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!

[PhoneBoy]

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/T...

[PointOfChecking]

Is it necessary to use MEP?

Can we keep it simple and not use MEP?

Thanks.

[PhoneBoy]

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

[PointOfChecking]

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

[PhoneBoy]

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?

[PointOfChecking]

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.

[PhoneBoy]

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?

[PointOfChecking]

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.

[PhoneBoy]

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 

[PointOfChecking]

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.,

[PhoneBoy]

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.

[PointOfChecking]

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

[PhoneBoy]

Have you tried any further debugging with fw ctl (z)debug to see where the packets might be getting dropped?
You might also look at our new easy_debug script that should help (not sure when we added this, but it is in R81.20).

[PointOfChecking]

what am I looking for in fw ctl zdebug?

Running that command doesn't seem to return anything substantial.

We're using R80.20 on the 1800.  but seems the "easy_debug script"  must be created via "TAC Debug" web GUI, available for Check Point Internal users.

[the_rock]

Here is simple example. Say, for argument's sake, you want to filter for IP 7.8.9.10 and/or port 445, below is the command:

fw ctl zdebug + drop | grep 7.8.9.10 | grep "445"

HTH

Andy

[PointOfChecking]

Thanks will try that and report back.

[the_rock]

Sounds good, keep us posted.

Andy

[PointOfChecking · Accepted solution]

The sk118796 states that SMBs cannot do SCV.  The work around is to remove the SMB from any RemoteAccess community rules.

Thanks @PhoneBoy  and @the_rock 

There are other niggly issues which need to be resolved, but at least this thread can be closed 🙂 Thanks again.

[PointOfChecking]

Hi,  running the command shows the below:

"kfunc not supported".

I've found this article, and going through it now.

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

Thanks.

[the_rock]

I assume sk fixed it for you then?

Andy

[PointOfChecking]

It fixed that problem, but opened another can of worms.

I'm going to work through those and if any issues, I'll probably have to come back to you guys 🙂

Thanks again.

[the_rock]

O s***...what happened? Hope its not a bad problem that arouse?

Andy

[PhoneBoy]

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

[RS_Daniel]

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

[the_rock]

Good point. All that is also listed below:

https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_RemoteAccessVPN_AdminGuid...

[garrod]

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

[PointOfChecking]

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