I need some advice on OpenVPN VoIP performance tuning

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Fri Apr 16, 2021 17:19    Post subject: I need some advice on OpenVPN VoIP performance tuning Reply with quote
Hi All,

I have 2 sites - the first site#1 (main) uses multiple networks (172.16.1.0/24, 192.168.1.0/24) the second site#2 (remote) a single network 172.16.100.0/24

At the main site I have a FreePBX asterisk phone switch configured with a variety of different VoIP phones connected to it (mostly Polycoms but some other brands as well)

At the remote site I have 2 Polycom phones and 5 Cisco phones.

Currently I have ASUS RT-N16 routers at each site. Currently, the main site is running r45993 K2.6 and the remote site is running r46177 K3.0

The OpenVPN main setup is using udp, TUN, AES-128-CBC and an intermediate network of 172.16.20.0 The remote setup is the same except that NAT and Compression are turned off

I have various routing statements in the openvpn config to allow all networks on each site to route through OpenVPN to each other. Both the main site router and the remote site router have wifi disabled.

This setup has been running for the last couple of years. Originally I had it on r30880 code on both sides but beginning of the year I decided it was time to get it current and moved it to current code

My problem with it is simply this - the fragility and difficulty to troubleshoot the setup.

When I set it up on the r30880 code a few years back it took weeks of fiddling with it (and by fiddling I mean replacing routers with other models running dd-wrt) to get things working. Note that merely getting PINGS and telnet and file connections over the OpenVPN setup to work was NOT the problem. The problem was getting it configured so that the VoIP phones at the remote site would stay registered with the server. I ended up going through the same process with the most current upgrade.

File connections and so on all use TCP. But VoIP is heavily dependent on UDP. One of the assumptions in the TCP/IP protocol suite is that it's OK to drop UDP packets if the line is congested, etc. So far so good.

Unfortunately, with VoIP when the manufacturers started implementing it in phone extension hardware, they made the assumption that the PBX in all cases was going to be reachable via a local LAN, either gigabit or 100baseT ethernet.

On such LAN's it is extremely rare you ever have a situation where there is so much congestion that the ethernet switches drop packets. So the phones basically treat UDP like most apps treat TCP - practically every single UDP packet is going to be delivered. If there is any significant amount of UDP packet loss then many phones will just give up and drop registration. The Polycom's seem to be particularly bad at this, the Cisco phones much less so, some other manufacturers phones are worse and some are better and some models are worse and some are better even within the same manufacturer. And I have tested at least 8 different major VoIP manufacturer's phones. It makes no difference if the phone has a jitter buffer in it or not (although a jitter buffer does help sound quality a lot) they are still all over the map with registrations. I've tried "running the latest firmwares" on the phones, it makes no difference.

This basic assumption of the reliability of UDP causes a whole lot of trouble with OpenVPN and dd-wrt. The reason as near as I can figure it out is that different builds generate different OpenVPN executable binaries for different CPU's and different router models seem to have different modules included that can screw up the works. The fundamental issue seems to be that OpenVPN is written in such a way that if an incoming packet is presented to it for encryption, that if OpenVPN has not completed encrypting prior packets presented to it and sending them out to the remote VPN server, it will drop the incoming packet if it's UDP. So, if the particular router model CPU happens to have particularly poor integer math or lacks floating point or whatever, or is running at a slower clock speed, or is mostly being sucked up in a hardware driver, then OpenVPN will drop more UDP packets than the phones can tolerate. As a result they lose registration with the PBX.

On the ASUS RT-N16's these have Broadcom BCM4716 CPUs running at 480Mhz, which is respectable, but 128MB of DRAM and 32MB of flash, and so because the flash is constrained, BrainSlayer is forced to drop SIP Proxy from the build. The wifi radios in these are, apparently, horribly inefficient (my guess is most of the radio is implemented in software in the binary blob driver) so by turning OFF the radios, and not having SIP Proxy (which appears to screw with VoIP traffic even if it's disabled) in the build at all, it gives you a lean, mean build on overpowered hardware so I'm able to get the phones to stay registered.

