Release Asuswrt-Merlin 3004.388.8_2 is now available

[Daveo]

Dirty upgrade from 3004.388.7 to 3004.388.8 on RT-AX88U with no issues.

 

[shabbs]

Dirty upgrade from Beta to Release across all gear. So far so good. No issues off the hop.

 

[RMerlin]

But i don't redirect it since i don't want to

Then your issue has nothing to do with the killswitch since it's only usable for Internet access.

If you have the time to sort out some workaround or maybe in the next fw i would really appreciate it.

I can't help you, I'm not really familiar with WIreGuard, sorry.

Could you please advise on a solution to fix this VPN director issue? For now, I've reverted back to the older version.

Don't redirect the entire subnet. Exclude the router's own IP from it.

 

[Ste00]

Asuswrt-Merlin 3004.388.8 is now available for supported Wifi 6 models. This release implements a new VPN killswitch method, and fixes a number of issues.

Changes since 3004.388.7:

3004.388.8 (21-July-2024)
  - NOTE: RT-AX56U is exceptionally included in this release.
  - NEW: Rewrote VPN killswitch implementation.  The new method
         uses an always present routing rule to prohibit access to
         the main routing table, so it will be active even if the
         user manually stops a client.  Removing the prohibit rule
         requires disabling the killswitch on the webui.
         The rules are also created before WAN goes up, to reduce
         the risks of leaks between WAN going up and VPN connecting.

         *** Make sure to double check that you don't have any
         unwanted killswitch enabled if you have connectivity issues
         following the upgrade to this firmware.

  - NEW: Added killswitch support for WireGuard clients.
  - NEW: Added mDNS support to the router's local name resolution
         (nss).
  - UPDATED: Chart.js was upgraded from 2.x to 3.9, to share the
             same version used by Asus.  Any third party addon
             that used it will need to upgrade their charts to
             the new version.
  - UPDATED: wget to 1.24.5.
  - CHANGED: Removed stop/start and "Start with WAN" buttons from
             OpenVPN clients.  There is now just a single
             "Enable" option, which will immediately start the
             client when applying changes, and will also start it
             automatically when WAN comes up.  This is to reduce
             confusion, better integrate into SDN, and match how
             WireGuard clients already worked.
  - CHANGED: Allow text selection on the Wireguard Server settings
             page.
  - FIXED: JS error on Wifi 6e/7 models when toggling DDNS.
  - FIXED: Couldn't mount CIFS shares on the router for BCM4912
           devices.
  - FIXED: Wrong band shown when selecting the 5 GHz band on the
           WPS page for the GT-AXE11000.
  - FIXED: WPS page wouldn't properly detect if 6 GHz radio is
           disabled when selecting it for the GT-AXE11000
  - FIXED: Disabling IGDv2/pinhole support wasn't fully disabling
           IPv6 support.
  - FIXED: CVE-2024-3080 issue
  - REMOVED: Wifi Radar was removed (unsupported by Wifi 7 devices,
             and security issues cited by Asus in their own recent
             releases).

Please keep discussions on this specific release. The thread will be locked once feedback dies down.

Downloads are here.
Changelog is here.

Thanks for the update.

It seems things are missing and/or moved around with the removal of the ROG GUI option. This seems to have also created some bugs

Bug noticed so far:

- Network map > clients [not view list button, icon above] now doesn't show all clients whereas it did before, seems intermittent.
- Adaptive QOS > Web History > Export no longer works, does nothing.
-

Asuswrt-Merlin 3004.388.8 is now available for supported Wifi 6 models. This release implements a new VPN killswitch method, and fixes a number of issues.

Changes since 3004.388.7:

