Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nickel

1550 VPN establishment delay

Jump to solution

Some users observe that when connecting to VPN (from Capsule on Windows or IOS in our case), there is a delay until they can reach internal resources. They have to wait between 15 seconds and half a minute until they can reach devices with the allowed protocols.

Has anybody else experienced this problem?

 

1 Solution

Accepted Solutions
Highlighted
Employee++
Employee++

 

For iOS setting the "tunType" custom data value to force snx (SSL) may improve the delay in cases where the client might be attempting IPSec first for example and failing.

Refer: http://supportcontent.checkpoint.com/documentation_download?id=20361

View solution in original post

25 Replies
Highlighted
Admin
Admin
It does take some time for the VPN to negotiate and connect.
How precisely are you measuring this?
Have you done any tcpdumps to see what's going on?
0 Kudos
Highlighted
Platinum

What about Endpoint Security VPN client ? It has a nice progress window where you can see which phase of VPN establishment takes the most time. Usually that is the one where topology is downloaded from gateway if needed.

0 Kudos
Highlighted
Nickel

Also happpens with Endpoint Security Client. The delay occurs after negotiation is complete.

The other strange thing is that this does not happen for all connections. Some connections (few) get immediate connectivity.

Highlighted
Nickel

I have not performed any measurements. Basically user experience being reported. And my own.

Also, as mentioned in other reports, it does not happen very time. Some connections get immediate connectivity.

How do I get a tcpdump on a 1550? 

0 Kudos
Highlighted
Admin
Admin
tcpdump is accessible in expert mode from the CLI.
0 Kudos
Highlighted
Sapphire

I would instantly involve TAC using chat if there is a good chance to replicate the issue in a quick RAS !

Highlighted
Employee++
Employee++

 

For iOS setting the "tunType" custom data value to force snx (SSL) may improve the delay in cases where the client might be attempting IPSec first for example and failing.

Refer: http://supportcontent.checkpoint.com/documentation_download?id=20361

View solution in original post

Highlighted
Nickel

Hi Chris.

I will test this creating an iPhone profile to add the setting.

Nevertheless I must note that:

- the delay in accessing internal devices occurs after negotiation is over and "connected" status is presented by the client.

- users have also reported the delay using Windows 10 Capsule and Enpoint Security from Mac, so it does not seem to be specific to IOS, but rather to the 1550.

- we have no reports on this delay when connecting to R80.10, R80.30 or R80.40 open servers 

 

Thanks.

 

0 Kudos
Highlighted
Employee++
Employee++

Thanks for clarifying, please test the latest build of R80.20.05 if not already and engage TAC to assist further.

0 Kudos
Highlighted
Nickel

We had a very bad experience with TAC (Premium Support) in previous issue with 1550, so I prefer to wait and test available recommendations posted here.

Users will have to live with the short delay (sometimes a couple of retries connecting to their device) in the meantime.

Thanks again and best regards.

 

0 Kudos
Highlighted
Platinum

Btw, are you talking about slow RDP connection ?

Highlighted
Nickel

The problem is with the first connection attempts failing to any device independently of protocol (RDP, http, https or vnc). Once connected speed and latency are fine with all protocols.

0 Kudos
Highlighted
Platinum

I am asking because recently I had a problem with my 1470 where RDP will connect instantly on WAN interface but very slow on DMZ interface. 

I guess you have already eliminated possible sources of delays such as TP blades ?

0 Kudos
Highlighted
Nickel

These are VPN connections from Internet (WAN) to intranet.

No Threat Prevention issues detected or logged.

 

0 Kudos
Highlighted
Platinum

Have you tried to temporarily disable SecureXL ?

0 Kudos
Highlighted
Nickel

No. I have not. 

I will have to leave this issue alone for a while.

 

Thanks to all.

0 Kudos
Highlighted
Nickel

Yes. Disabling SecureXL seems to solve the issue.  TAC also suggested we do that.

Question is: what is the performance hit for not using SecureXL?

 

0 Kudos
Highlighted
Platinum

It depends. Paste 'fwaccel stats -s' with SecureXL enabled to check it.

0 Kudos
Highlighted
Platinum

Btw, leaving SecureXL disabled is only a workaround and shall be temporary solution, not permanent one. You should really involve TAC for this and escalate if not satisfied with how is the problem handled. Especially if you have Premium Support. 

0 Kudos
Highlighted
Nickel

Thanks.

I had to revert back from R80.20.05 as we started to get a "violated unidirectional connection" errors on many outbound connections.

Now back with R80.20.02 which seems to be stable. Not willing to spend more time as Checkpoint debugger with this appliance..

Highlighted
Copper

Have you checked this SK that might relate to your symptoms?

Connections through port forwarding or from VPN to 1500 are slow when SecureXL is enabled
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...


We had issues with S2S-VPN between two 1500 appliances where CIFS connections get stuck with SecureXL enabled.
Workaround for us was to either turn [vpn accel off] or, turn whole SXL off. 

Issue is scheduled to resolve in R80.20.10, but I believe there is a hotfix over R80.20.05 that includes the kernel parameter to be optimized value from the first place.

Highlighted
Nickel

Hi Tom,

We upgraded to R80.20.05 (1229) but started having other problems with outbound connections (“violated unidirectional connection” errors). So we reverted back to R80.20.02 (936) and will disable SecureXL. After that, staty put for a while until we find the next bug.

Thanks and regards.

 

0 Kudos
Highlighted
Nickel

In another thread I was told to test changing the IOS Capsule tunnel type from IPsec to SSL.

After a few initial tests, this seems to solve the problems accesing internal devices (delayed availability or no availability).

The previous problem we had with R80.20.05 (1229) was not caused by the version but by the fact that TAC had suggested to turn off SecureXL.

We are now running again R80.20.05 (1229) with normal configurations and using SSL tunnel type in Capsule.  I will post again in a few days if solution is stable.

 

0 Kudos
Highlighted
Nickel

It was very simple and I had not seen it at first. In the settings of the IOS capsule connection.

 

capsule.jpg

Highlighted
Employee++
Employee++

Glad it helped 🙂