Hello all,
My apologies in advance if this has been covered or is a dumb question, but I am having some trouble securing the connection running to my outdoor AP6 from my S24. My thoughts were that I want to prevent someone from unplugging the AP6 and plugging in their own device including a switch or hub. I initially tried to restrict the switch port to just allow the MAC of the AP6 but that resulted in devices connecting to the ap having no internet. Is this the expected behavior?
I could maintain a list of my wireless device MAC addresses but I’d like to give others access by providing a WiFi ssid and password. Also I thought about possibly marking that port connect to its own vlan and isolating it from the rest of my network but I’d like the ability to access my network via the wireless connection provided by the AP6.
Does a mechanism exist to restrict a switch port to a specific AP + all traffic from other devices connected to that AP?
If anyone has any advice or suggestions I would appreciate it.
I think the immediate answer might be something like 802.1x authentication, but that might be little excessive depending on the environment
Understanding and deploying 802.1X with Alta Labs Network Switches – Alta Labs
I’m thinking you could use PPSK/Alta Pass to create another password for other people to use on your WiFi and tie that to another VLAN to segment them away from your main network, although that doesn’t really take care of someone physically unplugging the access point and connecting to your network.
Awesome, thanks for the tip! I have experimented a bit with the 802.1x settings by enabling a radius server on the route 10 and setting the port mode to 802.1x strict on the s24 switch. I did this on the port that runs to the AP6 Pro Outdoor. I did not create any users or find any place to specify the radius server or user on the access point - do the AP6 Pros support 802.1x?
I didn’t notice any difference right off the bat so I did unplug the port to the AP and plug it back in after a moment. The AP shows up in my interface as normal and it seems like there is a device connected to it but I haven’t had a chance to verify that it has internet access.
After some more digging, it seems that even if I got 802.1x working here, someone could hypothetically plug in their own switch between the network and my AP and gain access that way since the switch port would open after the AP authenticated. One solution suggested was MACsec - is that a supported or planned feature within the Alta Lab ecosystem?
I also found mentions of CAPWAP and GRE to tunnel traffic from the AP to the controller. I do have an onsite controller but I’m not sure this is the same type of controller the article referred to.
I’m in the process of slowly adding various wired devices outside my house (poe cameras, Pool equipment controller, bitcoin miner haha) so I’d like to make sure I’m not going to accidentally add a bunch of points folks could potentially jack into my network and mess around.
Ok so I didn’t set the radius server in the s24 switch settings. After I set that it completely blocked the ap6 pro on that port. Setting the port to 802.1x non-strict did allow the ap6 back on and traffic was moving to/from the ap. I am guessing the AP6 is not authenticating with the radius server so 802.1x strict is not working. Is there a way to setup that authentication (even if it’s outside the graphical web interface)? Or am I completely on the wrong track here?
So I did some reading and I’ve seen some folks use wpa_supplicant to authenticate with the radius server for 802.1x. I gave that a shot on the AP but no matter which interface I specify, wpa_supplicant says that interface doesn’t support the “wired” driver which I am trying to use. Has anyone done this before or have a working config for wpa_supplicant?
As far as I know the Alta Labs controller doesn’t support being a RADIUS server itself, so it would need to be combined with a separate RADIUS server like FreeRADIUS, for example.
FreeRADIUS
Getting Started
Although MACsec would be interesting, especially since I don’t believe that sees a lot of support outside of devices from the real big network companies. Might be worth creating a feature request on it. Although I think that also requires the chips in the switches to support it as well.
I enabled the radius server on the Route10 and when I ssh into the Route10 I believe the freeradius server is running. I also added the Route10 as a radius server on the s24 switch but I don’t really know how to verify that is working. Is it not possible for the AP6 to auth to the radius server running on the Route10 through the s24 when the port connecting them is marked 802.1x strict?
The current supplicant does not have the wired driver enabled. We haven’t received any requests for this. However, if you invite me to your site, I can install a firmware that has it enabled, but you’d still need to use ssh (and post-cfg.sh) to bring it up.
1 Like
Just saw this. Yea that’s what I ended up discovering, that the qca-wpa-supplicant package doesn’t have the wired driver installed. I ended up making a script in /cfg that uninstalls qca-wpa-supplicant and installs hostapd-common and wpa-supplicant packages which I pulled to /cfg as well. Then it runs wpa_supplicant -ieth0 -Dwired -c/cfg/wpa.conf -B and that seems to work in that I can set the switch port to 802.1x strict and then ssh into the AP after it is connected and boots up. I’m not sure if ditching the qca version of wpa-supplicant will mess other things up but if you have a version of the firmware with the wired driver that would be awesome. No chance there’s firmware that supports MACSec yet is there???
I’ll DM you for an invite. I can install a version with the wired driver. MACSec is less likely to be released soon.
After doing all that research I was pretty excited to learn about MACsec; it seems like it could solve all the concerns I mention above in a clean way. I looked around for other hardware supporting it and I didn’t find much. Is it a feature the current hardware could eventually support? It seems like it could be a cool differentiating factor for Alta!
On a separate note, as I was poking around on the devices, I noticed that when I tried to do a opkg update some of the urls are no longer valid - it seems the ipq50xx target is no longer there under that specific version of openwrt. It looks like it was moved to the qualcommax directory but it’s still only there in the latest versions of openwrt. Do you know if/why the support was removed in the version the Alta AP6 firmware is built off of? Are there any plans to update to the more recent versions of openwrt that have the ipq50xx target on openwrt’s repos?
We don’t have plans currently to support MACsec, but feel free to make a feature request.
We don’t utilize the openwrt public repos for anything on our end, and don’t technically support using okpg files in general. They may work for you, but we just wouldn’t be able to support any questions you have using them.
1 Like