What's new

[Dev] Asuswrt-Merlin 388.1 development

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
The more I work with Wireguard, the more I dislike it.

- No way to get any actual debug logging unless running Kernel 5.6+ (or if there is, no documentation mentions it, they all talk only about kernel debugging with 5.6+) Makes debugging anything a big guessing task.
- No concept of a "client disconnecting" - once a peer (client) contacts another one (server), it will stay forever there, with no way of knowing that the "client" has disconnected - that's because to Wireguard, there are no client and servers connecting, just peers talking to one another

Wasted a few hours last night implementing and testing reporting connected "Clients", until discovering that it's useless because clients never truly go away. So that VPN Status code will have to be half scrapped.

And that's on top of the fact that it's incompatible with NAT hardware acceleration, that it uses a cypher that has no hardware acceleration, and that various VPN providers require a custom implementation and/or don't provide any downlodable config file to configure it manually. Asus had to implement dedicated support for NordVPN and HMA, which I will most likely not be offering in Asuswrt-Merlin since it's part closed-source, and part tied to VPNFusion, which I don't support.

Frankly, nothing but drawbacks from a router's point of view when compared to OpenVPN, or even IPSEC.
 
Last edited:
it is not very clear who and why is pushing WG into Asus as a VPN service. Why is he? (Keenetic?)
 
Broadcom sdk runs a much older Linux kernel some even older except for select models, asus or whomever wants WG in asus routers would have to develop with all these drawbacks. Not being able to detect client disconnects seems like a big no for me. Personally I want to be able to tell if a client is accessing the router or if I’m connected to a wg vpn. No debugging also feel like a pain. Only thing that makes me want wg is the supposed performance benefit, and the fact that iOS has issues with leaking ip or so I’ve heard using openvpn.

