ESSID_3 - 2.4ghz and 5ghz - WPA2-Personal + fast roaming enabled - VLAN 102
The management VLAN is set to VLAN 101.
On my OPNsense router, the networks I've configured for each VLAN are as follows:
VLAN 101 - 192.168.101.0/24
VLAN 107 - 192.168.107.0/24
VLAN 102 - 192.168.102.0/24
My WAX220 is connected physically to a port on the OPNsense firewall that has its interface configured with the 3 VLANs only. No untagged traffic should be passed on this interface.
In this configuration, everything works as expected. Clients connected to either of the 3 networks are assigned DHCP from the OPNsense router on the correct ranges.
Then, I tried setting ESSID_2 to WPA2-Enterprise with the following configuration:
Group Key Interval - 3600
Radius Server - 192.168.101.1 (FreeRADIUS running on the OPNsense firewall)
Radius Port - 1812
Radius Secret - [triple checked for correctness]
In this configuration, I'm unable to get any clients to connect. They fail by being unable to complete the 4-way handshake.
I suspect the issue is that the WAX220 is not able to reach the Radius server running on the OPNsense firewall.
Steps I tried to troubleshoot this:
I configured radius to log as much as possible, including successful and failed login attempts, and tried connecting from multiple clients. In every case, nothing was logged by the radius server.
I downloaded the logs from the WAX220, but these are only kernel dmesg and nothing stood out to me here indicating why the WAX220 presumably does not talk to my radius server.
I made sure there are no filter rules in place that could prevent the WAX220 from communicating with the radius server on my OPNsense firewall.
I did a ping test from the diagnostics page of the WAX220, and confirmed that it is able to reach the firewall.
I used tcpdump on the vlan bridges, the individual vlan interfaces, the untagged physical interfaces to see if anything at all was being sent from the WAX220 to my radius server, and there was no radius traffic at all.
I tried all of the above tests with the radius server set to 192.168.107.1 (it listens there too, as it listens on every vlan)
I tried all of the above tests with WPA3-Enterprise as well.
Steps I did not try (yet):
WPA2-Enterprise without VLANs on the wifi networks nor a management VLAN configured. (i.e. the stock configuration for the WAX220).
Could there be a bug with 802.1X on the WAX220 when using VLANs in this way? It seems the WAX220 does not even attempt to contact the radius server, or perhaps it is trying to send these packets untagged when it should be sending them over what I presume is the configured management VLAN?
The firmware apparently doesn't work with WPA2-Enterprise and VLANs? Is my configuration incorrect or have I purchased a business product that doesn't do business?
I didn't want to jump to any conclusions but if WPA2&3-Enterprise works for me once I get the chance to re-configure the WAX220 and my firewall to NOT use VLANs, then I think we might have a problem here 🤣
Provided the WAX220 plays nicely with freeradius's vlan assignment and properly isolates users to their VLANs, it could conceivably be a solution, but unfortunately not good enough for me, because:
What's the point in being able to have multiple ESSIDs on separate VLANs if I can't mix and match the security? In my case, I have several IoT devices that are incapable of dot1q and dot1x. If I disable all VLAN capability in the WAX220's configuration and rely on my radius server to assign users to VLANs, my assumption is that an ESSID with WPA2-Personal, for example, would probably work - but would be untagged - and would not adhere to my security requirements.
Also, if this is indeed some kind of bug. What's your best guess of whether netgear will address it, and in what kind of timeframe? Should I take this loss and pay up for a more capable brand?
Identical in the point that no RADIUS communication is initiated on the management VLAN. Not close enough to the device to check if there is junk data emitted instead.
My best guess as to what is going on is: When a management VLAN is configured and the Wifi networks are also configured with VLANs (Not sure if the Wifi VLANs are part of the issue or if it is only with management VLAN), some misbehavior occurs when the WAX220 tries to communicate with a radius server on the configured management VLAN.
This is why, in my troubleshooting, I made sure the radius was accessible on every VLAN, to see if the WAX220 was trying to contact the radius server over whichever VLAN is configured for the Wifi network - and based on the (malformed?) packet I see every time a client associates to that particular ESSID - this appears to be the case.
A frame that I think should be sent over VLAN 101 (the management VLAN) ends up getting corrupted(?) and sent over VLAN 107 (the VLAN set for the wifi network with WPA2-Enterprise enabled)
Now that I think about it. If a management VLAN is configured, the only IP assigned on the WAX220 would be whatever DHCP it got (or static) IP on the management VLAN - and so this naturally would be where I think the radius traffic would occur.
@MikeD1234 did you ever get a chance to test this and see if our theory about the RADIUS traffic being corrupted and/or not sent over the management VLAN is what is happening?
Did I answer your question? In this case could you give us feedback on the situation and accept my post as a solution to make it more visible to other users?
