CHiLL Posted December 17, 2018 Posted December 17, 2018 (edited) I have configured a virtual 2019 server with Microsoft's Always-On VPN and it is working - however it is a bit slower than I was expecting. When connected at home, I am transferring/downloading a video file from the on-site network file server to the local C:\ drive of the laptop at my home at approximately 2MB/s (16Mb/s). Whilst this is fine for general use for users to access/edit documents, SIMS, etc...it's not great if they're working on larger files like PowerPoints with embedded videos. I pretty much followed this guide: https://4sysops.com/archives/always-on-vpn-directaccess-for-windows-10/. School Internet connection: 100Mb/100Mb over 1Gb pipe Server network connection: Virtual 1GbE adapter VPN Tunnelling: Split Tunnel Home Internet connection: ~30Mb Sky Fibre Unlimited Laptop spec: Basic Stone NT310 (fairly old) but with a Kigston A400 SSD. I can confirm that I can max out both the school's 100Mb and home 30Mb connections with other types of download, so this appears to be related to the Always-On VPN connection, though I'm not sure how. Edited December 17, 2018 by CHiLL
SaintSide Posted March 24, 2019 Posted March 24, 2019 If it's any help I've had thoughput issues with Always-On since moving away from Direct Access. I moved to Pritunl on a CentOS 7 VM with LDAP, it's been running great and doesn't seem to have any latency/bandwidth issues.
forkies Posted January 31, 2020 Posted January 31, 2020 Sorry to revive this thread. We are just implementing always on vpn through RRAS, moving from Smoothwalls SSL VPN client. Initial testing of both IKEv2 and SSTP are giving me shockingly slow performance, copy speeds from network drives at about 3MB/s. I have done a lot of testing using different connections and not getting higher than 4MB/s. On the Smoothwall SSL VPN connection I could get 10MB/s so thought I would have at least the same. Would be interested to hear what speeds others are getting and if I can do anything to improve the speed I am getting. Also, how many clients people have connecting on one server, the server specs and how much CPU usage they are seeing on the server when copying large files with one client. TIA, Tom
jtotheb Posted January 31, 2020 Posted January 31, 2020 UDP flood protection absolutely killed the AOVPN IKEv2 throughput, especially SMB traffic, with a Sophos UTM. A to/from exception got it up to what we'd expect to see.
chaplic Posted January 31, 2020 Posted January 31, 2020 Is it the always on VPN, or SMB access (and it is a NAS or a windows fileserver). SMB1 access with higher latency is poor - it doesn't matter the bandwidth. Have you got a webserver to test a download from?
forkies Posted February 3, 2020 Posted February 3, 2020 UDP flood protection absolutely killed the AOVPN IKEv2 throughput, especially SMB traffic, with a Sophos UTM. A to/from exception got it up to what we'd expect to see. Thanks, I can't see any option for this on Smoothwall and I have the port forward setup with the relevant ports to connect. Nothing showing in logs to suggest it is taking any mitigating action. I will keep researching to see if anything on Smoothwall related.
forkies Posted February 3, 2020 Posted February 3, 2020 Is it the always on VPN, or SMB access (and it is a NAS or a windows fileserver). SMB1 access with higher latency is poor - it doesn't matter the bandwidth. Have you got a webserver to test a download from? It is always on VPN device tunnel and user tunnel (tried seperately) using IKEv2 and SSTP fallback option seems a bit slower. Connecting to a windows server 2012 r2 file server, but have tried a few different servers and desktops copying files. pinging I am getting mostly 4ms pings. We have SMB1 disabled. I will try doing a download from the internal web server and let you know how that goes.
russlp Posted March 5, 2020 Posted March 5, 2020 Hi @forkies, Did you have any luck with this in the end? We are having similar issues here :/
forkies Posted March 5, 2020 Posted March 5, 2020 Hi @forkies, Did you have any luck with this in the end? We are having similar issues here :/ Nope. Decided just to give access for a few people anyway so not major but will probably look to run it through our firewall again instead as that used to give us good speeds. Shame but don’t have time to do more work on it for the moment. 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now