Speed up connection process

[Martijn]

Hi all,

Are there settings or options we can change to speed up the connection process of a VPN client?

One of our customer uses RSA SecurID as authentication method and it takes about 20 seconds before the gateway decides to authenticate against this RSA server. We tested this and see the UDP 5500 packet leaving the gateway after about 20 seconds and at the same time we see the user in the RSA log.

What takes place in those 20 seconds before authentication? We see the VPN packets entering the gateway right after clicking the Connect button, but then we have to wait for the real authentication.

A check for a site update is taking place, but is there also a certificate / CRL check?

What else is being checked and how can we speed up those processes?

Regards,

Martijn.

[G_W_Albrecht]

Please elaborate which kind of RA VPN your clients are using for connection ! See sk67820: Check Point RemoteAccess Solutions  for different RA VPN methods.

[Martijn]

Hi,

Customer uses Endpoint Connect VPN client. E82.X at the moment, but E81.X has the same 'delay'.

Martijn

[G_W_Albrecht]

The Endpoint Connect R73 client is completely legacy - so i would assume either Endpoint Security VPN or Endpoint Security Client is used. But newest version is E81.30 - so the E82.x seems strange. 

But no matter which version, it would surely help to do a RA  VPN debug to see how VPN is established. Also it may be interesting to look where in the rule base this connections are allowed.

[FedericoMeiners]

Martijn

First of all it would be a great idea to actually be sure that the issues are generated by the VPN. It happened to me a lot of times where a customer blames the VPN or the appliance, but after performing a tcpdump / fw monitor analysis we could verify that the latency was from the server site.

Is the RSA Authentication server on the same network as the VPN Firewall?

If you go through SSL VPN you still have latency issues?

Basically what you want to check by performing a TCPDUMP / FW MONITOR is to check where is the delay:

Check the incoming request and the respective time (i, I, o O) and then check if the reply from the server is delayed or not. You may need to turn of SecureXL to perform this test correctly.

If you have ruled out that it is a VPN issue then it would be a good idea to check if the issue persist when using the SSL VPN, you will need the Mobile Access for this to work.

Finally I have faced some issues of VPN with s2s tunnels and remote access latency due to clamping, you can check sk90200 and sk98074, generally with the kernel parameter is enough.

Hope it helps,

Federico Meiners

[FedericoMeiners]

Also, may I ask which version are you running on the firewall / management server?

By re reading your post again I'm asking myself if the VPN is the real problem here or if it's something with the firewall, I mean, you did see the packets getting in in a timely manner but you have the delay on the outgoing part. Is there any chance to try authentication from a different subnet that goes through the firewall to check if the same behavior applies?

[Timothy_Hall]

You have something wrong/misconfigured in your LDAP setup.  SecurID/RADIUS/TACACS authentication methods are accessed through an External User Profile object (formerly known as the generic* user), which is always checked after the local user database then LDAP, and this order of operations cannot be changed.  See this screenshot:

When no match is found for the user login name in the local user database, all defined LDAP Account Units (AUs) are queried simultaneously.  They must all respond before the authentication process can move on to External User Profiles and SecurID, or the above timer must be reached.  The most common cause of this is an old or invalid AU specifying servers that are unreachable or no longer exist, if you clean up those old AUs the delay should go away.  If you only have one AU and it appears to be valid, check the defined servers for that AU object and make sure they are correct and reachable.  The delay you are seeing is not normally caused by an LDAP credentials issue since that results in a quick failure; the delay is normally caused by unreachable or invalid LDAP servers defined somewhere in an AU configuration.

If you can't delete the old AUs for some reason, on the above screen you can configure a firewall to query only certain AUs and ignore others (or maybe even shorten the timer), but the best long-term approach is to clean up your AU configuration and/or servers definitions.

[Martijn]

Hi,

The LDAP query time out put us on the right track.

On the gateway in Remote Access -> Authentication we configured SecurID as Authentication method. But the User Directory selection was Automatic.

We changed this to External User Profiles only and now the gateway is performing SecurID right away. Client now connects within 10 seconds.

Regards,

Martijn.