Mobile VPN Performance & Stability Debugging - IKEv2 vs L2TP

JethroD

Hi. Disclaimer - I am not the sys admin who setup our Firebox, but seeking some guidance & debugging steps to help figure out issues with VPN randomly disconnecting and overall speed issues. Want to know how best to debug and what to realistically expect. I do have access to Fireware Web UI.

ISSUES:
1) My VPN connection to our Office server randomly disconnects during workday.
2) Overall speed is at best lower than I imagined it would be, and at worst (during certain times of the day) pretty much unusable.

OUR SETUP
Office:

• WG M290 Firebox
• Recently updated to v12.10.3.x
• Frontier Business FiOS, static IP, provisioned at 600Mbps/600Mbps
• Connected via ethernet to Mac Mini server, mostly for file sharing

My Home:

• Spectrum cable w/ default modem & router, provisioned at 500Mbps/20Mbps
• Connected via ethernet to Mac Pro laptop running OSX 13.6 (Ventura)
• Home & Office both in L.A area, not far from each other

TESTING SO FAR
For a year or two now, I've been connecting to the Office via L2TP Mobile VPN, using built-in VPN client on Mac. But I will get randomly kicked off server out of nowhere, sometimes when doing a network intensive action (e.g., downloading or posting a file to server).

When running optimally (typically earlier in the day), overall speeds seem slower than they should be as well, but unsure if my expectations are incorrect. We use a utility called Network Speed Tester to test throughput from server to my location. There is a client app installed on our server and then on my machine to test between. The best I've been able to get is a bit over 100Mbps. But with our Office upload at 600Mbps, and my download at 500Mbps (sometimes I test up to 560-570Mbps), I just expected a bit more.

• Is something like this (e.g, 100Mbps) the best we can expect if using our Firebox for VPN?

Then, typically later in day (maybe 5-8pm or so), the speed slows to a crawl, measuring maybe 3-6Mbps. My general internet speed tests during these times still measure at over 500Mbps though (after I disconnect from VPN), so not seeing the slow down here. When connected to VPN during these times (which forces all internet traffic through VPN), the internet speed tests aren't drastically slower – maybe 200Mbps vs 260-280Mbps – but packet loss is noticeably higher, as that is typically 0% when things running well.

• Any way to debug where these slow downs are occurring and cause? One might expect it to be my cable internet, but it seems to test fine during these times.

So last week we had our Firebox firmware updated (it was a few releases old), and had IKEv2 VPN enabled. Everything I'd read stated that IKEv2 'should' be more stable and a faster connection. We also had it setup to enable split tunneling so my general internet would not be affected anymore.

But testing so far shows that when connected via IKEv2, speeds are averaging about 5-10Mbps SLOWER overall to our server than when connecting via L2TP. AND, I am getting more random disconnects over IKEv2 than I was over L2TP, typically a few per day.

• Could something be misconfigured on our Firebox to cause IKEv2 to perform worse than L2TP for VPN?

THANKS FOR ANY TIPS OR DIRECTION HERE!

james.carson

Hi @JethroD

Based on what you're describing, the speeds you're seeing are likely a combination of the following things:
-Network speed (between the two points, upload and download.)
-Protocol in use to test and/or transfer files. (this is very often SMB)
-Latency between the two points.
-Use of a full tunnel vs a split tunnel.
-What other users on the VPN are doing (10 users all trying to move files at the same time.)

-Network speed/latency: Many file transfer types require each frame be ACK'ed, often before more data is sent. This generally works fine inside LANs where latency is near zero, but over WANs latency can slow this traffic quite a bit.

-Protocol: Most office file sharing is done via SMB (if you access it in windows via \computer\share or via a mapped drive, it's very likely SMB.) SMB waits for ACKs on sent data before more is sent, meaning the slowest upload throughput is in play even if that is not the direction data is being sent. Latency also increases time between sent packets.

-Full/Split tunnel. While a full tunnel is considered more secure, each user's additional bandwidth over the tunnel must be considered. Consider a split tunnel if not all traffic needs to be sent across the VPN.

-Other users. If other users are also utilizing VPN resources, what's available to individual users will be decreased.

Please also see the KB article here:
(Why are SMB/CIFS file transfers so slow over my VPN?)
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA10H000000g33SSAQ&lang=en_US
---There is a link to a Microsoft KB that discusses changes that can be made to help with SMB performance over WANs.

JethroD

Hi. Thanks for the response. Just a few things to clarify in case it's helpful:

• I connect to our office file server via AFP, not SMB. Unsure of performance differences between them, or if similar issues. I understand SMB may be the more future-proof standard on Mac, but we had issues in past when using so holding on to AFP for now (and our server is not on a recent OS, with no plans to upgrade).

• I'm typically the only user connecting via VPN. We are only a 3 person team, with two located at the office.

• When connecting via L2TP, all web traffic must be sent over VPN (full tunnel). But new IKEv2 configuration was setup as split tunnel, so only my traffic to our server is routed. So I would assume IKEv2 traffic would be lower.

• For my testing, I'm not sure the app I use to measure speeds from server is sending over SMB. It may be more of a GUI version of iPerf, though can't verify. When testing, I am usually NOT logged on to our server, just connected to VPN.

So still wondering about the random disconnects. It seems like very often there is an almost immediate disconnect when first connecting (few seconds - minute), then next attempt is more solid. Not seeing the regular timed disconnects I was reading may be an issue with Sonoma (I'm still on Ventura). And not sure how I'd verify this conclusively, but seems like it's the VPN connection that is dropped which then, obviously, cuts my connection to server. On L2TP there is a longer delay between when I appear to lose connection to server then VPN shows disconnected. On IKEv2, it happens very quickly (so hard to see which happens first).

And still curious why IKEv2 overall speeds are measuring slower than L2TP? Could we have some settings not optimized?

When things are going well (e.g, speed tests around 80-100Mbps), it's workable. Browsing large file directories in Finder can be very slow, but I can work with it. It's more when things slow to a crawl (3-6Mbps) where I'm not able to get any work done, and Finder freezes up. But unsure how to determine source of these slowdowns.

THANKS AGAIN!

james.carson

-AFP vs SMB. Info on Apple's website (specifically their forums) suggest that AFP performs in the same manner (where it expects to see an ACK of the previous blocks prior to sending more.) FTP is a good alternative to test with if you're looking for something to compare against, as it's designed to stream across a WAN.

-Disconnects: We'd need to see logs from the firebox as well as the client in order to provide more information on those. Consider opening a support case if you'd like more information on those.

-IKEv2 vs L2TP speeds. IKEv2 likely has a more aggressive profile on your Mac likely including Diffie-Hellman (DH group) encryption. If encryption/decryption is more intensive or if the CPU on your PC is better optimized for one over the other, you'll see performance differences.

I don't know what your specific App is using to test, a cursory google search turns up a ton of speed testing tools. I would suggest checking the documentation for more info.

If you're looking for more information, I'd suggest opening a support case. This would allow one of our technicians to look at your firewall and VPN set-up and provide feedback based on that.