WDS is not being used and wps is disabled. It is being used as a standard repeater.
This AP you pulled out was it an ASUS wireless router in repeater mode? If not then it does not apply to this issue.
Last edited:
Repeater connected to Guest SSID bypassing Access Intranet = Disable
- Thread starter hiluke88
- Start date
This AP you pulled out was it an ASUS wireless router in repeater mode? If not then it does not apply to this issue.
drinkingbird
Part of the Furniture
From what @guetech posted from the logs, it is using WDS. I guess even if it is disabled it is getting used, which if so, is a bug for sure. Doesn't seem to be an issue on the AC68U so maybe it is only with the HND chipset routers.
Of course anyone with bad intentions can crack your main wifi in a few minutes with readily available utilities anyway so it isn't like we're talking high security to start with here.
If you're concerned with malicious users, time to go to professional gear. If you want to isolate IOT or guest stuff and aren't worried about your neighbors trying to hack you, Aimesh is the solution for that, or you can run a script to move the WDS interfaces that are getting created into the proper bridges.
@RMerlin - do you know why Asus is using WDS when it sees its own brand repeater connect, even if WDS is not configured? Something related to AImesh?
Thank you for acknowledging it. I understand that if this is a big issue for someone that they should be using better equipment but that does not mean that Asus should ignore it. In the corporate world this would be a huge concern and a company like Cisco would have it fixed within days.
ColinTaylor
Part of the Furniture
I don't believe it is using WDS. wds1.1.1 is just the name of the interface. Even if it wanted to use WDS it would only be able to do so if it was enabled on the primary router, which we have been assured it isn't.
drinkingbird
Part of the Furniture
Maybe not officially wds but it is creating a new interface for that repeater only when it is an asus router. Maybe it is part of the aimesh discovery process and preparing it for setup? Must be a way to completely disable aimesh on these things?
ColinTaylor
Part of the Furniture
It would be more useful seeing the log activity on the primary router rather than the repeater as that is where the guest isolation is taking place.
The log from my post here was taken from the primary router, it shows what happens when the repeater connects to it.
All this talk about WDS is a red herring because both repeater mode and aimesh use a modified WDS that is unrelated to enabling/disabling WDS in the GUI on the primary router.
By the way I found a possible solution: Apply the same ebtable rules on interface wds+ that Asus puts on wlX.X when intranet is disabled:
Code:
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROPThose rules need to be reapplied when wireless is restarted and will break AiMesh if you use it.
ColinTaylor
Part of the Furniture
Sorry, my mistake. I thought it was from the repeater because none of those wds interfaces exist on my router that's also running a guest network. So if you haven't enabled WDS it must be being enabled in some other way as alluded to by @drinkingbird.
The interface is automatically created when the repeater connects, it isn't present before that.
Edit: Let me know if I can enable a more verbose logging mode to follow more closely what happens when the repeater connects to the primary!
Last edited:
ColinTaylor
Part of the Furniture
I configured my old RT-AC68U as a repeater and confirmed your findings.
When my repeater connects to the router's guest Wi-Fi it creates another wireless interface (wds0.2.1) and adds it to the bridge br0. But it doesn't make any changes to ebtables so there's no LAN isolation.
I think the creation of the new interface is happening somewhere within the wireless driver. I initially assumed that there was some client/server communication happening between the two devices but that doesn't appear to be the case as there is no IP configured on the connection (tcpdump sees only two broadcast packets over the interface).
I don't know at what point the router creates the normal ebtables isolation rules. I'd guess that this would be a separate userland process that happens after an interface is created rather than being part of the wireless driver code. If that's the case then that code was probably never written to take account of guest isolation for an Asus repeater.
Code:
May 4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May 4 01:17:34 wlceventd: wlceventd_proc_event(469): wl0.2: Deauth_ind 30:5A:3A:C7:8A:21, status: 0, reason: Unspecified reason (1)
May 4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May 4 01:17:34 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 IEEE 802.11: associated
May 4 01:17:34 wlceventd: wlceventd_proc_event(534): wl0.2: Assoc 30:5A:3A:C7:8A:21, status: Successful (0)
May 4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 RADIUS: starting accounting session 666B8932B21C30B8
May 4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 WPA: pairwise key handshake completed (RSN)
May 4 01:17:35 kernel: wfd_registerdevice Successfully registered dev wds0.2.1 ifidx 1 wfd_idx 0
May 4 01:17:35 kernel: device wds0.2.1 entered promiscuous mode
May 4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May 4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May 4 01:17:36 kernel: device br0 entered promiscuous mode
May 4 01:17:52 dnsmasq-dhcp[2965]: DHCPDISCOVER(br0) 30:5a:3a:c7:8a:20
May 4 01:17:52 dnsmasq-dhcp[2965]: DHCPOFFER(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May 4 01:17:52 dnsmasq-dhcp[2965]: DHCPREQUEST(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May 4 01:17:52 dnsmasq-dhcp[2965]: DHCPACK(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May 4 01:19:35 kernel: device br0 left promiscuous mode
Code:
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.f02f749237d8 no eth1
eth2
eth3
eth4
eth5
eth6
eth7
wds0.2.1
wl0.2
# ebtables -t broute -L
Bridge table: broute
Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
Last edited:
drinkingbird
Part of the Furniture
You also want to move the wds interface over to the guest bridge (br1 in the case of 192.168.1.1), just need to toy with the best script to put it in, probably one of the service-event ones. That way the IPtables rules get applied also since they are against the br1 interface. The ebtables rules allow all UDP through and will also allow ping of the router interface (not a big deal on the second one, but the first you want to block, which the IPtables rules do, with the exception of DHCP and DNS).
EDIT Sorry I forgot you are using GW2/3 - disregard. The necessary iptables rules are already in place since they all share BR0.
Make sure you delete your rules with -D prior to doing -A. Otherwise you can end up with many copies and could become an issue (each time the script is called it adds them and does not overwrite) and the firewall-start script gets called twice at startup and when you do other things also, and service-event ones can get called many times.
My guess is that it is still related to Aimesh, even if you aren't enabling it, it is making itself discoverable, or expecting that you are going to configure aimesh or something. There is probably some process you can kill at startup or maybe NVRAM value you can change to prevent this behavior alltogether.
If you don't want devices on the repeater to be able to see each other, enable AP isolation on that (same thing asus does on guest). Or maybe that setting is being propagated by this phantom aimesh, who knows.
Last edited:
drinkingbird
Part of the Furniture
So it is re-applying a second copy of the ebtables rules but using the wrong interface. This must be some sort of leftover from either early aimesh or some auto-WDS or auto mesh that they had at some point and forgot about/didn't update.
Probably be more fruitful to find a process that can be killed at some point during startup but I guess as long as EBTABLES rules are added with the "+" it will cover any Asus repeater that gets added.
ColinTaylor
Part of the Furniture
No, the duplicated rules can be ignored as they're nothing to do with this problem. They're present even when the repeater isn't connected, and I don't use AiMesh. My firmware is rather old now so it's likely this glitch has since been corrected. I'll edit my post to remove those lines to avoid future confusion.
drinkingbird
Part of the Furniture
Ah, yeah I only have one copy on mine, figured it was adding those when you added the repeater.
I had the same feeling so I tried dropping traffic to cfg_server (UDP 7788 and TCP 7788) and infosvr (UDP 9999) on the primary to see if it would help.
The primary no longer knew the SSIDs of the repeater (they were visible in nvram show before) and no longer knew it was an AX-55, so that's something. Unfortunately the wds still ended up in br0 with no ebtables restrictions. (I also tried again connecting the repeater to guest 1 but it still ends up in br0 instead of br1/2).
It's possible my rules weren't perfect or that there are more processes at play (/usr/sbin/asusdiscovery seems to start during the pairing but it doesn't run long enough for me to see if it listens or sends anything).
I took your advice and did some tests to see what still goes through. Asus rules were indeed leaky, so I improved a bit. I also looked for the best script to apply the new rules, which seems to be service-event-end when $2==wireless and firewall-start.
Code:
#!/bin/sh
LAN_SUBNET="192.168.1.0/24"
ROUTER_IP="192.168.1.1"
ebtables -t broute --new-chain RESTRICT_LAN 2> /dev/null
ebtables -t broute -F RESTRICT_LAN
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-proto udp --ip-sport 67:68 --ip-dport 67:68 -j ACCEPT # DHCP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto tcp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 5351 -j ACCEPT # NAT-PMP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto icmp -j ACCEPT
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $LAN_SUBNET -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst 224.0.0.0/4 -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv6 -j DROP
# Always apply our restrictions to WDS devices (avoid(reduce) isolation break when a repeater connects to a guest network)
ebtables -t broute -D BROUTING -i wds+ -j RESTRICT_LAN
ebtables -t broute -A BROUTING -i wds+ -j RESTRICT_LAN
# Apply our custom restrictions to guest 2 and 3 if needed
for INTERFACE in wl0.2 wl0.3 wl1.2 wl1.3; do
ebtables -t broute -L BROUTING | grep "\-i $INTERFACE " | while read -r line ; do
ebtables -t broute -D BROUTING $line
done
if [ "$(nvram get "${INTERFACE}_bss_enabled")-$(nvram get ${INTERFACE}_lanaccess)" = "1-off" ]; then
ebtables -t broute -A BROUTING -i $INTERFACE -j RESTRICT_LAN
fi
doneAs a bonus the single chain now gives a much more readable ebroute -t broute -L output.
drinkingbird
Part of the Furniture
Yeah not really sure why they allow UDP in the EBTABLES rules for GW2 and 3, possibly so you can stream from your phone on main LAN to your TV on IOT guest or something. For GW1 it is not an issue since it will hit IPTABLES and get denied there. Though I wonder if since it is passing between two different interfaces within the bridge if it does hit IPTABLES even though it is the same subnet. Haven't tested that, in theory it shouldn't hit IPTABLES but I'm not an expert on linux firewall, have just figured out enough to get my asus working how I want (guest able to print to main LAN but block all other, etc).
You could probably put some EBTABLES rules on the repeater to stop guests on that from talking to guests that hang off the main router, though AP isolation on the main router probably stops that anyway.
If the repeater mode supports AP isolation you can enable that there to stop guests from talking to each other when on the repeater too.
Keep in mind the BROUTING chain is special. "DROP" means send it to the interface (the wl or wds ones in this case) for routing. In this case, since the wl interface has no IP on it, it can't route, it blackholes and effectively does just become a drop rule. ACCEPT means bridge the traffic, in this case send to BR0. So in the way asus has implemented it, DROP and ACCEPT actually work as you'd expect. When sending to your new sub-chain, not sure if that behavior is carried over, I would assume so, not positive. But doesn't matter since it will work as DROP and ACCEPT either way for the reasons above.
Similar to deleting your BROUTING rule before adding, I'd probably delete your custom chain before adding too. Just so you don't end up with duplicate rules every time the firewall restarts.
EDIT just noticed you're flushing it first, never mind.
ebtables -t broute -L --Lc gives you counters which is handy too.
Thank you for the insight!
Do you know if it's possible with ebtables to drop packets going from other interface to the guest/wds interface? With the current rules the guest can't send broadcasts but it will still receive them from other interfaces (asuswrt relies on client isolation to stop that which is moot here since it's across routers). I tried playing with the filter tables in ebtables but it didn't seem to work.
The proper solution is to move the wds to br1 (as you suggested) so that it's in a different subnet and broadcast domain. And it works but it doesn't seem very stable, a few times the interface was removed from the bridge by asuswrt. And there's no script to catch its creation. Maybe I have to use a cron that runs every minute and fix the bridges? I guess it wouldn't be too bad on such a beefy router?
Something along those lines:
* * * * * fix-guest-networks-cron
Code:
#!/bin/sh
PREV_VALUE="$(cat /tmp/fix-guest-status 2> /dev/null)"
CURR_VALUE="$(brctl show)$(ebtables -t broute)"
if [ "$PREV_VALUE" != "$CURR_VALUE" ]; then
/jffs/scripts/fix-guest-networks
echo "$(brctl show)$(ebtables -t broute)" > /tmp/fix-guest-status
fiNot terribly elegant but is there a better way to catch bridge changes made by asus?
drinkingbird
Part of the Furniture
If the interfaces are in the same bridge/subnet you're mostly limited to using ebtables, though for broadcasts I guess iptables may come into play, at least for ones sourcing from the router interface. Try using ebtables to block 255.255.255.255 (with no protocol specified) but you'd need to craft it in a way that it doesn't block broadcasts on your regular LAN.
Maybe it would be more prudent to try using Aimesh and finding a way to hide/remove your main SSID from the node?
That won't work for me because I'm using an AX55 as the repeater and there's no scripting support, but it might be a solution for others yes.
Something like
Code:
nvram set wl0_closed=0
nvram set wl1_closed=0Would need a cron because aimesh propagates config every now and then.
Similar threads
Similar threads
Similar threads
-
Solved Help finding workarounds for a WiFi bridge repeater that doesn't support VLANs
- Started by robca
- Replies: 3
-
-
Devices connected through wifi extender are showing up under guest IP subnet
- Started by jsn2233
- Replies: 3
-
How to get a list of all devices currently connected to the router in the terminal?- Started by _BLACK_BuLLeT_
- Replies: 4
-
GT-AX11000_3004_388.8_2 Asus AI Mesh: 0 devices connected to one node- Started by ali.
- Replies: 0
-
Question - How Does Wireless Log determine Connected time?- Started by JGrana
- Replies: 25
-
VPN Stays connected but Stops Routing after DoH Change- Started by CaptnDanLKW
- Replies: 2
-
-
AX86U no longer boots if usb is connected after latest update 3004.388.7
- Started by zany130
- Replies: 3
Latest threads
-
Release ASUS TUF-AX6000 Firmware version 3.0.0.4.388_33427 (2024/11/06)
- Started by fruitcornbread
- Replies: 0
-
Release ASUS RT-AXE7800 Firmware version 3.0.0.4.388_25127 (2024/11/06)
- Started by fruitcornbread
- Replies: 0
-
Release ASUS RT-AX5400 Firmware version 3.0.0.4.388_25127 (2024/11/06)
- Started by fruitcornbread
- Replies: 0
-
-
AX88U Pro Firmware version 3.0.0.6.102_33338 2024/11/06
- Started by Paliv
- Replies: 3
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!
Staff online
-
RMerlinAsuswrt-Merlin dev