3004.388.8 (21-July-2024)
  - NOTE: RT-AX56U is exceptionally included in this release.
  - NEW: Rewrote VPN killswitch implementation.  The new method
         uses an always present routing rule to prohibit access to
         the main routing table, so it will be active even if the
         user manually stops a client.  Removing the prohibit rule
         requires disabling the killswitch on the webui.
         The rules are also created before WAN goes up, to reduce
         the risks of leaks between WAN going up and VPN connecting.

         *** Make sure to double check that you don't have any
         unwanted killswitch enabled if you have connectivity issues
         following the upgrade to this firmware.

  - NEW: Added killswitch support for WireGuard clients.
  - NEW: Added mDNS support to the router's local name resolution
         (nss).
  - UPDATED: Chart.js was upgraded from 2.x to 3.9, to share the
             same version used by Asus.  Any third party addon
             that used it will need to upgrade their charts to
             the new version.
  - UPDATED: wget to 1.24.5.
  - CHANGED: Removed stop/start and "Start with WAN" buttons from
             OpenVPN clients.  There is now just a single
             "Enable" option, which will immediately start the
             client when applying changes, and will also start it
             automatically when WAN comes up.  This is to reduce
             confusion, better integrate into SDN, and match how
             WireGuard clients already worked.
  - CHANGED: Allow text selection on the Wireguard Server settings
             page.
  - FIXED: JS error on Wifi 6e/7 models when toggling DDNS.
  - FIXED: Couldn't mount CIFS shares on the router for BCM4912
           devices.
  - FIXED: Wrong band shown when selecting the 5 GHz band on the
           WPS page for the GT-AXE11000.
  - FIXED: WPS page wouldn't properly detect if 6 GHz radio is
           disabled when selecting it for the GT-AXE11000
  - FIXED: Disabling IGDv2/pinhole support wasn't fully disabling
           IPv6 support.
  - FIXED: CVE-2024-3080 issue
  - REMOVED: Wifi Radar was removed (unsupported by Wifi 7 devices,
             and security issues cited by Asus in their own recent
             releases).

Please keep discussions on this specific release. The thread will be locked once feedback dies down.

Downloads are here.
Changelog is here.

Thanks for the update.

It seems things are missing [menu seems much smaller] and/or moved around with the removal of the ROG GUI option. This seems to have also created some bugs

Bug noticed so far:



- Network map > clients [not view list button, icon above] now doesn't show all clients whereas it did before, seems intermittent.
- Adaptive QOS > Web History > Export no longer works, does nothing.
- I did notice a message somewhere that wasn't translated into English very well but was previously, can't remember now but if I do I'll be back...

These were all fine in the beta that did include the ROG themed variant.

 

[Jeep]

Dirty upgrade from 3004.388.7 to 3004.388.8 on an RT-AX86U (not PRO), smooth sailing so far. Thanks as always!!

 

[Rhialto]

Just read that 10seconds before the post. Appreciate the quotes for others to find it.

So, it seems important to read full thread before posting, make sense?

 

[leonla]

Then your issue has nothing to do with the killswitch since it's only usable for Internet access.


I can't help you, I'm not really familiar with WIreGuard, sorry.

Don't redirect the entire subnet. Exclude the router's own IP from it.

@RMerlin

Thanks! I excluded the router's IP (192.168.1.1), everything started working smoothly again!

I needed to route specific devices: some to OVPN1, others to OVPN2, and the rest to OVPN3. (I used the 192.168.1.0/24 subnet in the previous version). Is it possible to exclude the router's IP from the kill switch configuration?

 

[eibgrad]

@RMerlin

- NEW: Rewrote VPN killswitch implementation.  The new method
         uses an always present routing rule to prohibit access to
         the main routing table, so it will be active even if the
         user manually stops a client.  Removing the prohibit rule
         requires disabling the killswitch on the webui.
         The rules are also created before WAN goes up, to reduce
         the risks of leaks between WAN going up and VPN connecting.

         *** Make sure to double check that you don't have any
         unwanted killswitch enabled if you have connectivity issues

Hmm, well that's interesting. IIRC, that was the original way it worked, and so many ppl complained about it, you changed it quite some time ago. So now we're back to the original way again.

 

[jetpack42]

Bug noticed so far:

- Network map > clients [not view list button, icon above] now doesn't show all clients whereas it did before, seems intermittent.

I don't think this is a Merlin problem, viewing clients via the list and/or the icon is very inconsistent in stock Asuswrt as well (across both standard and ROG versions of stock firmware). Its been a known problem for a long time. Rebooting the router may help temporarily.

 

[eibgrad]

@RMerlin