If I do something like for example turn on the wifi in the main router, then I'll start losing phone registrations - the Polycom's will drop off first, while the Cisco's stay connected. If I try different hardware routers, and they are worse, not even the Cisco's stay connected. (Surprisingly, some of the really stripped down builds running on neutered routers with 4MB flash have quite good OpenVPN performance due to the unloading of so much useless cruft in the dd-wrt build)

For example I have a couple of Netgear AC1450s that have 128MB flash and 256MB ram and 800Mhz dual core CPUs I have tried to put into service since they are better and more powerful devices than the RT-N16 - right - no, wrong. Because, apparently, the ARM build generates a less efficient OpenVPN binary so that even the boost in CPU power is worthless and apparently their radio drivers are more efficient since turning off the radios doesn't seem to do anything so that trick doesn't help. And since the devices have gobs of flash, the incentive for BrainSlayer is to throw everything including the kitchen sink into the build so the dd-wrt code overall is slower because the router has to manage all the other modules even if they are not active.

Supposedly Marvell CPUs have some crypto-specific instructions that OpenVPN supports but dd-wrt does not support Marvell other than the WRT19x and WRT32x devices and unless I had some definitive response that a WRT1900 would greatly speed up openvpn performance I'm not going to drop $100 on a set of used ones just to experiment.

Unfortunately, virtually everyone out there benchmarking OpenVPN is doing it with raw file transfers and such that are all TCP based. So even if they are doing it in a controlled lab environment their results are worthless.

I know that I could just scrap out the dd-wrt devices and put Intel boxes in there which all have crypto hardware acceleration and probably solve the issue. But the remote site is 2 hours away and troubleshooting this and making changes to get to a reliable setup is an all day affair for just a single change like a hardware device change. And then you have the increased unreliability of having a hard disk and a fan and so on.

Another possibility is switching VPN protocols but going to something like IPSec well first I have to abandon dd-wrt for something like a Cisco RV320 or RV340, and those are not completely reliable either plus their configuration ability is very limited - I cannot for example send out a TFTP server IP in a DHCP response packet for example. And IPSec would mean adding multiple peer configurations and a more complicated configuration. But most of all, IPSec would mean a commercial setup that would end up becoming EOLed. One of the great things about dd-wrt is it's support - it STILL runs on antique WRT54g's unbelievably. The ASUS RT-N16's are almost antiques as well yet still run builds that were released yesterday.

The other great thing about dd-wrt on a remote device is if it suddenly stops working usually a power cycle reboot fixes it and I can call someone at the remote site who is NOT an IT person and walk them through doing this.

So I am not really interested in replacing dd-wrt but instead I would love suggestions on performance tuning openVPN on non-hardware-accelerated gear.
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Fri Apr 16, 2021 18:00    Post subject: Reply with quote
Try WireGuard Smile

About 3 times faster than OpenVPN.

Alternatively use something like a Netgear R7800

Marvel has shitty wifi drivers but if you do not need wifi the hardware is good

OpenVPN and WireGuard documentation links in my signature

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Fri Apr 16, 2021 19:33    Post subject: Reply with quote
The primary problem w/ the router is NOT the lack of hardware assisted crypto. Yes, it can make a significant difference, but only once you get the more basic problem, which I'm about to explain.

The problem is that most of these consumer-grade routers are NOT capable of handling ring changes efficiently. They simply don't have the horsepower. And since most VPNs run in user-space, this presents a problem, since creation and management of the tunnel require *constant* access between user-space and the kernel. THAT is what's causing the performance hit. Once you get past that problem, THEN hardware assisted crypto plays a much bigger role in getting top-end performance.

Way back in the early 90's, Microsoft encountered this same problem w/ their GDI (graphics device interface) in Windows 3.0. It required constant access between user-space and the kernel, bringing the GUI to a crawl. The processors of those days were like those of today's routers; relatively pathetic. Microsoft solved the problem by moving the GDI to the kernel. All well and good until the Internet came along and hackers discovered they could exploit known vulnerabilities in the GDI, to the point they sometimes had RCE (remote code execution) capabilities! Microsoft then spent years fixing those vulnerabilities.

