Beta Asuswrt-Merlin 386.7 Beta is now available

[Jeffrey Young]

Has anyone attempted to use the Asus Wireguard implementation?
Too many Family members home for summer to attempt myself.

Also, B2 working well!

It was my understanding that the Asus implantation in the GUI was not ready. Do you have a Wireguard GUI with this Beta?

The kernel module and user space tool is there. I use both for my wireguard server implementation. Works well for me.

 

[capncybo]

Has anyone attempted to use the Asus Wireguard implementation?
Too many Family members home for summer to attempt myself.

Also, B2 working well!

Hey @Clark Griswald I think Jeff's response is correct but perhaps you were referring to "Asus Instant Guard" if so... It's only for mobile devices & lacks a desktop software client. But for Cell Phones, I've used it with success & it's ridiculously easy to get working.

 

[AurelM]

I've dirty upgraded a local Asus RT-AC68U HW ver. A1 from firmware 386.5_2 through both 386.7 alphas and both 386.7 betas. I've not discovered any issues.

Last night I've dirty upgraded a remote Asus RT-AC66U B1 (which uses the same firmware file as the RT-AC68U) from firmware 386.5_2 straight to 386.7_beta2 through vpn tunnel, with RT-AC68U acting as the OpenVPN server and RT-AC66U B1 acting as the OpenVPN client in a site-to-site configuration. After the automatic reboot, the vpn connection would be established, but I could no longer access the RT-AC66U B1, neither the WebUI through https, nor the shell/terminal through ssh.

A long time ago, preparing for bad things to happen, I've also setup a OpenVPN server on the RT-AC66U B1 and and can access it this way.
I've tried many things and looked at both the server and client configurations, as well as flash the 386.5_2 firmware back on the RT-AC68U. I've not flashed the remote RT-AC66U B1 because it is being used for internet services and so I can't just reboot it whenever I feel like it.

Finally I found that the OVPN chain in iptables's default filter table got separated to four different chains OVPNCF, OVPNCI, OVPNSF and OVPNSI and by adding the following ruleiptables -A OVPNCI -i tun11 -j ACCEPT to the RT-AC66U B1 I can access it again, when both routers run 386.7_beta2 firmware. Note: tun11 is because I use OpenVPN client 1 with a tun interface, not a tap one.

Is there something I can change in the WebUI on either or both routers to not use the iptables command or is it a bug?

Thank you RMerlin for the new releases.

 

[Howard_inGA]

Can't see any issues there! Does what RMerlin asked earlier apply to you?

https://www.snbforums.com/threads/asuswrt-merlin-386-7-beta-is-now-available.79282/post-769761

If an ISP provider restriction (Comcast) were correct, then I don't see how I am accessing it when I connect a PC directly to the modem?? I'm stumped!?

 

[Deleted member 22229]

If an ISP provider restriction (Comcast) were correct, then I don't see how I am accessing it when I connect a PC directly to the modem?? I'm stumped!?

Comcast does NOT block access to modem stats whether its rented or owned.

 

[BreakingDad]

Has anyone attempted to use the Asus Wireguard implementation?
Too many Family members home for summer to attempt myself.

Also, B2 working well!

Not the cousins ?

 

[RMerlin]

For the Open VPN configuration issue I cleared all browser cache, cookies etc and retried the page but still had the same error. Browser console shows the following errors:

Found it, thanks. This issue is only on the RT-AC5300 since it uses a different GPL from other models.

 

[eibgrad]

I've dirty upgraded a local Asus RT-AC68U HW ver. A1 from firmware 386.5_2 through both 386.7 alphas and both 386.7 betas. I've not discovered any issues.

Last night I've dirty upgraded a remote Asus RT-AC66U B1 (which uses the same firmware file as the RT-AC68U) from firmware 386.5_2 straight to 386.7_beta2 through vpn tunnel, with RT-AC68U acting as the OpenVPN server and RT-AC66U B1 acting as the OpenVPN client in a site-to-site configuration. After the automatic reboot, the vpn connection would be established, but I could no longer access the RT-AC66U B1, neither the WebUI through https, nor the shell/terminal through ssh.

