Release Asuswrt-Merlin 386.3 is now available

[Robert Tickle]

I just experienced a network anomaly. It is probably just a freak thing, but I figured I'd reported it in case others have had the problem. I first noticed there was an issue when four of my seven security cameras dropped off-line. I have relatively cheap security cameras so I figured I just need to power cycle the cameras. That didn't fix it, so I decided to reboot my network. Not only did that NOT fix the problem, it made it worse. My 5ghz network did not restart, but the 2.4ghz did. However, when I attempted to login to the router via the 2.4 channel, the router gave me the factory reset screen! I had to reconfigure my wifi channels and then everything was fine. I have not logged into my router in several days before this happened. I've never seen this happen before and hopefully I'll never see it again. I have no idea what caused this.

UPDATE: 20 Aug 2021 - Decided to bite the bullet and do hard factor resets (WPS resets) on both my routers. I saved screen prints of my setting because I didn't want to use a saved config file. After manually re-configuring back to all the setting I had before the resets, everything is working normally again. I had been doing "dirty upgrades" since 386.2_0. Is there a recommended limit on the number of dirty upgrades before you have to do a hard reset and manually configure?

 

[tgab_b]

Doing this is very simple: configure a VPN Director rule to redirect the whole subnet, and then add rules for the exceptions.

What is problematic is people also wanting to have VPN routing applied to the router itself, not just to their LAN. And one known bug where if you set a client to Redirect: No, then it will fail to process the other client rules that come after it - this is already fixed on my end and will be included with the next release.


An exception cannot be processed AFTER a rule. Once a rule is hit, a routing decision is made, and the rest of the routing tables are no longer processed.

The current implementation works perfectly fine for that scenario. People are mixing up a lot of different things here. One user's complain was that he needed port-based forwarding. Another was that he also needed the router itself redirected through the VPN. These are the special case that cannot be handled by VPN Director.

