All Remote User use Visitor Mode ( Endpoint Connect VPN )

[Supporto_Checkp]

Hi
i've a question related to the use of visitor mode

we have a VS r80.30 installed on a 5900 appliance that manage vpn access for our users ( other than another VS )

we have enabled both ipsec and mobile blade, so "visitor mode" is enabled by default and cannot be removed.

Most of the users use "Endpoint Connect VPN" as a client.

with "vpn show_tcpt" , "vpn tu tlist" and using the "one liner" in previous message I see that most of them use visitor mode.

With 100 users is ok, With 340 it's a crap because is managed in "user area".

We contacted Checkpoint but it was useless.
They said the at first all the client try to use nat-t and THEN 443 and visitor mode.
But capturing traffic on both the client ( many clients indeed ) and the firewall we have evidence that Endpoint Connect VPN don't use NAT-T but goes directy with 443.

This is a fresh check of our users
REMOTE ACCESS VPN STATS - Current
----------------------------------------------------------------------
Assigned OfficeMode IPs : 181 (Peak: 181)
Capsule/Endpoint VPN Users : 179 (Peak: 179) using Visitor Mode: 177
Capsule Workspace Users : 0 (Peak: 0)
MAB Portal Users : 0 (Peak: 4)
L2TP Users : 0 (Peak: 0)
SNX Users : 0 (Peak: 8)

LICENSES
----------------------------------------------------------------------
SecuRemote Users : 45000
Endpoint Connect Users :
Mobile Access Users : Unlimited
SNX Users :

Can the behaviour written above be cause by our licences? ( Endpoint Connect Users : "" )

Too many visitor mode users cause really BAD performance,i'm talking about 800ms for a ping response, using Web Portal or the SSL Extender solve the problem but the customer don't want to use this solution.

[_Val_]

Quoting from sk105119

Visitor mode

• Visitor Mode is supported by the legacy SecureClient and by Endpoint Connect (Endpoint Security) Client.

  Each packet in Visitor Mode is processed in user space, which causes a load on CPU on Security Gateway (only several hundred Visitor Mode clients can be handled by the Security Gateway).

  In SecureClient, if enabled by the user, Visitor Mode is never automatically turned off. It is recommended that users only enable Visitor Mode when essential (typical to Airport and Hotel Wi-Fi spots), and disable it afterwards.

You can disable Mobile Access. hence forcing Endpoint Clients to use IPsec. 

[Supporto_Checkp]

we cannot disable mobile access because we have users that use it.

Also the same client ( I mean example PC and SAME version of endpoint connect )
use 443 for auth and 4500 for traffic on a physical cluster configured in the same way
BUT use visitor mode on this vsx.
We don't USE SecureClient.
We use Endpoint Connect VPN as Client or SSL Extender
and with "same configuraion" i really mean that are the same.
Each global properites,each license,each gateway setting related to vpn

[_Val_]

Basically, you are saying the following:

1. You have identical VPN config for both VSX and physical environment
2. Same Endpoint clients use ports 4500 & 443 to connect to physical, while using only 443 when connecting to a VS.

This does not make a lot of sense, to be honest. How did you check? Any traces on the client side? 

[Supporto_Checkp]