A long time ago, preparing for bad things to happen, I've also setup a OpenVPN server on the RT-AC66U B1 and and can access it this way.
I've tried many things and looked at both the server and client configurations, as well as flash the 386.5_2 firmware back on the RT-AC68U. I've not flashed the remote RT-AC66U B1 because it is being used for internet services and so I can't just reboot it whenever I feel like it.

Finally I found that the OVPN chain in iptables's default filter table got separated to four different chains OVPNCF, OVPNCI, OVPNSF and OVPNSI and by adding the following ruleiptables -A OVPNCI -i tun11 -j ACCEPT to the RT-AC66U B1 I can access it again, when both routers run 386.7_beta2 firmware. Note: tun11 is because I use OpenVPN client 1 with a tun interface, not a tap one.

Is there something I can change in the WebUI on either or both routers to not use the iptables command or is it a bug?

Thank you RMerlin for the new releases.

Did you set the Inbound Firewall option on the OpenVPN client to Allow? (the default is Block).

IOW, site-to-site requires you allow inbound connections to the OpenVPN client to be established, which is denied by default.

 

[David Williams]

Upgraded dirty on AC3100, AC88U setup as Mesh nodes to Beta 2 and AX86U setup as Mesh Router to Beta 2 and all works fine so far. Thanks as always to all in this great forum.

 

[AurelM]

Did you set the Inbound Firewall option on the OpenVPN client to Allow? (the default is Block).

IOW, site-to-site requires you allow inbound connections to the OpenVPN client to be established, which is denied by default.

Thank you for your response. Yes, the OpenVPN client has Inbound Firewall set to Allow. I think that if it was set to Block, it wouldn't have worked with previous firmwares either. In 386.7_beta2 firmware, this settings changes only the default rule for chain OVPNCF from DROP to ACCEPT, which is referenced by the FORWARD chain. It doesn't touch the OVPNCI chain, which is referenced by the INPUT chain, which is where I made the change.

 

[eibgrad]

Thank you for your response. Yes, the OpenVPN client has Inbound Firewall set to Allow. I think that if it was set to Block, it wouldn't have worked with previous firmwares either. In 386.7_beta2 firmware, this settings changes only the default rule for chain OVPNCF from DROP to ACCEPT, which is referenced by the FORWARD chain. It doesn't touch the OVPNCI chain, which is referenced by the INPUT chain, which is where I made the change.

In all the time I've been working w/ the OpenVPN client on Merlin, at least up to the current official release (386.5_2), the *only* user-defined chain I've ever seen relative to the OpenVPN client is OVPN.

Chain OVPN (2 references)
pkts bytes target     prot opt in     out     source               destination      
    0     0 DROP       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0

This is the first time I've ever heard of these others you mention (OVPNCI, OVPNCF, etc.). So perhaps something has changed w/ the most recent beta that I'm unaware of. Or else there's something else in the configuration that's triggering these additional chains, something I'm NOT using.

P.S. This is why I do NOT recommend users put alphas and betas into productions systems.

 

[RMerlin]

This is the first time I've ever heard of these others you mention (OVPNCI, OVPNCF, etc.). So perhaps something has changed w/ the most recent beta that I'm unaware of. Or else there's something else in the configuration that's triggering these additional chains, something I'm NOT using.

Asus changed their firewall implementation for OpenVPN. To make it easier for me to merge future changes to firewall.c, I have also adopted their rule setup following the GPL merge. I'll check to see if this chain should also receive the same rule.

 

[AurelM]

In all the time I've been working w/ the OpenVPN client on Merlin, at least up to the current official release (386.5_2), the *only* user-defined chain I've ever seen relative to the OpenVPN client is OVPN.

Chain OVPN (2 references)
pkts bytes target     prot opt in     out     source               destination     
    0     0 DROP       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0

This is the first time I've ever heard of these others you mention (OVPNCI, OVPNCF, etc.).
[...]

Well, if it wasn't for this problem, I wouldn't have known it either.

[...]
So perhaps something has changed w/ the most recent beta that I'm unaware of. Or else there's something else in the configuration that's triggering these additional chains, something I'm NOT using.
[...]

Here's how it is in 386.7_beta2:

@Asus_RT-AC66U_B1:/tmp/home/root# iptables -S | grep OVPN
-N OVPNCF
-N OVPNCI
-N OVPNSF
-N OVPNSI
-A INPUT -j OVPNSI
-A INPUT -j OVPNCI
-A FORWARD -j OVPNSF
-A FORWARD -j OVPNCF
-A OVPNCF -i tun11 -j ACCEPT
-A OVPNCI -i tun11 -j ACCEPT
-A OVPNSF -d 192.168.2.0/24 -i tun21 -j ACCEPT
-A OVPNSI -i tun21 -j ACCEPT
-A OVPNSI -p udp -m udp --dport 1194 -j ACCEPT

[...]
P.S. This is why I do NOT recommend users put alphas and betas into productions systems.

I agree with you, however these are home routers, not business ones to be used in production environment. And if something went wrong, a 15 minute reset/firmware downgrade and reload of the saved settings and jffs partition would have been everything needed.
I used the 386.7 alphas and betas on the local router without any perceived issues for over 3 weeks and thought it was safe to use the latest beta on the remote router as well and beside this little hiccup, it seems this way.

Asus changed their firewall implementation for OpenVPN. To make it easier for me to merge future changes to firewall.c, I have also adopted their rule setup following the GPL merge. I'll check to see if this chain should also receive the same rule.

While writing this post, I just saw that the rule I added was already in the OVPNCF chain, I removed it and vpn still works, so a typo somewhere perhaps. This was already there -A OVPNCF -i tun11 -j ACCEPT and this I added -A OVPNCI -i tun11 -j ACCEPT.

 

[RMerlin]

Last night I've dirty upgraded a remote Asus RT-AC66U B1 (which uses the same firmware file as the RT-AC68U) from firmware 386.5_2 straight to 386.7_beta2 through vpn tunnel, with RT-AC68U acting as the OpenVPN server and RT-AC66U B1 acting as the OpenVPN client in a site-to-site configuration. After the automatic reboot, the vpn connection would be established, but I could no longer access the RT-AC66U B1, neither the WebUI through https, nor the shell/terminal through ssh.

Just to confirm that my understanding of iptables isn't flawed, I take it that your issue was with accessing the router itself, but accessing LAN devices was fine, is that correct?

 

[AurelM]

Yes, I couldn't access the router.
I didn't however test accessing lan devices since there aren't any configured over there. I mostly use this connection when I'm over there to access resources from my home. Sorry.

Edit: I now know what you meant, when I said I deleted the rule from OVPNCF (FORWARD) chain, I actually disabled access to the remote lan devices, so this rule needs to be there as well as another one in the OVPNCI (INPUT) chain.

 

[RMerlin]

Yes, I couldn't access the router.
I didn't however test accessing lan devices since there aren't any configured over there. I mostly use this connection when I'm over there to access resources from my home. Sorry.

Ok, no problem.

The theory is, the INPUT chain is what allows or denies access to the router itself. The FORWARD chain allows access to LAN devices. In your case, the problem is that the ACCEPT rule was added to the FORWARD chain, but not the INPUT chain.

I'll add it to the INPUT chain as well, but I will need to also review the server firewall rules to see if a similar scenario isn't also present.

And thanks for actually testing it. Nobody else reported it so far, so this issue would have most likely been present in the final 386.7 release, and a fix might have come only months later with 386.8. While he is correct that people shouldn't run beta code on a production network, it always comes down to your tolerance to disruptions. People willing to test beta releases are invaluable to this project, and each beta cycle always detects multiple issues that can then be fixed in time for the final release. For 386.7 I deliberately tried to keep changes to a minimum as I wanted to have a fairly short beta cycle, but as in this case, issues can also be introduced by new GPL merges.

 

[Alaska99]

After dirty update AX88U from 386.7 beta 1 to beta 2 all the 5ghz setting was reinitialized to default setting. WPS has been réenabled too.

 

[ardennguyen]

@RMerlin DHCP manual assignment seems not working with beta2 on my AX88U, I tried reset, still not working. It would disregard the manual entry and went for auto assignment.

 

[bluepoint]

@RMerlin DHCP manual assignment seems not working with beta2 on my AX88U, I tried reset, still not working. It would disregard the manual entry and went for auto assignment.

Manual assignment works here on an AX88U, what's not working?

 

[SheikhSheikha]

B2 running smoothly for several days now.