Wrong World
New Around Here
Hello,
It may be possible that something is seriously broken in the way the Broadcom chip manages VLANs associated to guest SSID, or at least I am having a problem with Asuswrt-Merlin 384.5 (ot it may be my fault, of course).
Here is a little background on my setup:
Cable - [ONT] - [EdgeRouter Lite 3] - [Netgear GS108Tv2] - [Asus RT-AC66U_B1]
The EdgeRouter has many VLANs associated to its eth1 virtual ports, so:
...
VLAN 101: XXX.XXX.101.x on eth1.101
VLAN 102: XXX.XXX.102.x on eth1.102
...
and so on.
The Asus router is connected to the Netgear switch via a trunk. The RT_AC66U_B1 is indeed running in access point mode, and is linked to the switch with a single cable via the Ethernet port 1. Being a trunk, I've created inside the access point all the needed VLANs and moved them on different brX bridge interfaces. On each bridge there is either the 2.4 GHz or the 5 GHz interfaces (eth1/eth2), or one of the guest Wi-Fi interfaces wlX.Y. In this particular case, I have:
102: vlan102: 1t 5t
from robocfg, and
br3 8000.38d54773e328 no vlan102
wl0.1
from brctl. Hence, the traffic associated with the SSID served by wl0.1 is automatically tagged with VID 102 and it goes up to the EdgeRouter as a tagged traffic, where it hits the eth1.102 router's interface. Or so it should, because in reality I am seeing on my syslog server connections coming from a guest client on that SSID which sometimes are arriving on the wrong router's interface, and this can only happen if the Broadcom chip in the AP tags the traffic with the wrong VID.
See these two log entries captured with 3 seconds of difference. You can see that traffic from XXX.XXX.102.11 tries to go to XXX.XXX.1.30 and gets blocked by the relevant router's firewall rule. However, you can also see that the traffic arrives first from eth1.102 (which is correct, as the source device is on VLAN 102) and three seconds later arrives from eth1.101, which would mean it was tagged with the (wrong) VID 101, and in fact it hits a different (and unrelated) firewall ruleset. (Note: real IPs and MACs have been partially masked out)
2018-06-24T19:51:39.000Z [INSECURE_IN-30-D]IN=eth1.102 OUT=eth1 MAC=11:22:33:44:55:66:10:11:5f:b6:5d:06:08:00:45:00:00:3c SRC=XXX.XXX.102.11 DST=XXX.XXX.1.30 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6750 DF PROTO=TCP SPT=57499 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
2018-06-24T19:51:36.000Z [GUESTS_IN-80-D]IN=eth1.101 OUT=eth1 MAC=11:22:33:44:55:66:10:11:5f:b6:5d:06:08:00:45:00:00:3c SRC=XXX.XXX.102.11 DST=XXX.XXX.1.30 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43648 DF PROTO=TCP SPT=57498 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
I seem to recall some time ago that someone claimed on this forum that there were cases where the Broadcom chip would mess the VIDs, especially when dealing with many tagged VLANs (I have 6). I also seem to recall that the same person stated that in order to have the chip properly working he had to configure the VLANs using "et robowr" and not robocfg, although this could have been a problem in previous firmware releases that has been fixed meanwhile. Unfortunately, I am not able to find that message any more.
Has anyone suffered from a similar issue? I am stuck currently, because if I cannot trust that the Wi-Fi traffic is properly tagged, I cannot continue with my project. Oh, BTW: wl0.1 is not running in isolation mode, for what is worth.
Thanks!
It may be possible that something is seriously broken in the way the Broadcom chip manages VLANs associated to guest SSID, or at least I am having a problem with Asuswrt-Merlin 384.5 (ot it may be my fault, of course).
Here is a little background on my setup:
Cable - [ONT] - [EdgeRouter Lite 3] - [Netgear GS108Tv2] - [Asus RT-AC66U_B1]
The EdgeRouter has many VLANs associated to its eth1 virtual ports, so:
...
VLAN 101: XXX.XXX.101.x on eth1.101
VLAN 102: XXX.XXX.102.x on eth1.102
...
and so on.
The Asus router is connected to the Netgear switch via a trunk. The RT_AC66U_B1 is indeed running in access point mode, and is linked to the switch with a single cable via the Ethernet port 1. Being a trunk, I've created inside the access point all the needed VLANs and moved them on different brX bridge interfaces. On each bridge there is either the 2.4 GHz or the 5 GHz interfaces (eth1/eth2), or one of the guest Wi-Fi interfaces wlX.Y. In this particular case, I have:
102: vlan102: 1t 5t
from robocfg, and
br3 8000.38d54773e328 no vlan102
wl0.1
from brctl. Hence, the traffic associated with the SSID served by wl0.1 is automatically tagged with VID 102 and it goes up to the EdgeRouter as a tagged traffic, where it hits the eth1.102 router's interface. Or so it should, because in reality I am seeing on my syslog server connections coming from a guest client on that SSID which sometimes are arriving on the wrong router's interface, and this can only happen if the Broadcom chip in the AP tags the traffic with the wrong VID.
See these two log entries captured with 3 seconds of difference. You can see that traffic from XXX.XXX.102.11 tries to go to XXX.XXX.1.30 and gets blocked by the relevant router's firewall rule. However, you can also see that the traffic arrives first from eth1.102 (which is correct, as the source device is on VLAN 102) and three seconds later arrives from eth1.101, which would mean it was tagged with the (wrong) VID 101, and in fact it hits a different (and unrelated) firewall ruleset. (Note: real IPs and MACs have been partially masked out)
2018-06-24T19:51:39.000Z [INSECURE_IN-30-D]IN=eth1.102 OUT=eth1 MAC=11:22:33:44:55:66:10:11:5f:b6:5d:06:08:00:45:00:00:3c SRC=XXX.XXX.102.11 DST=XXX.XXX.1.30 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6750 DF PROTO=TCP SPT=57499 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
2018-06-24T19:51:36.000Z [GUESTS_IN-80-D]IN=eth1.101 OUT=eth1 MAC=11:22:33:44:55:66:10:11:5f:b6:5d:06:08:00:45:00:00:3c SRC=XXX.XXX.102.11 DST=XXX.XXX.1.30 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43648 DF PROTO=TCP SPT=57498 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
I seem to recall some time ago that someone claimed on this forum that there were cases where the Broadcom chip would mess the VIDs, especially when dealing with many tagged VLANs (I have 6). I also seem to recall that the same person stated that in order to have the chip properly working he had to configure the VLANs using "et robowr" and not robocfg, although this could have been a problem in previous firmware releases that has been fixed meanwhile. Unfortunately, I am not able to find that message any more.
Has anyone suffered from a similar issue? I am stuck currently, because if I cannot trust that the Wi-Fi traffic is properly tagged, I cannot continue with my project. Oh, BTW: wl0.1 is not running in isolation mode, for what is worth.
Thanks!
