Then your issue has nothing to do with the killswitch since it's only usable for Internet access.But i don't redirect it since i don't want to
I can't help you, I'm not really familiar with WIreGuard, sorry.If you have the time to sort out some workaround or maybe in the next fw i would really appreciate it.
Don't redirect the entire subnet. Exclude the router's own IP from it.Could you please advise on a solution to fix this VPN director issue? For now, I've reverted back to the older version.
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:
Code: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.
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:
Code: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.
So, it seems important to read full thread before posting, make sense?Just read that 10seconds before the post. Appreciate the quotes for others to find it.
@RMerlinThen 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.
- 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
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.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.
@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?
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.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
networkmap is closed source and since there was no GPL merge in this release, its code is completely unchanged from 388.7.Network map > clients [not view list button, icon above] now doesn't show all clients whereas it did before, seems intermittent.
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.Is it possible to exclude the router's IP from the kill switch configuration?
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.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.
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.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.
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.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.
@RMerlinNothing 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.
@eibgradSomething 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.
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.
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!