OpenVPN should start using quic or http3 which uses udp instead of tcp. Supposedly is possible.

 
Last edited:
it is not very clear who and why is pushing WG into Asus as a VPN service. Why is he? (Keenetic?)
A lot of people have been asking for it for years now, in part because they hear how fast it is (turns out for a router it's not THAT fast).

OpenVPN should start using quic or http3 which uses udp instead of tcp. Supposedly is possible.
OpenVPN can also use UDP.

HTTP3 has nothing to do with that, as it`s a layer 7 protocol, while TCP/UDP are layer 4. OpenVPN uses plain TLS, with its own protocol encapsulated within that session.
 
A lot of people have been asking for it for years now, in part because they hear how fast it is (turns out for a router it's not THAT fast).


OpenVPN can also use UDP.

HTTP3 has nothing to do with that, as it`s a layer 7 protocol, while TCP/UDP are layer 4. OpenVPN uses plain TLS, with its own protocol encapsulated within that session.
Yeah I only mentioned http3 as it’s packaged with quic which will eventually replace tcp.
 
Yeah I only mentioned http3 as it’s packaged with quic which will eventually replace tcp.
There is no real benefit to change the layer 4 protocol there. Any protocol level improvements to OpenVPN would be at a higher level. Even improving TLS to reduce the number of round-trips would add about no benefit, since OpenVPN uses a persistent connection, unlike a website where you might need to open connections to 10-15 separate servers to retrieve the website content and that of all the various external resources present within the page, such as banner ads or Google-hosted content.

OpenVPN's next real step forward is the current work to offload the data handling portion to the kernel, which would reduce context switches, and allow to better leverage hardware-acceleration beyond just CPU operands.

 
There is no real benefit to change the layer 4 protocol there. Any protocol level improvements to OpenVPN would be at a higher level. Even improving TLS to reduce the number of round-trips would add about no benefit, since OpenVPN uses a persistent connection, unlike a website where you might need to open connections to 10-15 separate servers to retrieve the website content and that of all the various external resources present within the page, such as banner ads or Google-hosted content.

OpenVPN's next real step forward is the current work to offload the data handling portion to the kernel, which would reduce context switches, and allow to better leverage hardware-acceleration beyond just CPU operands.

Ah okay that makes sense. Thanks for the explanation.
 
And I do have another improvement idea in mind for VPNDirector, and will probably experiment with in 388.1.

I fully enjoy your VPN Director development - so real pleased you will retain and hopefully extend.

I am really hoping you will bring the feature previously offered by this developer - namely the ability to direct to a VPN by desired destination. In other words - any client device wanting say "Netflix" services would be routed through VPN Client3 for those services but would remain routed through default WAN [or other designated VPN] for everything else.
 
I too have been wondering where the massive hype surrounding Wireguard has been coming from. Yes, in some applications it can be faster than OpenVPN, but it's amazing how it has consumed a large percentage of popular perception that it is a Must Have Now.

Meh...
 
I too have been wondering where the massive hype surrounding Wireguard has been coming from. Yes, in some applications it can be faster than OpenVPN, but it's amazing how it has consumed a large percentage of popular perception that it is a Must Have Now.

Meh...
Remember Shadowsocks? It also generated tons of buzz at the time.
 
I am really hoping you will bring the feature previously offered by this developer - namely the ability to direct to a VPN by desired destination. In other words - any client device wanting say "Netflix" services would be routed through VPN Client3 for those services but would remain routed through default WAN [or other designated VPN] for everything else.
There`s no clean, reliable way to achieve this, so I have no plan on implementing it. Involving dnsmasq, ipset and iptables in the equation means it will break too easily, for example whenever someone uses something else than their router as their resolver. This is best left as an addon, where someone installing it would fully be aware that it may not work as expected.
 
There`s no clean, reliable way to achieve this, so I have no plan on implementing it. Involving dnsmasq, ipset and iptables in the equation means it will break too easily, for example whenever someone uses something else than their router as their resolver. This is best left as an addon, where someone installing it would fully be aware that it may not work as expected.
Great logic ... as usual ... understood and thanks for the speedy response.
 
About WireGuard, it is usually three times as fast as OpenVPN, very easy to setup, very robust and supported by most VPN providers nowadays (with some tricks you can use NordVPN).
I have a DDWRT router which runs WireGuard and that has CTF+FA enabled (which is the DDWRT Hardware flow acceleration ), so yes it would be nice to have.
 
About WireGuard, it is usually three times as fast as OpenVPN, very easy to setup, very robust and supported by most VPN providers nowadays (with some tricks you can use NordVPN).
I have a DDWRT router which runs WireGuard and that has CTF+FA enabled (which is the DDWRT Hardware flow acceleration ), so yes it would be nice to have.
Running Wireguard on a desktop might be roughly three times faster than OpenVPN (maybe), but I have yet to see a consumer router that can achieve a that kind of improvement, at best it seems to approach double the speed. Still impressive, but not the same.
 
There`s no clean, reliable way to achieve this, so I have no plan on implementing it. Involving dnsmasq, ipset and iptables in the equation means it will break too easily, for example whenever someone uses something else than their router as their resolver. This is best left as an addon, where someone installing it would fully be aware that it may not work as expected.
same reasoning applies to the functionality in YazFi I imagine?
 
Running Wireguard on a desktop might be roughly three times faster than OpenVPN (maybe), but I have yet to see a consumer router that can achieve a that kind of improvement, at best it seems to approach double the speed. Still impressive, but not the same.
My router goes from 35 Mb/s OpenVPN to 105 Mb/s on WireGuard measured with iperf3, dual core 800 MHz ARM A9 (e.g. Asus AC68)
 
For me, OpenVPN provides all I need as it will max out my 100/10 connection on my (soon to be) obsolete AC86U. :)
 
About WireGuard, it is usually three times as fast as OpenVPN,
Not on a router.

very easy to setup
OpenVPN involves exporting a config file, and importing on a client - just as easy.

same reasoning applies to the functionality in YazFi I imagine?
I don`t know what Yazfi does. I do have plans to investigate a potential way of allowing VPNDirector to also deal with interfaces rather than just IP addresses, if that's what you mean.
 
My router goes from 35 Mb/s OpenVPN to 105 Mb/s on WireGuard measured with iperf3, dual core 800 MHz ARM A9 (e.g. Asus AC68)
That is a worst case scenario however, as that CPU lacks AES acceleration. A modern router with AES acceleration can hit 220-250 Mbps with OpenVPN on a 1 Gbps WAN link, while WG might hit 300 Mbps but limit that 1 Gbps WAN link to only 400 Mbps of max WAN throughput. And since WG uses Chacha20, it cannot leverage any of the existing cipher hardware acceleration technologies available.

And once OpenVPN gets DCO finalized, it should in theory also allow OpenVPN to leverage a hardware SPU, which means both lower CPU usage and higher throughput. Or you can go for just higher throughput by leveraging multithreading instead of an SPU, but with a higher CPU usage.
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top