Poor SSL VPN performance when using TCP

Shouldnt be the case, as i tested it with Sophos Connect 2.0 back in the days on multiple devices. 

Do you use Compression on SSLVPN? 

Did you try Sophos Connect 2.0 or the OpenVPN Client? 

Did you only try SMB? Can you try other protocols, as SMB can actually cause such problems (re transmissions). 

Likely caused by MTU Issues: https://forums.openvpn.net/viewtopic.php?t=25039

I really need this to get sorted out, otherwise we will stop deploying XG firewalls to our customers. Since it has nothing to do with SMB and SG Firewall is using the very same MTU size, it should be something else going on.

I added the two parameters to my config file. Unfortunately it makes no difference at all, tried with the OpenVPN Client and the Sophos Connect 2.0 Client.

Edit:

I tested this now with android. I tested UDP, TCP and TCP edited with the parameters you mentioned. The results are roughly the same as with Windows:
TCP: 8-10 Mbit/s
UDP: 35-45 Mbit/s

hi LuCar Toni 

Tried with your 2 params and no difference at all, exacly 16Mbit/s using TCP.

(windows 10 / openssl / XGvirutal v18 MR1 hosted on gigabit link)

Thanks for the feedback.
Please give Sophos some time to review the test scenario and the different perspectives. 

As far as i know, Sophos has a RootCause of this issue and will look into fixing this in a upcoming release. 

I've just compared the OpenVPN Client logs from UTM and XG. Those are the differences i've found.

Why is XG only using TSL v1 while UTM is using TLS v1.2?

Where do i find these config file on the Windows 10 client PC?

I had a second user today (in Dortmund/Germany).
He uses WLAN and MS Direct access.

Due to latency his SMB downloads is about 355-800kbit/s.

I don´t think that this something that a VPN client could fix.

I read some threads about mtu size and tcp autoscaling with MS DA Servers on Hyper-V ...

I'd suggest you open your own thread, since this has nothing to do with this topic.

Thas right,

but even with Sopos VPN Client the error is the same.

I had a own thread and was directed here.

Hi,

I redirected you because your original post was about a VPN user, now you have changed to being W10 users in your office.

Ian

Just to update this thread. I would ask everybody with a valid Support Subscription to open a Case referring to this Thread, if he has this issue. 

Properly this will be resolved in the next bug fix version - So i will mark this Answer as a Answer. 

When I get back into the office on Monday, I'll pass over the details and the case that one of my clients had opened and we closed it because we found a work-around, and put it down to the OpenVPN client issues.

Like I say, we found that changing the connection method to SHA1 worked - in itself for them wasn't so much of a problem as they use encrypted traffic as per best practices throughout the network, and if Azure files can use SMB direct onto the internet, there is no reason why SMB files cannot be used with a weaker VPN as an extra layer.

When I get back into the office on Monday, I'll pass over the details and the case that one of my clients had opened and we closed it because we found a work-around, and put it down to the OpenVPN client issues.

Like I say, we found that changing the connection method to SHA1 worked - in itself for them wasn't so much of a problem as they use encrypted traffic as per best practices throughout the network, and if Azure files can use SMB direct onto the internet, there is no reason why SMB files cannot be used with a weaker VPN as an extra layer.