The use of WireGuard in place of OpenVPN is essentially the same solution. WireGuard runs in the kernel, NOT user-space, giving it leg up over all other VPNs. Performance is thus dramatically improved, but w/ the same potential for unintended consequences/vulnerabilities.

The issue w/ VOIP is NOT so much TCP vs. UDP; it's the need for realtime response. Same holds true for video conferencing. The loss of packets when using UDP w/ your time server, for example, is no big deal. No one would even notice. But that's NOT true w/ realtime applications. They simply can't tolerate lost packets all that well. And then you add the internet + VPNs, and well, you're just asking for problems. It's one of the reasons the argument over net neutrality matters. Whatever the valid arguments may be to justify it, it makes it that much harder to give these protocols the preferred routing they need.

In my own case, I simply grew tired of the lackluster OpenVPN client performance on my router (ASUS RT-AC68U) and moved it to a small form-factor PC made out of spare parts (circa 2011), running dd-wrt x86. Problem solved. It's pretty inexpensive to run. It only draws a measly 18 watts and runs off a USB flash drive. Even the most modest PC-based platform is going to blow away the router in terms of VPN performance. And have I no personal desire to start dealing w/ yet another VPN after all these years. WireGuard also doesn't support *bridged* VPNs either, only routed. And having the bridged option can be handy at times.

In short, if you want to stick w/ the router, then WireGuard is probably your best option. And the better the router in terms of raw horsepower, so much the better. But to some degree, the fact you have to reach over the internet and use a VPN is always going to make this setup somewhat problematic.

JMTC

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Fri Apr 16, 2021 23:19    Post subject: Reply with quote
There is of course always an issue with running any real time protocol over the Internet based on UDP. (incidentally the Polycom's will support SIP-over-TCP as will FreePBX/Asterisk although it does the same thing - periodically loses registration or fails to register at all)

However one thing I have learned is that if you throw bandwidth at this problem the problem usually goes away - that is, with modern ISP's and their networks they have so many gobs of unused bandwidth available on their fiber links (at least in the United States) that if you buy big enough links for each side, ESPICALLY if you buy business-quality links (which I did, primarily to get static IP addressing) you don't really have packet loss or significant jitter. People tolerate pretty horrible voice on cell phones nowadays anyway so "hearing the pin drop" was sacrificed ages ago with VoIP.

I also get it with Net Neutrality but I am actually on the anti-Net-Neutrality camp because the moment that ISP's are forced by law to prioritize ANY packet just on account of the type of packet, you are going to see creative people write stuff like file transfer programs that use prioritized packets, merely because they are dicks and want to get top billing on the wire, and because they don't give a tinker's dam about playing fair with anyone else.

But all this is academic since in THIS case, there is apparently enough bandwidth available between the main and remote sites for SIP to work and the phones to stay registered. (which is even more interesting since both sites use different providers) So the problem is horsepower - CPU power in this case.

If the crypto calculations are not demanding enough to make a dent in the CPU clock cycle allocations then OK as you say the only other potential problem is the context switching between userspace and the kernel with openvpn.

It's probably similar to running a NFS server in userspace (someone wrote such a thing and I have run it on these small devices and yes, it's anemic compared to a proper kernel-space NFS server)

But, I feel like I'm so fricking close on this one. The old 30880 code was stable and the phones remained registered with it. And during the course of the year or so that I ran that code version I switched in and out several different hardware devices at each site. Netgear WNDR4000's and a few others. It just seems with this code that all you have to do is meet a minimum amount of horsepower for the code you are using - once you get that, you are gold.

There's been major changes with OpenVPN between the older OpenVPN version on the old code and today's dd-wrt code that have created a fatter and slower OpenVPN instance. That's fine if you are running PC's at each end since every year Intel releases CPU's with more and more go-fast instructions that the OpenVPN people seem to like to write Assembly code to make use of.

