Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Poor SSL VPN performance when using TCP

Hello folks,

 

i am pretty disappointed with the SSL VPN performance on TCP connections. When using TCP i only get ~16 Mbit/s when copying files over SMB. With UDP the performance is much better and i get the full 50 MBit/s. This is not acceptable at all, since i always got the full performance with UTM on even slower hardware and i need to use TCP on some sites. I've tested this on multiple appliances with our customers (XG210, XG125, XG115 etc.) and it's always the same: TCP performance on SSL VPN is plain bad and there is no heavy load on the CPUs involved.

 

Is this a bug, or is the TCP SSL VPN performance really that bad compared to UTM?



This thread was automatically locked due to age.
Parents
  • 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.

  • Interesting. 

    Could other try the same? 

    De install the current openVPN (Sophos SSL VPN), install Sophos connect 2.0.

    https://community.sophos.com/products/xg-firewall/sfos-eap/sophos-connect-eap/b/announcements/posts/sophos-connect-2-0-early-access

    Import the OpenVPN File (you can download this file in User portal as "Configuration file for other os"). 

    Feel free to post your results with Sophos Connect. 

     

     

     

    Feel free to compare both Logs (Sophos Connect and OpenVPN). you see all the Push Requests by XG. Do you see any difference? 

    Maybe compare the Sophos TAP Adapter/Interface configuration. As you can view the device on Windows, you should be able to see the MTU size etc. 

    __________________________________________________________________________________________________________________

  • Can't we compare something from UTM too? I have access to at least two appliances with connections that have 53 Mbit/s upload, just tell me what to look for.

  • To use a UTM would be to compare a OpenVPN Server. Basically a different platform. You can compare the pushed mechanism, of course. 

    Using the same client with different OVPN, you could compare the pushed mechanism, but the results wouldnt be the same, as the server platform is "different". 

    Still not clear, if this is caused by the Client or the server platform: So if the platform is causing this, this comparison would not help. If the client caused this performance, a comparison could help. 

    You should simply compare the OVPN Logs of both appliances on the Client. What will you get by XG / UTM. If one is pushing a option more / less, this could be the cause of this performance issue. 

    But i would rather recommend to use Sophos Connect 2.0 and test it with XG. Compare the values and report back, if you see a difference or not. 

    __________________________________________________________________________________________________________________

  • I uninstalled openVPN and installed the new SC2, but still the old slow results with 12/8 MBits. ;-(

  • LuCar Toni said:
    Feel free to compare both Logs (Sophos Connect and OpenVPN). you see all the Push Requests by XG. Do you see any difference? 

    In push requests I don't see any difference.

    The main difference from both clients is the TAP driver, they are completely different versions. And of course, the OpenVPN Version on both of them are different, together with openssl. SC 2.0 uses a much newer version.

    LuCar Toni said:
    MTU size

    Looking at the drivers options the SC 2.0 EAP had an MTU of 1400 while the OpenVPN Client from the User Portal had an MTU of 1500.

    Is there any more information needed?

     

    Thanks!


    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v20 MR1 @ Home

    XG 115w Rev.3 8GB RAM v19.5 MR3 @ Travel Firewall

  • To get back to  as he is one of the only person in this thread getting more Performance through the tunnel with a windows Client. 

    Could we get insight of this Windows Client? Which Version is windows running? How many interfaces (plus virtual) interface are running? 

    Still stuck my head in the differences between Unix and Windows in handling this Session, because Linux overall seems not have any issue with the configuration at all. 

    So it seems like something on Windows limits the download performance but not all Windows Clients. 

     

    Spend some time to regenerate the certificates used by XG with different algorithm. Because likely we moved forward in XG as the used algorithms. So the used certificates on UTM could differ from a XG installation in case of algorithm used. (In V18 you can use stuff like Elliptic curve).  

     

     

    Dumped this traffic but it looks like there are no Retransmissions or anything else, as indicators for performance degenerated factors. 

     

    So currently, if i recap this Thread: Nobody but  gets better throughput with Sophos Connect on Windows. Did somebody test other OS right now? Something like iOS/Android? 

    Config File can be exported and send via Email. Both platform have openVPN in their Appstores. 

    __________________________________________________________________________________________________________________

  • Can we change the cryptographic settings and test again?

  • No issue at all ins't quite right. He said: "I've tried out on Linux machine with the latest version of OpenVPN, I've got 120Mbit/s over a single connection with TCP. (Still a lot slower than UDP.)"

  • Could we get insight of this Windows Client? Which Version is windows running? How many interfaces (plus virtual) interface are running? 

    This is from the laptop I've used to test it today.

    Windows 10 Home 2004

     

    Interfaces:

    Realtek 8168

    Qualcomm Atheros QCA3977

    Sophos TAP Adapter // Used by Sophos Connect 2.0

     

     

    I've regenerated the certificate with this Elliptic curve, and hash.

    And here's the crypto settings for the SSL VPN.

     

    Got the same results as before, TCP over the client that's available on the User Portal is stuck at 14-16Mbit/s while I can push 70-90Mbit/s on SC 2.0 EAP with TCP. (Sorry, this test has done before I managed to get home, did on bad wireless.)

     

    Still stuck my head in the differences between Unix and Windows in handling this Session, because Linux overall seems not have any issue with the configuration at all. 

    On Linux with the same setup with TCP and OpenVPN 2.4.9 I can push the same throughput than Sophos Connect 2.0 EAP with TCP.

    But still a lot slower than UDP, which on both situations (Linux or Sophos Connect 2.0 on Windows) can push 300Mbit/s over a single client and connection.  Which It's only limited by the CPU my XG is using, (and also AES-NI not being available on the Software Version.)

     

     

    Here's a TL;DR about throughput on my XG.

     

    Windows 10 2004 with SSL VPN TCP;

    OpenVPN Client from the User Portal = 14-16Mbit/s limit

    Sophos Connect 2.0 EAP (On Wired) = 120Mbit/s limit.

     

    Windows 10 2004 with SSL VPN UDP:

    Sophos Connect 2.0 EAP (On Wired) = 300Mbit/s, with peaks to 320Mbit/s.

     

    Linux Kernel 5.7.2 with OpenVPN 2.4.9 over TCP = 120Mbit/s (Same as Sophos Connect.)

    Linux Kernel 5.7.2 with OpenVPN 2.4.9 over UDP = 300Mbit/s, with peaks to 320Mbit/s. (Same as Sophos Connect.)

     

    The main issue here on the slow network comes from the OpenVPN client that is available on the User Portal, and at the same time on SC 2.0 and Linux It still 1/3 the throughput of UDP.

     

    EDIT: Sadly I can't do further testing since my ISP is dead right now.

    Thanks!


    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v20 MR1 @ Home

    XG 115w Rev.3 8GB RAM v19.5 MR3 @ Travel Firewall

  • It's interesting that you get better results with Sophos Connect, since i'm getting exactly the same results as with the OpenVPN Client.

Reply Children
  • So we would have to catch up on the 16 mbit/s difference to  120 mbit/s. 

    I found something, which could be the root cause, needs to be analysed for now. 

    __________________________________________________________________________________________________________________

  • Hi,

    i was linked to this thread.

    I have several users with Windows 10 / 1909 and they use direct Access (HTTPS) to internal servers (no problem).

    I formy self use Sophos VPN Client to connect to a XG 17.5.MR12 and i dont´have any perf. problems (not realy).

    But

    I have one user in Phoenix USA with high WAN latency (about 200ms average) with a performance drop to 355kbit/s.
    He uses a Cable Modem with about 60-100MBit.

    It doesn´t matter if he uses Sophos VPN or Microsoft Direct Access (always slow with 355kbit/s).
    This is slow with SMB File Access.

    The server are located in germany.

    is there any change that the WAN latency could be a problem with TCP / UDP? 

  •  

    atop:

    NET | tun0 1578% | pcki 29337 | pcko 57619 | sp 10 Mbps | si 2428 Kbps | so 157 Mbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0

     

    Looks better to me.

     

    Could you please try following:

    Within the config file: 

    resolv-retry infinite
    nobind
    sndbuf 0
    rcvbuf 0
    persist-key

     

     

    If this does not help after reimporting the config file, there is a second change needed on XG. I just want to know, if this Client config change helps or not. 

    This is currently under investigation. 

    __________________________________________________________________________________________________________________

  • 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  

    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.