Posted: Mon Apr 25, 2022 21:47 Post subject: WPA2 authentication fails on 2.4ghz virtual interfaces
I have a Netgear AC1450 I use as a wireless access point (WAP)/extender for four vlans coming from my main router. Since all of the network SSIDs are on both the 5ghz and the 2.4ghz radio, and clients can oftentimes still connect to the main router too, I didn’t notice an issue that seems to have been around for a long while, and was tricky to isolate:
Clients are unable to authenticate (WPA2/AES) to virtual interfaces associated with the 2.4ghz radio. Here are some pertinent facts:
- clients can authenticate to the main 2.4ghz network (ie non-virtual interfaces)
- the radio seems to otherwise work fine. If I disable the WPA2/AES security altogether, clients can connect to virtual interfaces as well
- the 5ghz main and virtual networks all work fine
- it doesn’t seem to have anything to do with the password or the vlans
- this affects linux, android, and iPadOS clients. Thus it doesn’t seem to be a client issue
-it affects builds back to at least 2020 (42xxx) because that’s what I was running when I found the issue. I find that it remains with the latest build 48646, after upgrading with a full reset.
- I noticed that the MAC addresses mentioned in the dd-wrt gui (and in nvram) do not match the MAC addresses being advertised for these virtual interfaces from the client perspective. They are unique however, within the router.
It’s all a bit puzzling to me, and I didn’t find anything on the forums about it. I would be most grateful if anyone has any insight into why this might be happening or what might be done about it.
Are the clients able to see the 2.4ghz radios?
Are the 2.4 ghz radios set to the same standard as the clients (ie b/g/n or whatever combination)
What are the specific network authentication and WPA algorithms selected?
Thanks for your response. I need to amend my problem slightly. It turns out sometimes, some of the virtual interfaces on 2.4ghz do work with WPA2/AES security; normally the first works (in addition to the physical interface). But the second and third normally do not (and the third has never once worked with any client). If I swap the SSID and passwords for the first and second virtual interfaces, they reverse which one works.
To answer your questions:
Yes, clients can see all the interfaces. When they try to connect, they say either that the password is incorrect, it cannot connect, or that they time out when authenticating.
I only use WPA2/AES for security. But when I disable security altogether, they can connect fine.
In the attached screenshots, you can see two virtual interfaces. It is only possible to connect to interweb_pia2 with security disabled. If I re-enable WPA2/AES for that interface, it becomes impossible to connect.
Note that the BSSID (as gathered by my linux computer) does not match the one in the gui for these virtual interfaces:
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
06:A1:51:0E:7B:11 interweb_us2 Infra 3 195 Mbit/s 100 ▂▄▆█ WPA2
06:A1:51:0E:7B:10 interweb_pia2 Infra 3 195 Mbit/s 100 ▂▄▆█ --
* 04:A1:51:0E:7B:0F interweb2 Infra 3 195 Mbit/s 85 ▂▄▆█ WPA2
Virtual interfaces for the 5ghz radio DO match what the gui says (and they work fine).
Joined: 18 Mar 2014 Posts: 11456 Location: Netherlands
Posted: Tue Apr 26, 2022 12:52 Post subject:
I am running multiple interfaces without a problem but my router is in normal gateway mode (and my Wireless Network Mode is N/G mixed but I doubt that has anything to do with it)
Did yo try rebooting?
As you are using this router as a WAP check the proper settings:
VAP on WAP
If you place the unbridged VAP on a wireless access point:
A secondary router connected wired LAN<>LAN on the same subnet as a the primary router:
• WAN disabled
• DHCP server Disabled (=off and NOT set as Forwarder!)
• Local IP address in subnet of primary router but outside DHCP scope (you can run udhcpc to give the WAP a static lease but because you can it doesn't mean you should
• Gateway and Local DNS pointing to primary route
• DNSMasq enabled
• Router kept in the default Gateway mode (the wiki says Router mode but do not do that, Router can break things)
If so then you have to add the following rule to the firewall in order to get internet access from the VAP.
In the web-interface of the router (the WAP): Administration/Commands save Firewall:
#Always necessary (alternatively set static route on main router):
iptables -t nat -I POSTROUTING -o br0 -j SNAT --to $(nvram get lan_ipaddr)
I tried changing from router mode to gateway mode and rebooting, but the behavior seems unchanged.
The other things you mentioned in the setup are alright, except I don't use DNSMASQ (dns queries go to the main router, but I think that's fine). I also don't have that firewall rule, but it seems to be working fine (?) (I can use all the vlans fine via the 5ghz radio and they can access the WAN).
I've already reset when upgrading to the latest firmware, so no luck on that front either -- same behavior.
Maybe these logs from linux when trying and failing to connect to the third virtual interface might help:
Thanks for your input. I tried changing the password, rebooting, changing it back, rebooting again. Unfortunately no luck.
Then I tried playing with the interface MAC addresses found under Setup->Networking.
When I change the MAC for eth0 (the 2.4ghz radio) from
04:A1:51:0E:7B:DF, and reboot,
The virtual interfaces 1, 2, and 3 (as seen by a client) change from:
06:A1:51:0E:7B:11, 06:A1:51:0E:7B:12, 06:A1:51:0E:7B:10
06:A1:51:0E:7B:E1, 06:A1:51:0E:7B:E2, 06:A1:51:0E:7B:E0
(note only the last byte changes, and they are not in order).
Meanwhile, the same virtual interfaces as shown in the edit box under Setup->Networking, as well as in Wireless, and in the nvram change from:
06:A1:51:0E:7B:00, 06:A1:51:0E:7B:01, 06:A1:51:0E:7B:02
06:A1:51:0E:7B:D0, 06:A1:51:0E:7B:D1, 06:A1:51:0E:7B:D2.
(Note that only the last byte changes, they differ in the last byte from what is broadcast, and they ARE in order by virtual interface number)
While it is possible to change the MAC address for wl0.* virtual interfaces in Setup->Networking, these changes do not have any effect and are reverted upon reboot.
Note also the mac addresses in for the 5ghz radio:
Physical interface: 04:A1:51:0E:7B:10
Virtual interfaces 1-3: 06:A1:51:0E:7B:11, 06:A1:51:0E:7B:12, 06:A1:51:0E:7B:13
(These ARE in order and internally DO match the BSSID as broadcast to clients).
I now strongly suspect that the problem is related to the misalignment in the MAC addresses between what is stored internally to dd-wrt and what is broadcast, and that the different order for the third virtual interface might be causing the problem (the third interface should probably be 06:A1:51:0E:7B:E3, not 06:A1:51:0E:7B:E0). Perhaps the addresses are related to the order the interfaces were added/removed?
Looks like I have found a workaround, thanks to your idea to change the MAC addresses.
If I change the eth0 mac address (corresponding to the 2.4ghz radio) to:
so that it ends in a 0, like the 5ghz radio,
then the virtual interfaces (1-3) become:
06:A1:51:0E:7B:D1, 06:A1:51:0E:7B:D2, 06:A1:51:0E:7B:D3
(so they are in order, and they also MATCH between the BSSID as broadcast, and as shown internally [e.g, under Wireless and in nvram]).
And after doing that, I can now connect/authenticate to all the virtual networks!!!
So, it appears that there is a problem/inconsistency with the math being used to compute the MAC addresses for virtual interfaces (based upon the physical interface address) for my router, and it fails when the physical interface address ends in 0xF (or maybe, when it doesn't end in 0). Maybe there should be a bug report about this?
I am attaching ifconfig results from before when it was broken (phy addr ends in F, which I reverted to with some hesitation ), and from after, when it worked (phy addr ends in 0).
Looks like ifconfig shows the same MAC addresses as the GUI and nvram (ends in 00, 01, 02). But I confirmed that the BSSID as advertised to clients remains different (ends in 11, 12, 10 for virtual interfaces 1-3 respectively).