Dismal performance of RA VPN on VSNext

[Alex-]

R82T91, Entreprise-level appliances, KPPAK.

We have successfully converted a ClusterXL to ElasticXL and everything works like before in terms of Internet access, lateral networks and the like.

Only, the RA VPN performance is now absolutely abysmal, this wasn't the case on ClusterXL. We're talking like 10-20% of what we used to have before that switch. The Endpoint VPN client is up to date.

We've checked the various SK, made some debugs, packet captures and the like, reviewed the whole architecture but nothing is out of the ordinary. The VS itself is in normal range of resource usage and has a more than enough of CPU's allocated give the size of the appliance. There's never a connection issue, the VPN stays connected, it's just the throughput which is very low.

We will open an SR, I'm just looking if there are any good tips and tricks here given it's our first VSNext and RAVPN.

[Chris_Atkinson]

How did you convert as such...

On the previous cluster were there any MTU or MSS clamping configs that might not have come across?

[Alex-]

We took a weekend with service interruptions to switch to Elastic, so it was more of a reinstall than conversion.

No specific configurations were present in the ClusterXL as it worked fine out of the box.

[Timothy_Hall]

1) Is the performance issue for all RA VPN traffic or just large-packet connections like file transfers?  Under SmartView Monitor...Users, are the clients using TCPT (Visitor Mode) or NAT-T?  You could try forcing them to Visitor Mode, which is mostly immune to low MTU performance issues due to the use of TCP: sk107433: How to change transport method with Endpoint Clients

2) Be sure that the encryption settings for Remote Access VPN IPSec Phase 2 did not get locked back to 3DES/SHA1 as part of the conversion in the Global Properties under Remote Access...VPN Authentication & Encryption...Encryption algorithms...Edit...IPSec Phase 2.

3) Not sure if this applies to you, as it is a known limitation for R82.10, but worth a look:

In VSX mode, when running performance tests at higher CPS (Connections per second) across different sources and destinations, the Security Gateway will experience drops because that source-based routing is enabled in VSX mode by default.

• To resolve: Disable source-based routing to reduce the number of cache entries created and deleted during CPS test and improves the performance. Run: 
  fw ctl set -f int cphwd_enable_ecmp 0 -a

[Alex-]

Anything beyond a ping is slow. All traffic is tunneled through the gateway so plain browsing or an WinSCP from a client to the gateway itself (to limit the test path to the IPSEC tunnel) aren't great.

The algorithms were double-checked, they were already on AES since it's the same SMS than when it was ClusterXL and we took care of switching then.

Interesting point for the Visitor Mode, this isn't something we considered - I will check this with the customer and provide an update.

[Alex-]

Unluckily Visitor Mode doesn't change the situation either way.

We will follow-up with TAC.