Thanks! I excluded the router's IP (192.168.1.1), everything started working smoothly again!

I needed to route specific devices: some to OVPN1, others to OVPN2, and the rest to OVPN3. (I used the 192.168.1.0/24 subnet in the previous version). Is it possible to exclude the router's IP from the kill switch configuration?

Something doesn't add up here.

The VPN Director rules are only applicable to routing, i.e., when you are attempting to access a destination *outside* the local network (e.g., the internet). Any *local* access (i.e., LAN to LAN) is unaffected. IOW, accessing 192.168.1.1 from 192.168.1.100 is NOT going to be affected by the VPN Director.

Now if it's the case that you're attempting to access the GUI *remotely* over the WAN (which is NOT recommended), NOW you have a problem. Since the router uses a DNAT to redirect input from the WAN ip to the LAN ip of the router, any replies will come from the LAN interface of the router. And should the LAN ip of the router be included in your VPN Director rule(s), those replies will be directed over the VPN, and you'll lose remote access to the GUI.

All that said, I don't recall you specifically indicating this was a case of remote access of the GUI. It sounded like a LAN to LAN issue, which as I said, shouldn't be relevant.

 

[RMerlin]

It seems things are missing and/or moved around with the removal of the ROG GUI option. This seems to have also created some bugs

Nothing was removed there. At build time I simply provide flag to enable the ROG UI for the compiled firmware. The build script will build the regular firmware, then compile a second time but with the ROG_UI enabled. This time I forgot to re-enable the ROG_UI setting, so the script only generated one of the two firmwares.

If you have just gone from ROG to regular UI, I recommend flushing the cache as a few cached files (mostly CSS and JS) will be different.

Network map > clients [not view list button, icon above] now doesn't show all clients whereas it did before, seems intermittent.

networkmap is closed source and since there was no GPL merge in this release, its code is completely unchanged from 388.7.

Is it possible to exclude the router's IP from the kill switch configuration?

Anything that's routed through a VPN client will be subject to the killswitch. Anything that is routed through the WAN won't be. So if you add a rule that routes the router's IP through the WAN, it won't be affected.

A killswitch cannot be selective. If a client is tied to a VPN, then that client is subject to the killswitch if it's enabled.

Hmm, well that's interesting. IIRC, that was the original way it worked, and so many ppl complained about it, you changed it quite some time ago. So now we're back to the original way again.

Not quite. The new implementation is now done through a dedicated prohibit routing rule that is there in permanence, so it will work 100% of the time, unlike the original implementation that could sometimes not get applied, because it relied on routing rules getting added specifically when a VPN went down or was turned off. Sometimes the router failed to notice that was happening, causing the killswitch to not be applied.

Now that there is no more separate Enable/Disable and Start options, it makes it possible to have a more permanent killswitch in place.

The behaviour might sound a bit similar (since manual stop will also kick the killswitch in), except that it's easier for the router to handle things as the two methods a VPN could get started are now merged into a single radio toggle. The implementation is completely different, the routing table rule is applied whenever the killswitch option is toggled, rather than when the VPN is enabled/disabled.

 

[RMerlin]

All that said, I don't recall you specifically indicating this was a case of remote access of the GUI. It sounded like a LAN to LAN issue, which as I said, shouldn't be relevant.

Some people access their router through the WAN IP and/or DDNS hostname, which means it will use the WAN IP through the NAT loopback. That's one scenario I can think of that might get caught by a killswitch.

 

[eibgrad]

Some people access their router through the WAN IP and/or DDNS hostname, which means it will use the WAN IP through the NAT loopback. That's one scenario I can think of that might get caught by a killswitch.

Ahh, good point. Hadn't considered that possibility. I was stumped, because as I said, LAN to LAN should be a non-issue. But NAT loopback does introduce a DNAT. That still suggests the OP is making the GUI accessible remotely. Not a good idea.

 

[RMerlin]

That still suggests the OP is making the GUI accessible remotely. Not a good idea.

Not necessarily. Some people use the DDNS hostname mostly because they want to use the Let's Encrypt SSL certificate even while being within the LAN.

 

[eibgrad]