I don`t understand why some people are so confused. VPN Director was explicitly designed to provide you a very visual representation of all the rules in one single location, in the order they are applied. Just look at the VPN Director table, and read the rule one at a time, starting from the top. Does that rule match? If yes, then use the defined interface, and stop processing. It doesn't match? Then go on the the next rule in the list.

I believe VPN director functionality not as as simple as thought and require more working. Even very ordinary scenarios are not working. I did a full router reset and reconfigured manually, after painstakingly 2 hours, VPN director still fails to direct Transmission to VPN3.

With no option to disable VPN Director, I have to go back to 386.2.6.

Sadly, no one replied or came forward with some suggestion on my posts.

 

[RMerlin]

I believe VPN director functionality not as as simple as thought and require more working. Even very ordinary scenarios are not working. I did a full router reset and reconfigured manually, after painstakingly 2 hours, VPN director still fails to direct Transmission to VPN3.

Transmission running where? If it's on the router, then VPN Director can't help you because router traffic originates from the WAN IP rather than from the LAN IP.

That is NOT a "very ordinary scenario", in fact I have been advising for years against running a torrent client on your security gateway.

 

[tgab_b]

Transmission running where? If it's on the router, then VPN Director can't help you because router traffic originates from the WAN IP rather than from the LAN IP.

That is NOT a "very ordinary scenario", in fact I have been advising for years against running a torrent client on your security gateway.

Yes, it runs on the router, but I have bind it to an exclusive ip. My dhcp range start from 192.168,2.50-254 and Transmission is at 192.168.2.15. It used to be work fine just using Policy Routing.

 

[Lynx]

Add a VPN Director rule with the remote IP being the IP of the DNS server.

Automatically adding the server used by Exclusive mode is already planned, but if you also use other DNS servers, then you have to manually add rules for them. The automatic handling through Exclusive mode isn't implemented yet because I don't have any good way of doing so without creating multiple routing rules for every single client, which can grow exponentially complex as you start adding more rules.

Actually I just went ahead and did a test. There's no need for additional forced routes to be added. DNS Exclusive Mode gets applied before any routing is done, so the query that was aimed at your router will be properly redirected to the VPN's DNS server. Since the query will be coming from a redirected client, then the connection WILL be routed through the VPN. I tested by running my own DNS server on a remote VPS, and by using that VPS's IP for my VPN DNS. The client's DNS query that was sent to the router was properly sent to the VPS, and netstat showed the inbound connection came from the VPN's IP.

That's cool about the way the VPN DNS is handled. However DNS Exclusive doesn't play nicely with Diversion.

I still think it would be really nice to just have all LAN default to VPN and simply create any necessary WAN exceptions. Would be just great if VPN Director could be used to provide the WAN exceptions with 'redirect: yes' set. That's the safe option in terms of preventing leaks. But by way of exception only, traffic is routed through VPN.

 

[stamzrat10]

That's cool about the way the VPN DNS is handled. However DNS Exclusive doesn't play nicely with Diversion.

I still think it would be really nice to just have all LAN default to VPN and just create any necessary WAN exceptions. Would be just great if VPN Director could be used to provide the WAN exceptions with 'redirect: yes' set. That's the safe option in terms of preventing leaks. But by way of exception only, traffic is routed through VPN.

My division works (dns strict) until I enable or disable a rule. Then it breaks for all devices in the network.

Also transmission works for me under vpn.

I don't know how to explain this. I just hope that RMerlin will do his magic together with the diversion developer. I like the VPN Director. But if enabling /disabling rules causes abnormal dns behavior / leak, then diversion gets messed up and some other stuff down the road

 

[RMerlin]

Yes, it runs on the router, but I have bind it to an exclusive ip. My dhcp range start from 192.168,2.50-254 and Transmission is at 192.168.2.15. It used to be work fine just using Policy Routing.

It's still a bad idea. You are trying to secure your network by using a VPN, while at the same time running a public-fronting torrent client on the very device that provides security to your entire network. If that device gets compromised by a security flaw in transmission, then your whole network becomes compromised.

 

[Makaveli]

It's still a bad idea. You are trying to secure your network by using a VPN, while at the same time running a public-fronting torrent client on the very device that provides security to your entire network. If that device gets compromised by a security flaw in transmission, then your whole network becomes compromised.

100% agreed here not smart!

I never understood people running torrent apps directly on their routers. Seems like a waste of resources where the is a limited amount on the router. And a huge security risk as you pointed out.

 

[Lynx]

It is also kina cool just how flexible these routers are, even though running a Plex or Torrent server seems wacky.

 

[JGrana]

It is also kina cool just how flexible these routers are, even though running a Plex or Torrent server seems wacky.

Flexible due to Linux and Entware. Yes, but it's main purpose is routing/managing a network for the many clients such as PC's, servers, streamers, etc.
I tried miniDLNA years ago. Gave up. Too much overhead.

Two words if you want a similar but more powerful, cost effective and flexible "coprocessor"

Raspberry Pi

The Pi4 and Raspbian/PiOS make a great compliment to Asuswrt-merlin.

 

[tgab_b]

Still interested to know what is going wrong here:

0: from all lookup local
10101: from 192.168.2.100 lookup ovpnc1
10102: from 192.168.2.180 lookup ovpnc1
10301: from 192.168.2.180 lookup ovpnc2
10302: from 192.168.2.100 lookup ovpnc2
10501: from 192.168.2.15 lookup ovpnc3
32766: from all lookup main
32767: from all lookup default

Why 192.168.2.15 is getting routed thru ovpnc1? Can someone help?

 

[akamaka]

I just experienced a network anomaly. It is probably just a freak thing, but I figured I'd reported it in case others have had the problem. I first noticed there was an issue when four of my seven security cameras dropped off-line. I have relatively cheap security cameras so I figured I just need to power cycle the cameras. That didn't fix it, so I decided to reboot my network. Not only did that NOT fix the problem, it made it worse. My 5ghz network did not restart, but the 2.4ghz did. However, when I attempted to login to the router via the 2.4 channel, the router gave me the factory reset screen! I had to reconfigure my wifi channels and then everything was fine. I have not logged into my router in several days before this happened. I've never seen this happen before and hopefully I'll never see it again. I have no idea what caused this.

I have some similar issues from time to time where the WiFi drops and restarting the radio for either 2.4GHz or 5GHz restores the connection for all bands.
I am running FW386.2_6 on AI mesh with AX11000 main and an AC5300 client.

 

[RMerlin]

Still interested to know what is going wrong here:

0: from all lookup local
10101: from 192.168.2.100 lookup ovpnc1
10102: from 192.168.2.180 lookup ovpnc1
10301: from 192.168.2.180 lookup ovpnc2
10302: from 192.168.2.100 lookup ovpnc2
10501: from 192.168.2.15 lookup ovpnc3
32766: from all lookup main
32767: from all lookup default

Why 192.168.2.15 is getting routed thru ovpnc1? Can someone help?

I see no way this could be happening, unless the two VPN tunnels are conflicting/overlapping.

 

[tgab_b]

I see no way this could be happening, unless the two VPN tunnels are conflicting/overlapping.

Is there any way to find VPN tunnels conflict? Can I run some commands and provide you output to check?I have went back to 386.2.6 and still same issue.

I did the full reset of router and even re-formatted USB disk and installed everything from scratch. No back-ups restored.

Seems like some other issue and ofcourse not related to VPN Director.

 

[JTnola]

Thanks for your answer. Yes, in fact the test I did is to disable the VPN manually with this button and the Killswitch did not work :
View attachment 35215
I hope that in case of real cut the connection will be cut because on the previous version, the manual deactivation of the VPN cut the connection well. So my rule is correct in VPN Director ?

Not so incidentally, this is the way the kill switch works in the actual PIA VPN app, too: If your VPN disconnects and the kill switch was on, the kill switch prevents the device from accessing the internet. If, however, you disconnect manually … the kill switch is not triggered.

 

[TITAN]

I am settings up a site-to-site VPN using OpenVPN, only 2 IP's are required, however I am unable to set a /31 (255.255.255.254) or /30 (255.255.255.252) subnet. Just wondering if there is a reason that Merlin doesn't allow this?

 

[BreakingDad]

Just reverted to 386.2_6 , Since installing 386.3 I've noticed my download speeds are slower, and 1 pc on my network on ethernet is disconnecting. I've also removed VN Stats and YazDHCP as I decided I don't really need them. The aim, stability and simplicity. I also noticed a lot more log action on the new firmware, especially on reboot. I found 386.2_6 really stable and I don't need any of the VPN bells and whistles that have been added. So I feel this firmware is not working for me. Will skip this one for now.

 

[RMerlin]

Just reverted to 386.2_6 , Since installing 386.3 I've noticed my download speeds are slower, and 1 pc on my network on ethernet is disconnecting. I've also removed VN Stats and YazDHCP as I decided I don't really need them. The aim, stability and simplicity. I also noticed a lot more log action on the new firmware, especially on reboot.

None of these are related to the 386.3 changes, since it's the exact same GPL code, exact same Broadcom SDK as 386.2_6.

 

[BreakingDad]

None of these are related to the 386.3 changes, since it's the exact same GPL code, exact same Broadcom SDK as 386.2_6.

Yeh figured that was probably the case, might have another go at weekend.

 

[Lynx]

I found a bug I think.

Try entering any custom DNS in DNS Filter in custom 3, i.e. the third box. Assign it to a device. Observe that the custom set DNS is not applied.

Would anyone here be willing to confirm please?