But with these small router devices, it's as you say, completely aimed at the lowest cost which means they use the slowest and cheapest CPU's that will still make the device "work" But not having to have a fan in the device and just using convection cooling, and not having to have flash or a spinning disk - those are HUGE wins for me for the remote side.

I'm also not really interested in replacing the institutional knowledge of OpenVPN with WireGuard or SoftEther or something else, but if I have to I will to preserve the use of the cheap device on the remote.

I'm still in the "tuning" stage with both sides and even though all the extensions are registered I'm still going to tinker a bit with it over the next week, and I'll post what I find out to this thread.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Sun Apr 18, 2021 18:25    Post subject: Reply with quote
I understand your rationale for sticking w/ the router. If it wasn't for the fact I just happened to have the spare parts sitting on a shelf collecting dust over many years, and the fact it runs so inexpensively, I would have stuck w/ the router myself.

Seems to me the *least* you can do is upgrade those routers. According to wikidevi, the ASUS RT-N16 is a measly 480MHz!

https://wikidevi.wi-cat.ru/ASUS_RT-N16

Not all that impressive when you consider modern ARM-based routers are now routinely in the 1.8GHz range.

My current ASUS RT-AC68U (800MHz) is nothing to write home about when it comes to VPN performance (can't recall exactly what I was getting since it's been a while, but I think it was roughly 25-30Mbps). And when it comes to overcoming this problem, horsepower matters. It's pretty much linear.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Tue Apr 20, 2021 19:59    Post subject: Reply with quote
So this weekend I did some more testing. I started by upgrading the ASUS device out at the remote to the firmware released 4/19/21. That made things worse even though the firmware was only a month newer. The setup went back to the phones randomly losing registration with the PBX.

So then I replaced the router at the remote with a Netgear WNDR4000v2 This has a 600Mhz CPU in it. I was STILL getting random disconnects though - the most annoying thing was that if I rebooted or did a reconfiguration on the WNDR4000 then all phones would immediately connect - then over time would randomly switch to UNAVAILABLE state then eventually disconnect - at least MOST of them would eventually disconnect. That was at least better than the ASUS routers, though.

I then attempted to change the crypto to CHACHA20 for testing but got this error:

20210420 08:47:41 W DEPRECATED OPTION: --cipher set to 'CHACHA20-POLY1305' but missing in --data-ciphers (AES-128-GCM:AES-256-GCM:AES-128-CBC). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'CHACHA20-POLY1305' to --data-ciphers or change --cipher 'CHACHA20-POLY1305' to --data-ciphers-fallback 'CHACHA20-POLY1305' to silence this warning.

I believe this is a bug in my opinion the GUI should not be displaying cipher options that were not compiled into OpenVPN. HOWEVER - all phones registered and STAYED registered. Setting the cipher to AES-128-GCM made the error in the log go away.

So here are the takeaways from this:

1) DISPLAYED cpu utilization is meaningless here. All routers never displayed significant CPU utilization.

2) None of this is applicable to ordinary filesharing/etc traffic. Ping and TCP traffic showed no issues in any tested configuration. This is only applicable to UDP traffic that is sensitive to packet drops or delays.

3) The master OpenVPN dd-wrt router apparently does not need to have as much CPU speed to keep up with all packets.

4) The remote OpenVPN dd-wrt router requires the fastest clock speed CPU available. 500-550Mhz seems to be the cut-off point, anything under that and the CPU clock speed will not be fast enough to keep up with the UDP data stream. This has nothing to do with the actual bandwidth on the Internet connection.

5) The AES-128-GCM crypto code is apparently faster or better implemented than the AES-128-CBC crypto code, or the Broadcom CPU has some go-fast instructions that this crypto makes use of.

6) Compression must be set to NO on the remote. Allowing it causes too much delay.

7) The UDP timeout must be adjusted up from 120 seconds. I have mine set to 350 seconds but likely it needs to be doubled. The phones retry or send keepalives in 300 seconds.

8 - Turning on the wireless radios impacts CPU enough to cause phones to start dropping.

9) The NUMBER of registered SIP devices going through the tunnel apparently also matters - the more registered devices the more taxing it is on the remote and the more of them drop off registration.