Not necessarily. Some people use the DDNS hostname mostly because they want to use the Let's Encrypt SSL certificate even while being within the LAN.

Another good point. But doesn't that still require the WAN to be listening on the open port? It still sounds to me like the GUI is at least accessible over the WAN, albeit over https. I personally wouldn't expose the GUI even over https, let alone http. That's really the bigger issue for me at this point.

 

[leonla]

Nothing was removed there. At build time I simply provide flag to enable the ROG UI for the compiled firmware. The build script will build the regular firmware, then compile a second time but with the ROG_UI enabled. This time I forgot to re-enable the ROG_UI setting, so the script only generated one of the two firmwares.

If you have just gone from ROG to regular UI, I recommend flushing the cache as a few cached files (mostly CSS and JS) will be different.


networkmap is closed source and since there was no GPL merge in this release, its code is completely unchanged from 388.7.


Anything that's routed through a VPN client will be subject to the killswitch. Anything that is routed through the WAN won't be. So if you add a rule that routes the router's IP through the WAN, it won't be affected.

A killswitch cannot be selective. If a client is tied to a VPN, then that client is subject to the killswitch if it's enabled.

Not quite. The new implementation is now done through a dedicated prohibit routing rule that is there in permanence, so it will work 100% of the time, unlike the original implementation that could sometimes not get applied, because it relied on routing rules getting added specifically when a VPN went down or was turned off. Sometimes the router failed to notice that was happening, causing the killswitch to not be applied.

Now that there is no more separate Enable/Disable and Start options, it makes it possible to have a more permanent killswitch in place.

The behaviour might sound a bit similar (since manual stop will also kick the killswitch in), except that it's easier for the router to handle things as the two methods a VPN could get started are now merged into a single radio toggle. The implementation is completely different, the routing table rule is applied whenever the killswitch option is toggled, rather than when the VPN is enabled/disabled.

@RMerlin

Got it, thanks for explaining that. I've added 192.168.1.1 to the WAN interface (Iface WAN). Now I'm able to use 192.168.1.0/24 in OVPN3 without any issues. Thanks so much!

 

[leonla]

Something doesn't add up here.

The VPN Director rules are only applicable to routing, i.e., when you are attempting to access a destination *outside* the local network (e.g., the internet). Any *local* access (i.e., LAN to LAN) is unaffected. IOW, accessing 192.168.1.1 from 192.168.1.100 is NOT going to be affected by the VPN Director.

Now if it's the case that you're attempting to access the GUI *remotely* over the WAN (which is NOT recommended), NOW you have a problem. Since the router uses a DNAT to redirect input from the WAN ip to the LAN ip of the router, any replies will come from the LAN interface of the router. And should the LAN ip of the router be included in your VPN Director rule(s), those replies will be directed over the VPN, and you'll lose remote access to the GUI.

All that said, I don't recall you specifically indicating this was a case of remote access of the GUI. It sounded like a LAN to LAN issue, which as I said, shouldn't be relevant.

@eibgrad

Thanks for the clarification. Yes, I access the GUI remotely over the WAN, and that's where the issue arose. According to RMerlin, adding the router's IP to the WAN interface resolves this issue. I think he mentioned it's a different implementation now, ensuring the killswitch works consistently. I appreciate your insights into this.

 

[jksmurf]

I checked the thread for LED but couldn’t see a response, did anyone else who did a dirty upgrade that normally have the LEDs off in the Admin/System menu, also get their router starting up with the LEDs on and that “disable LEDs” switch toggled to off?

No biggie, but not had it happen before and it happened on both my RT-AX86U variants.

 

[m0rF1uS]

The new VPN killswitch is a beast! Absolutely amazing job!

 

[iBest]

Then your issue has nothing to do with the killswitch since it's only usable for Internet access.


I can't help you, I'm not really familiar with WIreGuard, sorry.

Don't redirect the entire subnet. Exclude the router's own IP from it.

Thanks for the info but you see, there's something in particular to this fw....
Since with previous one setup works.

Maybe some incompatibility code with WireGuard setup from accessing lan from a different subnet?
I'll stick to the old one for now , maybe some fix in the future.

Best of luck !