Beta Asuswrt-Merlin 386.3 beta is now available

[Stephen Harrington]

First boot post upgrade, I needed to change the VPN Client > Redirect Internet traffic through tunnel setting to VPN Director (policy rules) as it was initially set to No. Once this adjustment was made, everything worked fine and the VPN Director settings appear to be functioning as expected.

Had a similar experience but not quite the same when I upgraded to the Beta today.
I only have one device/one IP routed via Policy Rules through my NordVPN OpenVPN Client 1, my Synology NAS.
Initially after the upgrade "Redirect Internet Traffic Through Tunnel" was set to "VPN Director (policy rules)" which was as expected given my pre-upgrade setup with the "old style" Policy Rules.
However the VPN wasn't routing any data, despite it looking to be "up" and giving it a nudge by restarting it.
I had to set "Redirect Internet Traffic Through Tunnel" to "No", then hit "Apply", then set it back to "VPN Director (policy rules)" and hit "Apply".
After another restart of OpenVPN Client 1 it all came good, and has been fine through a couple of reboots I did to check.
Just a minor glitch in the upgrade process, but worth noting for others who may follow?

 

[maxbraketorque]

Create a firewall-start script with the two commands.

ok. Thanks again. I figured out how to add the script, so I'll give it a try.

 

[RMerlin]

Hello,
386.3_beta1 on AX88U causes disconnections with 5GHz WIFI (tested with notebook and smartphone). The WIFI Network is not available for about 20-30 seconds (the 5GHz Wifi disappears in the WIFI settings of the client and appears some seconds later again - this happened 2x within 30 minutes)
Does anyone have the same experience?
Now I have downgraded to 386.2_6 - I'm still testing but the connection is stable since 90 minutes.
Thank you
Kind regards
hababu

Again, as I have said before: there was ZERO wireless changes in 386.3. Your issue has nothing to do with the 386.3 update.

Your delay is most likely related to you using a DFS channel, which requires a one minute period of scan to ensure there is no radar within the selected channel.

 

[Markr87]

When android box shows no internet connection, does it have correct time? Because Android box must have correct time to have internet connection, it does this through NTP protocol. If your VPN server actively block NTP or UDP or its port, you won’t be able to sync time thus no internet connectio

I cannot reproduce your issue here, works fine for me when I exclude my tablet. Can you test using a PC instead of the Roku?

EDIT: I can actually see one scenario where it might be problematic: if your VPN provider uses a non-public DNS server. WAN clients aren't currently "excluded" from using it, this is actually a bug.

Can you try connecting your VPN, then running the following command?

/usr/sbin/iptables -t nat -I DNSVPN1 -s 192.168.1.100 -j RETURN

Replace DNSVPN1 by whichever instance you are using if it's not the first one, and replace 192.168.1.100 by the IP address of your Roku.

Then test again the Roku.

@sorachan VPN works great, again it's only when I try to go around the VPN that the Roku loses internet. BTW time is correct.

@RMerlin I am quite sure my goof here but this is my output.

Also @RMerlin I have tried out NordVPN and all systems go. Everything works with split tunnel. All apps work through the VPN as well, except Vudu . Nord seems slightly faster than Express as well so I will be sticking with Nord. If you think the problem I was having with Express could have been a bug I will gladly test for you.

 

[RMerlin]

Also @RMerlin I have tried out NordVPN and all systems go. Everything works with split tunnel. All apps work through the VPN as well, except Vudu . Nord seems slightly faster than Express as well so I will be sticking with Nord. If you think the problem I was having with Express could have been a bug I will gladly test for you.

Were you using the first VPN client? If not, adjust the number in DNSVPN to match the client you use, and also make sure you do have that client DNS mode set to "Exclusive".

 

[Markr87]

Were you using the first VPN client? If not, adjust the number in DNSVPN to match the client you use, and also make sure you do have that client DNS mode set to "Exclusive".

Okay, second time around this worked. Problem resolved.

 

[Seth Harman]

Upgraded my RT-AX88U last night to the beta. For the most part everything seems to work fine but I noticed something with VPN Director and I'm not sure if it's intended behavior or not.

