Asuswrt-Merlin 386.3 is now available for all supported model. This release introduces major changes to OpenVPN client handling, and also introduces the ability to generate QR Codes to make it easier to connect your mobile clients to your Wifi network.
August 6th 386.3_2 is now available.
Code:- NOTE: closed down the Issue tracker on Github, as 90% of it was people asking for technical support, or failing to use the supplied submission form. - CHANGED: Re-disabled jitterentropy-rngd on non-HND models. It kept using CPU time every two seconds and had a very marginal impact on the entropy pool (which it never could push above the target threshold of 1024). - CHANGED: Moved the "Redirect Internet traffic" setting on the OpenVPN Client page to the Network Settings section to increase its visibility, as too many users are forgetting to configure it. - CHANGED: Display "Internet traffic not redirected" instead of "Public IP Unknown" on the OpenVPN Client status display when Redirect Internet traffic is set to "No". - FIXED: Only the first OpenVPN client would be used if you had multiple clients connected and the first one had a Redirect Internet set to "No". Now, setting this to "No" means that client's routing table will no longer get a default gateway configured, allowing traffic to be processed by other RPDB tables if there wasn't a matching route within that client's table. - FIXED: IPV6-compatible DNSFilter servers weren't properly configured in dnsmasq. - FIXED: DNSFilter client rules may get corrupted after a reboot.
NOTE: On first boot with 386.3, you must either force-refresh the browser page (shift-reload), or clear your browser cache. Failure to do so will prevent the new QR codes from being properly displayed, due to an old cached CSS.
The highlights of this release:
- QR Codes can now be generated both on the Network Map (first index page of the webui), and on the Guest Network page. QR Codes are supported by iOS as well as most modern Android mobile devices (see your device's documentation for more information on how to use it) making it easier to connect to a Wifi network.
- Introducing VPN Director, which replaces the previous per-client Policy routing rules with a centrally managed page. More details in the Wiki: https://github.com/RMerl/asuswrt-merlin.ng/wiki/VPN-Director.
- OpenVPN routing handling was rewritten, allowing the implementation of VPN Director, but also bringing additional fixes and improvements. Routes are now created by the firmware itself rather than by the OpenVPN process.
- OpenVPN DNS handling was revised, resolving various quirks and issues related to it
- Improved OpenVPN kill switch behavior, it can now be used with clients set to route All traffic through
- Component updates: nano (5.7), curl (7.76.1), dnsmasq (2.85-openssl), openvpn (2.5.3), getdns (1.7.0), stubby (0.4.0)
Please review the Changelog for more details.
Please keep discussions to this specific release. This thread will be locked after a while once the release feedback has died down.
Downloads are here.
Changelog is here.
Now there's a name.Welcome to the forums @flyingpretzels.
Yes I can confirm this behaviour with NordVPN and 8.8.8.8 and 8.8.4.4. I have compared the routing and iptables rules in various scenarios. I've even turned off DNSFilter and manually created my own DNS DNAT rules. Everything points to this being a DNS interception by the NordVPN server (London) I'm connected through.I asked NordVPN and they say they don't redirect 8.8.8.8 DNS queries. Can anyone try setting DNS filter to custom 8.8.8.8 and see whether that DNS server gets used correctly? For me if I set to 1.1.1.1 I see Cloudflare reported correctly on dnsleaktest but if I set 8.8.8.8 I see my VPN DNS reported (I have VPN DNS accept disabled but have VPN DNS set as custom 1).
Thanks for confirming. Just wanted to check it wasn't an issue with the firmware. Weird that they do that, right?Yes I can confirm this behaviour with NordVPN and 8.8.8.8 and 8.8.4.4. I have compared the routing and iptables rules in various scenarios. I've even turned off DNSFilter and manually created my own DNS DNAT rules. Everything points to this being a DNS interception by the NordVPN server (London) I'm connected through.
Aug 7 18:27:42 kernel: CONSOLE: 175295.097 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:28:07 kernel: CONSOLE: 175320.014 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:28:42 kernel: CONSOLE: 175354.699 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:29:07 kernel: CONSOLE: 175379.618 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:29:42 kernel: CONSOLE: 175414.400 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:30:07 kernel: CONSOLE: 175439.216 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:30:42 kernel: CONSOLE: 175474.001 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:31:07 kernel: CONSOLE: 175498.815 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:31:42 kernel: CONSOLE: 175533.598 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:32:07 kernel: CONSOLE: 175558.415 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:32:42 kernel: CONSOLE: 175593.200 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug 7 18:33:07 kernel: CONSOLE: 175618.015 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
May 5 01:05:08 syslogd started: BusyBox v1.25.1
May 5 01:05:08 kernel: klogd started: BusyBox v1.25.1 (2021-08-06 17:47:26 EDT)
I'm not entirely sure that's what's happening but I can't think of another explanation as there doesn't seem to be anything special about those IP addresses in the router's configuration.Weird that they do that, right?
I did ask NordVPN on support chat and the representative I spoke with said that she did not think any such redirection on 8 8.8.8 was applied by NordVPN. RMerlin uses NordVPN too. Maybe he has some idea.I'm not entirely sure that's what's happening but I can't think of another explanation as there doesn't seem to be anything special about those IP addresses in the router's configuration.
I only tried it with one NordVPN server. Maybe you can try a few different ones and see if they all behave the same.I did ask NordVPN on support chat and the representative I spoke with said that she did not think any such redirection on 8 8.8.8 was applied by NordVPN. RMerlin uses NordVPN too. Maybe he has some idea.
Yep, google sir.AC86U dirty upgrade to 386.3_2 from 386.3 and noticed the below log entry:
Aug 8 10:25:59 kernel: protocol 0800 is buggy, dev eth5
It is repeating itself in the log.
Any idea?
AC86U dirty upgrade to 386.3_2 from 386.3 and noticed the below log entry:
Aug 8 10:25:59 kernel: protocol 0800 is buggy, dev eth5
It is repeating itself in the log.
Any idea?
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!