I am in the process of setting up a parallel set of routers in order to attempt a wireguard vpn setup. However all of the instructions I have found out there seem to use the case of a single remote end node connecting to a Wireguard VPN server. So likely a true lan2lan VPN connection over Wireguard will have to be cudgeled together the same way as you do it with OpenVPN.

Finally once more for any interested less advanced readers - this IS NOT APPLICABLE TO YOU if your OpenVPN connection doesn't "connect". If you cannot ping through your OpenVPN link NOTHING I am talking about has any applicability.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Tue Apr 20, 2021 23:32    Post subject: Reply with quote
Have you considered using a bridged VPN? Or perhaps an mDNS replicator (e.g., Avahi) w/ the current routed configuration?

What I'm wondering is if perhaps this application relies to some extent on broadcast messages, if only as a keepalive mechanism. But broadcasts do NOT typically cross IP boundaries, requiring a proxy for those purposes.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Wed Apr 21, 2021 7:57    Post subject: Reply with quote
This:
Quote:
20210420 08:47:41 W DEPRECATED OPTION: --cipher set to 'CHACHA20-POLY1305' but missing in --data-ciphers (AES-128-GCM:AES-256-GCM:AES-128-CBC). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'CHACHA20-POLY1305' to --data-ciphers or change --cipher 'CHACHA20-POLY1305' to --data-ciphers-fallback 'CHACHA20-POLY1305' to silence this warning.

is not an error it is a warning about a configuration error.

Chacha20-Poly1305 should be even more efficient than the new AEAD-GCM ciphers although in testing I did not find any measurable difference.

Using compressing is a a security risk and is also deprecated and the compress/decompress eats valuable CPU cycles so in actual throughput on soho routers it does not bring you anything

This is all described in our OpenVPN Documentation:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327398

But it is always nice to see that someone reaches the same conclusions as we already did Smile

Wifi is known to be CPU demanding if you also want to have WiFi and good OpenVPN performance you need something like a Netgear R7800 (Dual core Arm A15 at 1725 MHz)

WireGuard also has a lot of documentation:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327397

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Wed Apr 21, 2021 16:45    Post subject: Reply with quote
egc wrote:
This:
is not an error it is a warning about a configuration error.
t=327397


I have to disagree with you there since later in the OpenVPN log it explicitly says the cipher used on the link was CGM. If the GUI allows selecting CHACHA then it should alter the rest of the config in order to allow CHACHA to come up in the link. The whole point of a GUI is to prevent users from shooting themselves in the foot.

However adding ciphers makes OpenVPN bigger so it seems apparent that BS dropped the CHACHA cipher from the build of firmware for this particular router for space reasons and there IS a bug in that the GUI on this router build allows selecting CHACHA while the actual CHACHA cipher was not included in the build for this router.

If as you found compression is a waste of time then once more, the GUI default ALSO should be for compression to be OFF not for it to be ON. That's why we have a GUI!!!

Please explain the benefits of buying a $300 super powerful router that lets you do wifi + VPN + NAT all on the same box vs buying 2 inexpensive routers for $15 each out of the boxes at Goodwill (which is where every single router I test with comes from BTW including the WNDR4000) and using 1 for the NAT+VPN function and the other for the wifi function.

Oh wait, I should qualify that. The benefits FOR THE END USER. The benefits for the MANUFACTURER are apparent....LOL

Seriously people need to put some brains into this. Splitting off the wifi means redundancy and it makes it a heck of a lot easier to troubleshoot.

Sorry for the snark but this isn't my first rodeo. I am not posting my findings as a complaint I'm posting them so the next user who attempts this can benefit from the research.

Now, as for bridged vs routed VPN:

First, the SIP phone registration does not use broadcasting. Remember a lot of these SIP phones are sold for use in people's homes on service providers. Both of the Polycom VoIP extension phone sets came ...drumroll... out of the bins at Goodwill and cost around $15 each. Both originally started life out as RingCentral provided VoIP phones. I replaced their firmware with normal Polycom firmware and reconfigured them for use with my own system. If these required broadcasting that would be kind of difficult for RingCentral to be putting them into people's houses for use behind NAT-o-the-day routers to connect to RingCentral's SIP servers.

