Joined: 16 Jun 2006 Posts: 134 Location: Germany, BW
Posted: Wed Jun 07, 2023 11:27 Post subject: OpenVPN best Firmware-Version
For the last two weeks I tested OpenVPN Site-to-Site TUN and also TAP.
On my old Buffalo WLA2 I used 36247 and on the old (but newer) ASUS RT-N16 45229.
Of course speed was bad, but it worked in all configurations.
Now I want to do it on newer Hardware (looking for hardware with AES support) and try to find out the best firmware version for OpenVPN.
Tried my best on searching forum and internet but still not sure which FW to install.
If your after pure site to site speed you should use Wireguard, regarding your question, OVPN is very hardware dependant, meaning a fast CPU is required to give you good throughput, I've never noticed much OVPN speed difference what ever version I've used, as I say its more about pure under the hood grunt with OpenVPN, basically the faster your download speed is the faster CPU you require to keep up the encryption and decryption, this will apply at both ends with site-to site. _________________ Netgear R7800 PPPoE Main Router
Network IPV4 - Isolated Vlan's with IoT Devices. Unifi AC-Pro x 3 AP's, Router Wi-Fi Disabled. OVPN Server With Paid Commercial Wireguard Client's. Gateway Mode, DNSMasq, Static Leases & DHCP, Pi-Hole DNS & Running Unbound.
No one can build you the bridge on which you, and only you, must cross the river of life!
Joined: 16 Jun 2006 Posts: 134 Location: Germany, BW
Posted: Wed Jun 07, 2023 22:13 Post subject:
I read all the guides.
The docus for DD-WRT became better, but as I'm used to since 18 years, some GUI settings are not explained, for the Bridge-Explanation you have to know how it works before you read that aso.
I don't understand why Wireguard-Bridging mode needs the Public IP from the client. How should this work if you use this for traveling purposes?
As I know OpenVPN since years I was lucky not to need the guides to understand the concept and so it was easy for me to setup.
OpenVPN supports Bridging without 3378 tunnel within the VPN tunnel, the client can connect from everywhere without Server needs to have config-entry from Clients external IP.
And to compensate the performance benfit from Wireguard its better to pay 100 Euro more for AES supporting Hardware like Linksys WRT32X or better a NanoPi R6C than to spend 10-15 hours to get through the DD-WRT Wireguard Docus and have to google and search Forum for the missing setup steps.
What I liked in the Wireguard GUI is the easy way to configure the split tunneling for destinations not to connect via VPN. In OpenVPN you need client allow-pull-fqdn and Server push route net_gateways.
I go with OpenVPN and try the newest FW I just installed on two Routers.
WireGuard itself does not support bridging from the documentation:
Quote:
Some key points about WireGuard:
• Layer 3 only no bridging
• UDP only punches through firewall
• Like SSH authenticated keys
• Executes in Linux Kernel
• Static routing
I created a bridging solution by following the instructions of the WG Advanced setup guide by adding another RFC3378 Ethernet over IP tunnel.
But it is certainly more work than using OpenVPN/TAP
Joined: 16 Jun 2006 Posts: 134 Location: Germany, BW
Posted: Tue Jun 13, 2023 9:16 Post subject:
Yes I read this with the 3378 tunnel within the normal tunnel. I'm wondering if this double tunneling is not killing the speed advantage of Wireguard.
The big mess with OpenVPN is the missing support of AES with most Router-Hardware. You can do some fine-tuning with MTU and Cert settings, but at least you are screwd without CPU-AES-support.
But in "normal"-use-modus with PC or Phones, WireGuard is the best solution.
If I wouldn't need a Bridge because of a special requirement I would also use WireGuard for routing.
The 33387 tunnel has no encryption so does not hamper speed that much.
The problem with OpenVPN is not the encryption it is the constant switching between userland and kernel space and less important the fact that it is single threaded.
WireGuard lives in kernel space and that is what makes it so much faster even without AES hardware acceleration (which typically does not work for CHACHAPOLY anyway).
OpenVPN 2.6 tries to mimic that with DCO (Data Channel Offload) but that is only available on Kernel 5.15 and higher, so not coming on a router near you unless it can be back-ported.