DrayTek UK Users' Community Forum
Help, Advice and Solutions from DrayTek Users
Slow VPN routing
- mgillespie2
- Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
06 Apr 2024 09:39 #1
by mgillespie2
Slow VPN routing was created by mgillespie2
I have a 2862, I know it's getting on a bit, but it is works very well for me, for the most part.
My only real issue is slow VPN routing. I have a VPN setup using IPSec Tunnel and IKEv2 EAPand AES.
I find the the routing throughout via the router significantly slower than if I run the VPN client on my desktop PC. Slower by a factor of 10 times slower. I'm running latest firmware.
Is this simply due to the age of the router, and a limited CPU? Is there anything I can tweak in the settings to improve things? Will a newer router improve things? (If so, suggestions on non-wifi models?).
Thanks.
My only real issue is slow VPN routing. I have a VPN setup using IPSec Tunnel and IKEv2 EAPand AES.
I find the the routing throughout via the router significantly slower than if I run the VPN client on my desktop PC. Slower by a factor of 10 times slower. I'm running latest firmware.
Is this simply due to the age of the router, and a limited CPU? Is there anything I can tweak in the settings to improve things? Will a newer router improve things? (If so, suggestions on non-wifi models?).
Thanks.
Please Log in or Create an account to join the conversation.
- mgillespie2
- Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
06 Apr 2024 09:51 #2
by mgillespie2
Replied by mgillespie2 on topic Re: Slow VPN routing
There are a whole bunch of settings under advanced, security profile that I have no idea what they do, will any of these potentially increase my throughout?
Code:
IKE phase 1 mode(IKEv1) Main mode Aggressive mode
IKE phase 1 proposal Encryption
AES128
IKE phase 1 proposal ECDH Group
G14
IKE phase 1 proposal Authentication
SHA256
IKE phase 2 proposal
AES128_[SHA256,SHA1,MD5]
IKE phase 1 key lifetime
28800
(900 ~ 86400)
IKE phase 2 key lifetime
3600
(600 ~ 86400)
Perfect Forward Secret Disable Enable
Local ID
Please Log in or Create an account to join the conversation.
- HodgesanDY
- Offline
- Member
-
Less
More
- Posts: 140
- Thank you received: 3
06 Apr 2024 12:31 #3
by HodgesanDY
Replied by HodgesanDY on topic Re: Slow VPN routing
Hi mgillespie2,
10 times slower seems a bit much.
I have a 2862 and use LAN-to-LAN with IPSec and have no real speed issues, it is a little slower than unencrypted, or lesser encrypted traffic, mainly because of the encryption/decryption processing - as you mentioned, but, also because of the header room needed inside the packets for the method you are using, whatever that may be, as it eats into the size of the payload you can send across the connection.
You can test your payload size (MSS) by sending a ping packet with a specific size of your choosing. You could do this test before making any changes to see what the difference currently is.
Open a cmd prompt (on Windows) and ping the router (or a device) at the remote site to make sure your pings echo back, then try adding a payload larger than the default by typing:
ping 192.168.5.1 -l 1350
(I’ve used a random ip address here)
If that packet echos back, try increasing it until it doesn’t echo back. The -l 1350 is the payload size, minus everything else involved in the packet (headers etc).
Once you know what your maximum payload size is, you can try to make some adjustments to help pass the largest possible payload across your connection.
You will most likely be limited by the standard MTU of 1518 bytes (sometimes 1520 with added head-room) which generally gets set to 1500 by most shipped units; which is fine.
Max that MTU out at every possible point, to 1500, if you can. Nowadays you don’t need to worry too much about leaving head-room, like setting it to 1485, as most equipment will automatically adjust the payload size to allow for the header space it needs.
When you have matched this test on both your LAN-to-LAN and your Client App connection and can send the same size payload, or not, through both then you’ll know why one is faster than the other and if it’s the payload or the processing that is the bottle-neck.
10 times slower seems a bit much.
I have a 2862 and use LAN-to-LAN with IPSec and have no real speed issues, it is a little slower than unencrypted, or lesser encrypted traffic, mainly because of the encryption/decryption processing - as you mentioned, but, also because of the header room needed inside the packets for the method you are using, whatever that may be, as it eats into the size of the payload you can send across the connection.
You can test your payload size (MSS) by sending a ping packet with a specific size of your choosing. You could do this test before making any changes to see what the difference currently is.
Open a cmd prompt (on Windows) and ping the router (or a device) at the remote site to make sure your pings echo back, then try adding a payload larger than the default by typing:
ping 192.168.5.1 -l 1350
(I’ve used a random ip address here)
If that packet echos back, try increasing it until it doesn’t echo back. The -l 1350 is the payload size, minus everything else involved in the packet (headers etc).
Once you know what your maximum payload size is, you can try to make some adjustments to help pass the largest possible payload across your connection.
You will most likely be limited by the standard MTU of 1518 bytes (sometimes 1520 with added head-room) which generally gets set to 1500 by most shipped units; which is fine.
Max that MTU out at every possible point, to 1500, if you can. Nowadays you don’t need to worry too much about leaving head-room, like setting it to 1485, as most equipment will automatically adjust the payload size to allow for the header space it needs.
When you have matched this test on both your LAN-to-LAN and your Client App connection and can send the same size payload, or not, through both then you’ll know why one is faster than the other and if it’s the payload or the processing that is the bottle-neck.
Please Log in or Create an account to join the conversation.
- juleswilko
- Offline
- Junior Member
-
Less
More
- Posts: 34
- Thank you received: 0
26 May 2024 16:58 #4
by juleswilko
Replied by juleswilko on topic Re: Slow VPN routing
Funnily enough...
I'm just about to search for something similar.
But - L2TP IPSEC VPN - with end points routing their traffic - but - on a 2962.
It appears to have gone to absolute garbage throughput and horrendous ping times all of a sudden.
I'm just about to search for something similar.
But - L2TP IPSEC VPN - with end points routing their traffic - but - on a 2962.
It appears to have gone to absolute garbage throughput and horrendous ping times all of a sudden.
Please Log in or Create an account to join the conversation.
- HodgesanDY
- Offline
- Member
-
Less
More
- Posts: 140
- Thank you received: 3
26 May 2024 20:06 #5
by HodgesanDY
Replied by HodgesanDY on topic Re: Slow VPN routing
I have encountered this with ‘Hardware Acceleration’ >> ‘IPSec’. If you have this enabled, try disabling it first, before you go down a rabbit hole.
Please Log in or Create an account to join the conversation.
Moderators: Sami
Copyright © 2024 DrayTek