I have 4 VPN clients configured but I only run 2 simultaneously; either VPN1 or VPN3 is running, while at the same time VPN4 is running and VPN5 is never running but it contained the kill switch in case all active VPNs go down (it doesn't anymore, I moved it to VPN4). Because of this setup I have duplicate rules for VPN1 and VPN3, and VPN4 had a catch-all rule to direct everything not already preempted by the rules in VPN1/VPN3 to send all remaining traffic out through VPN4, that rule was 192.168.1.0/24. Under this setup on the old firmware everything worked as intended.

Once I upgraded to the beta firmware I noticed any IP addresses with more than one VPN rule associated with it could no longer access the Internet. For example, because of some older rules on a few of the unused VPN clients I ended up with both a WAN rule and a VPN rule for the same IP address, plus had the catch-all rule associated with VPN4. The documentation for VPN Director says any client with a redirect all traffic rule will be the highest priority, then WAN rules, then rules in order from VPN1 through VPN5 which I believe means my catch-all rule in VPN4 should have preempted everything under the new structure. What I encountered was anything where the only applicable rule was the catch-all had Internet access and showed as the WAN IP address, but any IP address that also had any other rule associated with it had LAN access but not Internet access. So, for example, if 192.168.1.50 had a WAN rule in any client it would not be able to communicate with the Internet until I disabled the catch-all rule, conversely if I disabled the WAN rule it would work under the catch-all. As well, anything that had a WAN rule and a VPN rule also had LAN access only until I disabled 2 of the three rules (WAN, VPN, and catch-all). I've alleviated all of the issues by deleting the catch-all rule and ensuring all remaining IP addresses only have a single rule, but I'd like to have that catch-all rule in place in VPN4 for guest clients/new clients that connect to my network.

I've tested this and it is reproducible (I just did it now with my phone, I created both a WAN rule in VPN1 and a VPN rule in VPN4 and Internet access was blocked until I disabled one of those rules). All VPN clients are set to use VPN Director for their policy rules and all DNS settings are "Exclusive".

Am I just confused as to how this should be working?

Edit: I did some more testing. It appears I can have mutiple VPN rules for the same IP address and still access the Internet but if there's a WAN rule and at least one other VPN rule it blocks Internet access.

 

[RMerlin]

Okay, second time around this worked. Problem resolved.

Thanks, that confirms it. I already fixed the issue on my end, the fix will be included in beta 2.

 

[RMerlin]

Edit: I did some more testing. It appears I can have mutiple VPN rules for the same IP address and still access the Internet but if there's a WAN rule and at least one other VPN rule it blocks Internet access.

Probably related to the previous post, DNS exclusive doesn't properly exclude WAN clients. So if your VPN client uses a private DNS, WAN clients won`t be able to properly achieve DNS lookups as they will still try to use the VPN's DNS but over the WAN.

 

[Seth Harman]

Probably related to the previous post, DNS exclusive doesn't properly exclude WAN clients. So if your VPN client uses a private DNS, WAN clients won`t be able to properly achieve DNS lookups as they will still try to use the VPN's DNS but over the WAN.

Yeah, looks like that's it. I set up both a WAN and VPN1 entry for my phone and, low and behold, I could load website on it by using the IP address of them instead of the URL.

A follow-up question would be how I would be able to set up the catch-all I had in place before the firmware upgrade as it looks like doing so under VPN Director it will end up the highest priority instead of a lowest priority catch-all or am I misunderstanding how that works?

 

[RMerlin]

A follow-up question would be how I would be able to set up the catch-all I had in place before the firmware upgrade as it looks like doing so under VPN Director it will end up the highest priority instead of a lowest priority catch-all or am I misunderstanding how that works?

Rule order is this:

WAN
OVPN1
OVPN2
OVPN3
OVPN4
OVPN5

So the catch-all would have to be on the last VPN client on that list. This is actually identical to before, only that this time it`s explicitly documented (and that WAN rules are all globally applied first).

 

[Wisiwyg]

Thanks, that confirms it. I already fixed the issue on my end, the fix will be included in beta 2.

"Heh, heh, he said Beta 2..."
In my best Beavis & Butthead voice...

 

[Seth Harman]

Rule order is this:

WAN
OVPN1
OVPN2
OVPN3
OVPN4
OVPN5

So the catch-all would have to be on the last VPN client on that list. This is actually identical to before, only that this time it`s explicitly documented (and that WAN rules are all globally applied first).

Does it explicitly have to be VPN5 or simply the last *active* VPN client, which in my case would be VPN4 as I never run VPN5? I want anything not covered by a WAN or VPN1-VPN3 rule to go out by default on VPN4.

 

[RMerlin]

Does it explicitly have to be VPN5 or simply the last *active* VPN client, which in my case would be VPN4 as I never run VPN5? I want anything not covered by a WAN or VPN1-VPN3 rule to go out by default on VPN4.

Last active. Stopped client rules are not applied.

 

[Seth Harman]

Last active. Stopped client rules are not applied.

Thanks so much for taking the time to clarify all this for me.

 

[shabbs]

"Heh, heh, he said Beta 2..."
In my best Beavis & Butthead voice...

Put the kettle on...

 

[kernol]

Put the kettle on...

Polly?

 

[John Adler]

after the beta install my PIA stopped working
flashed back to the stable version, PIA working again
waiting for the next beta

 

[Sky1111]

after the beta install my PIA stopped working
flashed back to the stable version, PIA working again
waiting for the next beta

On my side PIA continues to work fine. Checked the IP address of the target system, all good. Speed seems to be same - measured by router, it is between 110-140, average ~120 Mbps (and this is on hard wired 1GB internet)

 

[rlucho]

Hi, i have a noob question... There is an official update for AX11000 (3.0.0.4.386_44266) where it seems they fixed stability issues (2.5G port unstability), are those fixes getting implemented here? Idk how merlin beta updates works for implementing fixes from official firmware. Thanks in advance!