(Preemptive, perhaps, but if you're taking about more than a few hundred Mbps over OpenVPN, you likely should be looking at x86-class hardware with AES-NI and/or hardware acceleration. Running 1 Gbps with NAT and SQM is pushing the limits of all-in-one router hardware, and that's before 1 Gbps symmetric.)
While this won't give you real world figures (by any means), the following pull request has some data for comparison:
If you are worried about throughput, consider using WireGuard:
1 Like
I doubt you'll much more than 100-140 mbit and that's with a core pegged looking at https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1073309&sid=2b02d17dec76fa32e90a7341496c343f#1073309 (macsbug) . OpenSSL acceleration will help but not much as the bottleneck isn't really the encryption itself rather than moving packages back and forth from kernel to userspace and the fact that it's single-threaded.
@AndyInNYC
Be aware that the R7800 (IPQ8*** platform) isn't fully stabile which may or may not affect you.
Just pipe the vpn through a virtualbox on a stick.... ( internal <> pseudointernal )
Same physical medium just two interfaces on the virtualbox both bridged to it.
One interface would also work.
I beg to differ here, the ipq806x platform is stable - I've had continuous uptimes of several months (and only interrupted by conscious firmware upgrades or power outtages/ blown fuses). There may be an issue with stmmac and certain packet sizes >= 1500 bytes, but you either have them (because your ISP modem is configured to use them), or your don't (and this issue is very likely to affect many more targets than just ipq806x, as stmmac is a very common IP core).
Sure, I'd expect my network device to crash when receiving packet sizes >= 1500 that sounds perfectly acceptable to me. As I mentioned "which may or may not affect you", if we#re going to sugarcoat we might as well claim that everything works great irregardless of issues...
I am not sugar coating anything, a bug is a bug - and this type of bug mustn't exist in the first place. But this is (most likely) also not a stability problem with ipq806x as a target (which would be hard to get fixed), but a problem with a very common networking driver for embedded platforms (e.g. sunxi and quite a few other targets are very likely to fail under the same conditions) - this doesn't make it better, but much more likely to get fixed (and it may already be fixed in 4.19).
And while this bug is a real problem, my router hasn't crashed in almost two years and there aren't (m)any reports for other ipq8064 or ipq8065 devices, which share the exact same hardware for years - so yes, either you have a WAN modem that triggers the bug or you aren't very likely to encounter the bug.
I'm not expecting to completely fill my pipe. I'm just looking for more throughput than my current WNDR3700 can supply (which is dog slow). I'm also running a really old version of OpenWRT on the WNDR and my OpenVPN version/setup is no longer supported by my iOS app.
I can't use any VPN other than OpenVPN with SHA256 - I have remote phones connecting into my system for the PBX, and Yealink only supports a limited range of options using its built in VPN software. SHA256 is (I think) the most robust cipher Yealink supports.
Rather than muck with the current setup, I thought I'd upgrade and have the old router to fall back on.
Any reason to keep the WNDR going and upgrade its software?
Andew
Good back-up router at "zero cost" to you.
Absolutely, yes! Echoing what @jeff said, it's always a good idea to have a back-up, especially if it is "zero cost" because you already own it. Since the WNDR3700 has hardware that is modern enough to install the latest version OpenWrt, then after you get the R7800 up and running, you could upgrade the WNDR3700 to 18.06 and then stick it on the shelf.
Subsequently, if the R7800 fails for whatever reason (e.g., infant mortality of the hardware, you accidentally brick the router try to set up something, router gets fried in a lightning strike, etc.), you can just pluck the WNDR3700 off the shelf, swap your Ethernet cables, power up, and boom, you're back in business while you try to troubleshoot the R7800.
I actually meant any reason to just keep using the WNDR post software upgrade - it is long in the tooth and I don't think new software will speed up OpenVPN.
Since I'm getting such good feedback, I'll keep going .
I'm looking at the R7800-100NAS, but haven't pulled the trigger (used from ebay).
Is there another comparable (proc speed, memory/storage, etc.) that I should broaden my search to include? Obviously I'll be using OpenWRT/LEDE and OpenVPN on the device.
Andrew
The ZyXEL NBG6817 is close to identical to the r7800 (no eSATA port, but larger flash).
1 Like
Wow, the ZyXEL is even more expensive. I actually don't need eSATA (nor really the USB - I won't be doing any direct attached storage).
Andrew
OpenVPN will benefit if you switch from OpenSSL to mbedtls actually and set -O2 as default optimization, not much but ~7-8% or so (192 AES) 
I'm not sure I can do this and have the Yealink phones still connect properly - Yealink is pretty sticky on what the phone will accept/do - hence the need for SHA256, for example.
I also don't know enough about anything you typed to understand what I can/can't do with the Yealink.
I can worry about optimization once I get it working with my FIOS and my phones.
Andrew
Sorry, that was a reply about your current MIPS box and OpenVPN (WNDR3700v4 like hardware), not sure if v1 and v2 scales all that well.
By Yealink I guess you mean VOIP phones, do you have several base stations or just one?
It tends to be slightly cheaper than the r7800 in europe, but not in north america.
The ZyXEL occasionally drops to $150 on Amazon (US), both through Amazon as well as marketplace sellers. You can track the price and see the history.
I have a Asterisk/FreePBX system running for home/business. I have several remote phones in other states. Yealink T46G (and others) have a built in OpenVPN component which allows the phones to register 'as if local' and avoids a lot of NAT and other issues - as well as being more secure.