Second and much more important - bridging is almost NEVER appropriate on a WAN. There's a lot of stuff that broadcasts constantly and I do not need mDNSResponder packets from some POS iphone floating around on 1 network looking for an itunes server to be forwarded 80 miles away to another site. Having both sites the same network also means that IPv6 routing advertisements get forwarded and I've got 2 default gateways in this network, one of them at one site and one at the other. I don't need Internet-destination packets being forwarded through the VPN just so they can go out the router at the other site.

The reality is that the use of TCP broadcasting (and multicasting) is really being discouraged. While I am sure the network engineers over at the IETF are pissed as hell that their Bonjour view of the world is being rejected by admins the world over, and have a bazillion technical arguments why their way is better, even Microsoft has given up beating that dead horse now and has switched to DNS lookups for building browse lists and suchlike in Active Directory.

There's a reason Wireguard does not support bridged mode on OSI layer 2 interfaces - because bridged VPNs are stupid hacks. They should NEVER be used just because someone doesn't understand routing and they shouldn't be recommended for a WAN. The admin is only using them properly if the admin is embarrassed as hell to be using them and pissed as hell at some knuckle-dragging POS bit of equipment that is requiring them.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Wed Apr 21, 2021 16:58    Post subject: Reply with quote
You know what most users (should) do they read the manual.

I posted a link to the manual(s) where everything is explained, feel free to use it but if not then do not complain.

I do not have your router and build so cannot be 100% sure it supports CHACHA but you can simply test with:
Code:
root@R6400v1:~# openvpn --show-ciphers
The following ciphers and cipher modes are available for use
with OpenVPN.  Each cipher shown below may be used as a
parameter to the --data-ciphers (or --cipher) option.  The
default key size is shown as well as whether or not it can be
changed with the --keysize directive.  Using a GCM or CBC mode
is recommended.  In static key mode only CBC mode is allowed.

AES-128-CBC  (128 bit key, 128 bit block)
AES-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-GCM  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-192-CBC  (192 bit key, 128 bit block)
AES-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-GCM  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-256-CBC  (256 bit key, 128 bit block)
AES-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-GCM  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
CHACHA20-POLY1305  (256 bit key, stream cipher, TLS client/server mode only)

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Thu Apr 22, 2021 16:59    Post subject: Reply with quote
Both routers I am testing with show CHACHA20 as a listed cipher using the show-ciphers command. When selecting CHACHA20 as an encryption cipher I get the error I posted. I did not try selecting it as a data cipher. Beyond that if you want me to do more testing I can on my alternate router set.

The openvpn router guide only has a single line at the beginning saying openvpn needs a lot of cpu power. For starters that just isn't true - IF - all you want is basic connectivity. As I already stated it is possible to push TCP traffic over a link with devices with slower CPUs - such as 300Mhz - as long as you don't care about some packet loss. TCP does not - so it will work. UDP is more sensitive WITH CERTAIN APPS. For example DNS appears unaffected. Furthermore it appears that only RECENT versions of OpenVPN are CPU hogs because older circa-2016 versions of OpenVPN seem perfectly able to keep up with older/slower CPUs. Of course those older versions are insecure which is why I even started the process of upgrading.

Because the guide was written from the POV of someone testing with an 800Mhz CPU device you clearly did not stumble into the problem I did or you would have expanded and quantified that in the Guide. Obviously, you are free to take the postings here and distill the key data and add it to the Guide. You DID mention in the guide CGM is more efficient which I have found in my testing to be true also so that's good. But there may be users out there with slower routers who just need a quick OpenVPN setup for something and wouldn't be affected. Also, it appears (from my testing) that turning on or off the wireless has a great effect on OpenVPN dropping UDP traffic. You could mention that in the guide.

