Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
BorisL
Contributor

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
Chris_Atkinson
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
PhoneBoy
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

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
BorisL
Contributor

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.

BorisL
Contributor

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
PhoneBoy
Admin
Admin
tcpdump is accessible in expert mode from the CLI.
0 Kudos
G_W_Albrecht
Legend
Legend

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

Chris_Atkinson
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

BorisL
Contributor

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
Chris_Atkinson
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
BorisL
Contributor

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

Btw, are you talking about slow RDP connection ?

BorisL
Contributor

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

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
BorisL
Contributor

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

No Threat Prevention issues detected or logged.

 

0 Kudos

Have you tried to temporarily disable SecureXL ?

0 Kudos
BorisL
Contributor

No. I have not. 

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

 

Thanks to all.

0 Kudos
BorisL
Contributor

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

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

0 Kudos

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
BorisL
Contributor

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

Tom_Hinoue
Collaborator

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.

BorisL
Contributor

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
BorisL
Contributor

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
BorisL
Contributor

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

 

capsule.jpg

Chris_Atkinson
Employee
Employee

Glad it helped 🙂