problem solved.
On the vsx cluster there was a setting changed in database , not GUI or SmartConsole ( i don't know if was a default on older version ,this DB was born with 77 or older or someone changed it )
and the transport mode was set to "Visitor Mode"
i've changed it to "Auto Detect" and now .. NAT-T! (That surely is the default on newer DB version )

+-----------------------------------------+-----------------------+---------------------+
| Peer: x.x.x.x (ae0d46b71e22993d) | MSA: 2aab11bf1040 | i: 0 ref: 17 |
| Methods: ESP Tunnel AES-128 SHA1 | | i: 1 ref: 9 |
| My TS: 0.0.0.0/0 | | i: 2 ref: 11 |
| Peer TS: 10.115.0.16 | | i: 3 ref: 5 |
| User: y.y.y.y | NAT-T | i: 4 ref: 11 |
| MSPI: 5b (i: 0, p: 0) | Out SPI: d43a4be8 | i: 5 ref: 7 |
| | | i: 6 ref: 9 |
| | | i: 7 ref: 9 |
+-----------------------------------------+-----------------------+---------------------+

[Supporto_Checkp]

i've found the solution comparing two debug of the same client after a connection to both sites.

on VSX I had

[ 2696 4196][13 May 10:36:11][CONFIG_MANAGER] transport return value Visitor-Mode, because it is Gateway config variable. Scope: site "sitename"

[ 2696 4196][13 May 10:36:11][TR_CONN_MANAGER]  ConnGetInfo: vpn conn data:
(
    :gw-ipaddr (x.x.x.x)
    :vpnd_ipaddr (x.x.x.x)
    :authentication-method (username-password)
    :is_saa (false)
    :transport (Visitor-Mode)

On Physical I had
[ 2696 4196][13 May 10:36:11][CONFIG_MANAGER] transport return value Automatic ( or auto detect , i dont' have them anymore here with me ) , because it is Gateway config variable. Scope: site "sitename"

    :gw-ipaddr (x.x.x.x)
    :vpnd_ipaddr (x.x.x.x)
    :authentication-method (username-password)
    :is_saa (false)
    :transport (Auto-Detect)

i've looked both the DB with DBGUIEDIT for some value with "auto-detect" or "visitor-mode" ...and solved 😄

[_Val_]

Correct, this is exactly the way described in sk10743. I can only guess why your VSX did not have the default method set up. It is usually the other way around, forcing Visitor Mode, if NAT-T port is closed

[Supporto_Checkp]

I don't know why, to be honest.
I didn't follow the startup of this customer many years ago.
Maybe the default setting was different on R77 ? or someone changed it for any (wrong) reason ( or maybe the old ISP didn't allow NAT-T port )  before we managed the customer
Pre-Covid19 this wasn't a problem with 100/120 user so nobody had issues.

Problem is solved but I think that an option like this should be on GUI ,and not only on DBGUIEDIT.... like many other interesting option

[G_W_Albrecht]

It is sk107433: How to change transport method with Endpoint Clients 8)

[frankcar]

Did you resolve this ? we had the same issue and turned out to be the firewall objects ip we was using was not the one which was published for our vpn user to connect, so what it was doing was hitting another external IP we have on our cluster and using visitor mode always we had to change link selection in our issue to be the external ip users was resovling our VPN host to and now all we get is NAT-T users and a few vistor mode.

CPView shows what they are connected with.

check your ip you resolve for vpn is the one that matches the link selection IP.

vistor mode has a massive impact on 700 users or more from what I remember we was fine to around 650 after that we saw issue 15600 cluster R80.20

[CheckPointerXL]

Hi all,

Is this dangerous behavoir still on going? According to https://support.checkpoint.com/results/sk/sk168297 it should be fixed

Is this true also for VSX ?

@_Val_ 

[frankcar]

I can't tell you about VSX, we  dont use checkpoint vpn they went down the zcrawler zscaler route.

articles says its fixed, vistor mode in user space was the issue if in kernel should be fine then i guess still slow compared to NAT-T

Check Point has developed a new fix to handle Visitor Mode connections in the kernel on the Security Gateway.

Frank

[CheckPointerXL]

i think your clients are tring to connect to something different from your link selection setting

the solution is here https://support.checkpoint.com/results/sk/sk32229

[frankcar]

the chaps packages our client up in applications using the wrong external IP was our issue to, so link selection changed that for the endpoint and forced it to use the main ip, probably the article you mention may have done same thing for us, we dont use Checkpoint vpn client anymore shame was 100x better than zscaler performance wise.

[_Val_]

VSX or not, Visitor mode is still the same and handled by vpnd. However, since R80.40, there is a performance enhancement, mentioned in that SK. 

What do you call "This dangerous behavior", not sure I follow

[frankcar]

This dangerous behavior ? i didn't mention that anywhere i just searched

we had performance issue in user space if its fixed it fixed.

[CheckPointerXL]

"dangerous behavior" I mean the high load overall on the system if large numers of visitor mode are connected

[frankcar]

the only high load i had was manager calling me for it to be fixed because users was struggling to download word documents when we had over 700 on visitor mode but that was in user space, if they moved to kernel must have been resolved as they say.

the vpn core was maxed out too i think from memory

NAT-T is faster than https visitor mode we found, i am not sure if visitor mode is capable of doing the same speeds as NAT-T.

[_Val_]

Visitor mode is not accelerated and treated in the User Mode by a process. By definition, it is not the most performant RAS VPn solution. For a large deployment, I would recommend the classic IPsec based VPN.

[CheckPointerXL]

according to sk168297 this is no longer true

[_Val_]

We are both correct. 🙂

As the SK mentions, you need to make sure the new fix is enabled to have improved performance with the Visitor Mode. If the enhancement is disabled, the performance with the Visitor Mode will be poor. 

[CheckPointerXL]

i tried to get that kernel value but i got error on R81.XX gateways, while i can on R80.40

so i suppose that the enhancement is enabled on R81.xx

feedback submitted to sk

[frankcar]

Solution

Check Point has developed a new fix to handle Visitor Mode connections in the kernel on the Security Gateway.

The fix is included starting from:

• Check Point R81
• Jumbo Hotfix Accumulator for R80.40 - since Take_53

Note: By default, the performance enhancement is enabled.