What I am discussing here affects VoIP phone traffic specifically because that traffic appears to be particularly sensitive to small amounts of UDP packet loss that is IGNORED by TCP (which is built on UDP) and ignored by many other apps that use UDP and are more tolerant of some loss. You can fault the makers of SIP phones if you want for being too sensitive but that's what we have to work with. Some phones are worse than others.

The fundamental problem with what I'm doing is that it is one of those breakages that doesn't break "for everything" It's sort of like one of those wall-wart power supplies that is marked 12v 2A but will only supply 750Ma at 12v but when called on the full 2A will only supply 10v and it will be dirty. Lots of people have tossed perfectly good routers because of that because they "test" the 12v supply by plugging it into something else that lights up and works so they conclude the supply is good and the router won't power up because it's failed.

Well you can setup OpenVPN on a 300Mhz CPU device and it will "work" for just about all data the user sends through it. Except for VoIP SIP. So the user tests with pings and a file transfer and - it works. They test with a phone and - it doesn't work. They therefore conclude the phone is bad and go on to post treatises about how SIP phones don't work over the Internet because of all the zillions of routers and types of lines Internet traffic goes through are incompatible with SIP. See what I mean?
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Thu Apr 22, 2021 17:52    Post subject: Reply with quote
Setting an encryption cipher is becoming deprecated.
It is still in the GUI for backwards compatibility with OpenVPN 2.3 and earlier and for some providers which have their own ideas of key negotiation.

You should use the data-ciphers as your server and client are running OpenVPN 2.5.

Pictures of settings are in the Open VPN Server setup guide and this is also mentioned in this thread:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=326913

So just set CHACHA as first data-cipher on both server and client and it should work.

OpenVPN is unfortunately demanding as you cannot even have wifi enabled on your router and most users use their router for providing Wifi also.
Of course you can run it on an WRT54GS with 2-3 Mb/s or on my E2000 with 5 Mb/s but most users will not be satisfied with that Sad

WireGuard because it is running in Kernel has roughly 3 times the throughput of OpenVPN and is easy to setup so is gaining in popularity Smile

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Fri Apr 23, 2021 1:38    Post subject: Reply with quote
egc wrote:

WireGuard because it is running in Kernel has roughly 3 times the throughput of OpenVPN and is easy to setup so is gaining in popularity Smile


Hmm well then I still say there's a GUI bug because it should not have CHACHA in the encryption cipher setting dropdown. But it's not a critical bug since OpenVPN just issues error messages and uses GCM. More of an issue is the "stealth" bug-but-not-really-a-bug I've documented here.

OpenVPN was once touted as the cat's meow back when the VPN of the day was PPP. Now Wireguard is occupying that spot. In the future some other will no doubt when Wireguard gets all bloated up like OpenVPN has. It's the Cycle Of Code.

I hear you on the WRT54g. I got rid of the last of mine about 6 years ago. But I still see current postings from people with them. People are stubborn.
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Mon Apr 26, 2021 12:00    Post subject: Reply with quote
Here is some more data. Tonight I tried a test, I replaced the ASUS N16 router acting as the OpenVPN server (and which has had stable SIP phone connections over it's OpenVPN vpn for the last week) with a different ASUS N16 router running yesterday's build of dd-wrt Big K30 and I started getting the random disconnect issues again. I then replaced that router with the original N16 and things went back to working. The configs were identical the only difference was the "bad" router was running big K30 the "good" router was running mega K2.6 I am going to try flashing the "bad" router with K2.6 and see if that helps. Possibly we have an issue with there being less CPU cycles available on the K30 builds vs the K2.6 builds for OpenVPN? Or there is some other build difference with OpenVPN on K2.6 The K30 build on the Netgear at the remote site is working fine.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Mon Apr 26, 2021 12:24    Post subject: Reply with quote
K2.6 is lean and runs faster.
Steve Jenkins has done a nice write up (his site is currently not available) on this of course K2.6 is EOL and has no security fixes any more and has no WireGuard etc.

Other thing Shortcut Forwarding Engine (SFE, not available on K2.6)) although it gives a much higher throughput, it can have latency issues so try with enabled and disabled.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum