I’m slightly perplexed. You indicated that you use IKEv2/IPSEC to connect to NordVPN. From what I understand, NordVPN uses OpenVPN and OpenVPN doesn’t support IKE/IPSEC? So, I’m at a loss as to what OpenVPN is actually using when you select IKEv2/IPSEC, or even how it’s allowing you to select IKEv2/IPSEC. Are you running a MAC as well, which does connect via IKEv2/IPSEC?
You indicated in your first post that you’re not a techie. I think that you’re going to have to dive into a few details and become at least a limited techie to improve the VPN performance. Sorry : ( There doesn’t appear to be a magic wand here that would cure the situation. As I currently see it, there are three items to look at:
I had a look at the processor specs. It supports the Advanced Encryption Standard – New Instructions. Using that instruction set for VPN purposes should result in faster VPN throughput.
So, I’ve been looking around for references to enable AES-NI in OpenVPN and haven’t found a clear reference or instructions to do this. OpenVPN should support AES-NI out of the box, but, I’m still trying to confirm this.
Looking around I came across the latest build of OpenVPN, which appears to be v 2.4.6. There is a note in the following page which indicates that a newer driver will be included in an upcoming Windows Installer. Have a look at the NordVPN version of OpenVPN and if that is an older version, consider loading the newer version. To do that, on the pc, navigate to Start …. Programs and Features. Have a look to see if OpenVPN is listed and what version is loaded. Don’t quote me on this, but you should be able to load the newer version over the existing version. The latest version has improved IPv4/IPv6 dual stack support which might be useful in improving the throughput. I’d bookmark the following page and keep an eye on it for updates to OpenVPN:
While doing this I came across a comparison between ExpressVPN and NordVPN. The comparison indicates that NordVPN’s North American servers run slow. Looks very much like the results that you saw. That in itself might be the sole reason behind the slow performance. Take a read thru the following July 2018 comparison:
Can you run a speedtest thru some of NordVPNs servers in Europe? I’m thinking maybe the servers in the UK, Netherlands and Germany. Have a look to see if there are major differences in the throughput rates, as suggested in the comparison.
VPN throughput rates. Reading thru some of the pages spread across various site, the subject of encryption comes up. This makes sense, as you use higher encryption levels, the encryption/decryption load goes up. Have you run any tests to see what effect if any occurs when you select a different encryption standard? It might be that your throughput is so low, that it doesn’t matter which encryption standard you choose.
Can you have a look at the modem’s VPN passthrough settings. Log into the modem and navigate to SECURITY …. VPN Passthrough. My modem is running in Bridge mode at the moment so I don’t have access to that page. Previous versions had an IPSEC, PPTP and L2PT Pass-Through. Can you have a look to see if SSL is available as those other settings won’t help. If there is an SSL or SSL/TLS selection, please enable it, save the setting and reboot the modem …. ADMIN ….. DEVICE RESTART …. Reboot.
Food for thought:
I’d like to see the results for a speedtest thru a European Nordvpn server, just to see what difference there is. This might answer the question on its own.
Reading thru various pages, it looks like OpenVPN is a pig to run. It might be an idea to load a different VPN application to see if you end up with better results. I don’t know what applications are out in the wild, either free or licenced. In either case, I’d be looking for AES-NI support to get the pc’s VPN throughput running at its maximum. Looks like Windows has its own Microsoft VPN Client built in. It might not be as fancy as the OpenVPN client, but, it’s probably worth looking at for test purposes.
OpenVPN appears to run UDP or TCP/IP. UDP is a fire and forget type of protocol. It will either get to its end destination or it won’t. TCP/IP requires packet receipts, so, once a packet is sent, it should arrive or be retransmitted. One way or the other, it will get to its end destination. Problem is, the TCP/IP transmit/receipt protocol slows traffic. So, fwiw, you could try running UDP and see what you get for results, both in terms of reliability, and in speed.
Here’s an interesting line that I came across in the following link:
“When OpenVPN uses Transmission Control Protocol (TCP) transports to establish a tunnel, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the "TCP meltdown problem"”
That shouldn’t be an issue given the bandwidth that you have available, but, it’s rather interesting.
OpenVPN supports IPV6. Just for test purposes, try disabling IPV6 in the modem and see what happens to the VPN performance, if anything. Navigate to BASIC …. GATEWAY FUNCTION, and change the Router Mode from Dual (stack) to IPV4. Save the changes. It will take a couple of minutes for the modem to switch to IPV4 “only” mode. I usually reboot the modem after this. Run the ADMIN …. DEVICE RESET …. Reboot function. At the same time, reboot the pc. After the reboots, run another test thru the VPN to see what you end up with for results.
I came across a post for OpenVPN running on PfSense, which is a firewall operating system that is loaded on a pc. The post indicated that OpenVPN is a single thread application, so, it doesn’t matter how many processor cores there are, or if the processor has hyper-threading running, this is a single thread application. The only way to run the VPN faster is to run a faster processor. So this is rather interesting. When you’re running the VPN, bring up the Windows Task Manager and select Performance …. CPU to look for CPU loading. It would be interesting to know what the CPU loading is when the VPN is running. I came across a request in the OpenVPN Wishlist to include multi-core support, so, this looks like a problem. This gets back to the AES-NI support which should direct encryption processing to the onboard hardware processor, assuming that there is one built into the CPU. The question in this case is whether or not that processor is tied to the CPU clock rates, or if it can operate independently of the CPU? The CPU load might be a hint, low load, maybe the processor is doing the work, high load, the CPU is doing the work, in which case, what’s the status of the AES-NI support in the NordVPN OpenVPN application. Hopefully you can see why I’m asking this.
Fwiw, there is an upcoming firmware change for the CODA-4582 modem to improve the performance of IKE/IPSEC which is used by MACs when they connect with NordVPN. I don’t know if that will result in any corresponding improvement in VPN performance. Right now, the Hitron modems will limit IKE/IPSEC to 25 Mb/s. That's either a firmware problem, or a firmware limit that's existed since 2008 from the original Puma 5 modem manufactured by Texas Instruments (my guess). This might be part of the problem that you're seeing, although I still don't understand how you're using IKE/IPSEC in the first place.
Ok, so, this is a little bit of homework. As I indicated earlier, there doesn’t appear to be a single magic bullet that will solve the problem. One item that does come to mind is to call NordVPN tech support and ask the Customer Service Rep if AES-NI is already running in their OpenVPN client, and if not, what has to be done to enable AES-NI. I haven’t found any specific info for it, so, maybe the support is built in. If you do have to enable it, you might not find any difference in throughput rates if all of their North American servers are running very slow. It’s entirely possible that you could put a great deal of effort into this and not get anywhere due to their server throughput rates. Only way to determine that is to try different servers, or possibly even a different VPN provider.
What setting are you using for the encryption? AES-128-CBC, AES-192-CBC or AES-256-CBC?
WOW very nice reply indeed..
Lots of info
Nordvpn is done all they can do they say.
it is what it is
Using Europe's servers yields nothing better really!
Maybe the new CODA version of firmware, if and when it arrives, will be better.
Meanwhile I think I will either pay some person to fix it or look for an alternative VPN
- The European Servers are not any better in speed.
- the AES-NI is not Running in their client as it does not work well with their servers.
- the CODA router has these SSL or SSL/TLS selections enabled
- Im running the UDP protocol as well
- changed the Router Mode from Dual (stack) to IPV4 but it made no speed change, ( I have it disabled in the adapters in windows.)
- Their client does not allow to use different Encryption, so I was not able to run a test with other options
Encryption settings from what I see are not an item the user can tinker with
I do have a Netgear WNDR 4000 router with DD_rt that I would like to bridge with the CODA but not sure if it will be making a difference..
Do you think one of their routers they sell(nordvpn) flashed with their software will be better?.. if not
Time to look to another vpn perhaps.
Any suggestions of VPN services working great with the CODA router? in Canada and specifically rogers?
Again Awesome reply and thank you for taking all the time to post..
@flyboy50 I don't have any good suggestions for VPN services in Canada as I don't use a VPN (I probably should) . I'd be hesitant to buy a router from any specific service unless you absolutely had the ability to load it with something else such as PfSense, and that router had AES-NI support. Fwiw, the next PfSense version will require AES-NI support. My guess is that it won't load unless AES-NI support is present.
The Asus RT-AC88U, RT-AC3100, RT-AC5300 and RT-AC86U has IPSEC support when loaded with Merlin's Asuswrt. As far as I know, only the RT-AC86U has AES-NI support which results in much faster IPSEC throughput rates. You would have to look around to see what else might run AES-NI with IPSEC support.
Fwiw, QOS is an issue with Asus router. Seems this goes back a long ways. I don't use QOS so I haven't kept up with its current status.
For a VPN recommendation, you could post a question in the Canadian Broadband forum of the DSLReports site:
Here is one small thread from that forum.
Have a look at the following thread:
Here's a page from the smallnetbuilder site with a few interesting comments regarding VPN capability:
There is a better thread regarding the RT-AC86U and VPN support, just have to find it somewhere.
Running into the same situation. Same Modem (CODA-4582U - not certain what FW since Rogers won't allow me to log into the device since I have static IPs), IPSec VPN connecting to Azure. Odd thing is, it was working spectacularly until 3 days ago and has been working for about a year - running near full speed (around 650MB down and 42mb up.)
Then, all of a sudden I started getting warnings that my backups weren't completing in the time allowed - transfer rates to Azure are now 420kb/s instead of 42,000kb/s. But, my fast.com results are still returning 800/45. Spent hours troubleshooting Azure, rebooting firewall and modem to no avail.
Eventually, I changed Azure to point at my backup Primus 6/6 connection and my upload speeds were back up to 3-4MB/s...
Same Azure VPN settings, same firewall, same network, 6/6 connection is 10x than my 1000/50... Rogers tech says there wasn't any infrastructure changes nor was the device fw upgraded, but he tried pushing a newer FW modem but it failed - they are sending a tech to replace it, I hope it resolves the issue...
This doesn't seem to be affecting my Remote Users on openVPN (transfer rates are still in the normal range,) but I've confirmed it's also affecting my mobile IPSec clients using a different IPSec config (same inbound ISP/modem.)
Good morning @EricMc!
Welcome to our Community!
VPNs are very important to many of our customers, so please update us once the tech has come to replace your modem and let us know if that resolves it.
@EricMc usually when tech support can't push a firmware upload to the modem, that's an indication of an external cable and / or connector fault. Do not let the tech leave without him or her checking the cable signal levels, which can be done via the techs wireless tablet or laptop. That connects to the Rogers system, allowing the tech to look at the signal levels without connecting directly to the modem or its RG-6 cable.
Personal opinion, the first thing that should be done is to check the signal levels, take whatever corrective action is required, then consider swapping the modem.
Actually low IPSEC data rates with Intel Puma modems, which includes the Puma 5, 6 and 7, are a known issue. There is an upcoming update which will hopefully resolve the low data rates. Won't know until that's released and users have a chance to test it. So, swapping the modem will not do anything to increase the IPSEC data rates.
The black Hitron modems are Puma 6 modems, the white Hitron modem is a Puma 7 modem.
This problem probably dates back to 2008 when Intel bought the Puma modem line from Texas Instruments and dropped in an Arm and Atom processor into the design. Either the IPSEC limitation was in the original Puma 5 modem that Texas Instruments built, and that limitation was dragged 10 years into the future, or, the limitation was caused by the chipset design changes that Intel introduced.
Other users who require IPSEC data transfer have simply left Rogers and gone elsewhere, where IPSEC isn't an issue.
Edit: You should find that you're limited to 25 Mb/s over an IPSEC VPN, which is an Intel Puma 5/6/7 modem limitation. If you were running the new Ignite TV service, with a Technicolour XB6 modem instead of the Arris XB6 modem you might see higher IPSEC data rates. The Technicolour XB6 is a Broadcom BCM-3390 modem, the Arris XB6 is an Intel Puma 7 modem. Now having said that, when someone with a Technicolour XB6 manages to really test IPSEC VPNS, we'll find out if there are any additional network issues lurking about as well, and that possibly this isn't just a modem issue. I haven't seen anyone with the Technicolour XB6 post any IPSEC results, but, one of these days it will happen. I'm looking forward to those results, whenever they show up.
I've been reading about 'updates' as far back as 5 years ago - I don't think they are coming 'soon' anymore. That said, everything was working fine until Thursday last week with the exact same traffic - I've essentially uploaded 100s of TBs across the pipe over the last year. I had this issue with the an older model (likely the PUMA6, it was black) which caused us to upgrade to the coda-4582u modem against Rogers recommendation at the time. I went month-to-month for 6 months before signing a contract to make sure the issue didn't return. According to Rogers, nothing has changed that would cause this, so this is why I'm scratching my head... If nothing changed, what changed?
Have a look at my additional "Edit" above. There is an update in the works, just not sure if its going to be included in the next one or two updates. I'll inquire about any progress on this.
First thing that comes to mind is a cable issue. Its possible that the problem is beyond your cable system, somewhere between the local tap, which you are connected to, and the neighbourhood node. As I indicated above, the first item that comes to mind when tech support can't push an update is a cable issue. Since your cabling was replaced very recently, I would suspect some issue further upstream, in which case tech support should have dispatched a senior tech, not a contractor tech.
Then there is always the possibility of some configuration change witin the Cable Modem Termination System (CMTS). Your modem connects to the CMTS via the neighbourhood node. Any configuration change, accidental or deliberate can result in issues for users.
Are you running IPV6 by any chance, and if so, does your transfer target use IPV4 or IPV6? If you're running IPV6, I wouldn't be surprised if there was a configuration change with the CMTS which is causing IPV6 problems for users connected to that particular CMTS.
You should be able to log into the modem using 192.168.0.1 or 192.168.100.1 if the modem is in Gateway mode, or by using 184.108.40.206 if the modem is in Bridge mode with a router behind it. You can log into the modem thru the router.
If you can log into the modem and its running in Gateway mode, you will see two WAN addresses in the upper right hand data block on the Status page. That page is displayed automatically when you log into the modem. The upper right hand corner is the WAN address block and it will show both IPV4 and IPV6 addresses if the modem is running IPV6.