Thread Info
  • State Verified Answer
  • +4 person also asked this people also asked this
  • Locked Locked
  • Replies 100 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 49632 views
  • Users 0 members are here
Options
Suggested
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

Dreamcatcher

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.
  • 0 in reply to Dreamcatcher

    I am not here to explain the issue, as i am still in the process of finding the root cause of this.

    As i am trying to figure out, where this issue could sit, the first step is, to find the component, which is affected and which is not affected. 

     

     

    If you know, there is only one platform affected, you can look deeper into the config pushed to this particular OS. If all OS are affected, it is likely caused by the server platform. 

    As Linux seems to be able to handle this quite nicely, i am assuming, this could be caused by something pushed by XG to the Windows Clients and causing this. As openVPN interacts differently with the OS, there could be the Rootcause. 

    There are different OS specific values like buffer caches and kernel buffers, which could likely cause this. 

     

     

     

    On the same client, as you posted your Sophos Connect results, deinstall the SC and install the OpenVPN Client, provided by XG, will you get the same results or not? 

     

  • 0 in reply to LuCar Toni

    On the same client, as you posted your Sophos Connect results, deinstall the SC and install the OpenVPN Client, provided by XG, will you get the same results or not? 

    Stuck on 16Mbit/s as everyone in here.

  • 0 in reply to Prism

    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. 

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to Dreamcatcher

    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. 

  • 0 in reply to LuCar Toni

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

  • 0 in reply to LuCar Toni

    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!

  • 0

    The big question is why on earth would you configure a VPN connection to use TCP.

     

    If you think about the layers of network traffic, it doesn't matter if the VPN connection is UDP as the TCP connection connecting to services over the UDP VPN will take care of any issues....

     

    This gent sums it all up perfectly.

     

    www.youtube.com/watch

  • 0 in reply to BLS

    Because you can't control which ports are open on public networks like hotels, cafés etc. or company networks with guest WLAN? Ports 80 and 443 TCP will be open for sure, while i often encountered 80 and 443 UDP being closed.

     with Sophos Connect Client i get the very same results as with the Open VPN client for both, TCP and UDP.

  • 0 in reply to Dreamcatcher

    Which in itself is a good thing, my clients supply their users with mobile 4G devices, connecting to any public hotspot is a danger - just the use of a WiFi pineapple for example could be very costly to a company.