Two things meet at this point - your WLAN and your LAN.
Do you also use different VLANS in the WLAN environment? If so, the AP tags these packets when they are transferred to the wired network, from the end device's point of view, the traffic remains untagged. You must also tag these VLANs at the switch port where the AP is connected. You can write this statically into the startup config.
It is better if you send the VLAN taggs dynamically during AP authentication at the switch port.
After AP authentication you can check port mode in the switch CLI, use show port-access summary radius-overridden
.
You can check dynamic VLAN tagging with show port-access clients [port-nr] detailed.
------------------------------
Regards,
Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------
Original Message:
Sent: Sep 11, 2024 09:09 AM
From: JeffreyM
Subject: Aruba 2930F RADIUS auth with Windows NPS
I have configured the port on port-based mode. But what happens now is a bit weird.
The access point authenticates just fine and gets connectivity after successful authentication.
After that, the clients that were connected to the AP before (And already obtained an IP, can communicate just fine). But when a new client tries to connect, it doesn't get an IP-adres via the DHCP-server (running on the firewall (FortiGate)). It's like traffic from a new client to obtain an IP-adres doesn't work.
I think I need to use user roles in order to let traffic from the other VLAN's trough the switchport. But I can't configure them on the switches with the current firmware version which is YA.16.09.0014. I think this version doesn't support multi untagged vlan's inside a local user role?
Original Message:
Sent: Sep 02, 2024 06:56 AM
From: oden74
Subject: Aruba 2930F RADIUS auth with Windows NPS
Hi, the difference between client-based and port-based authentication is that if you use client-based each individual mac-address entering the port will be authenticated. If you use port-based authentication, only the first mac-address learned on the port is being authenticated and the mac-addresses that follow are allowed. So if you want to authenticated only the ap and not the clients connecting to the ap you can use port-based authentication.
Original Message:
Sent: Aug 30, 2024 04:58 AM
From: JeffreyM
Subject: Aruba 2930F RADIUS auth with Windows NPS
Hello,
We currently have four Aruba 2930F switches and a Windows NPS server handling authentication. We want to configure all ports for port-access.
I have configured almost every port with port-access, and authentication is working well with the NPS server (I'm using dynamic VLAN assignment).
One problem we are facing is that we have multiple APs. The MAC addresses of the APs are stored in a group in Active Directory (AD), and we check for a security group in a network policy on the NPS server. So far, this works great-the APs receive the correct VLAN ID after MAC authentication on the NPS server. However, the clients behind the APs can't connect because the VLANs are not allowed on the port.
One solution is to use user roles on the switch where the untagged/tagged VLANs can be added. Does the Windows NPS server support sending back a specific user role name to the switch after authentication? If so, how should I configure this, and how does the user role for the access points be configured on the switch? (Something with device port mode?)
And then I have one more question. Currently, all ports are configured with the following commands:
interface (x)
untagged vlan 1
aaa port-access authenticator (x)
aaa port-access authenticator (x) tx-period 10
aaa port-access authenticator (x) client-limit 2
aaa port-access mac-based (x)
aaa port-access mac-based (x) addr-limit 2
aaa port-access (x) auth-order authenticator mac-based
aaa port-access (x) auth-priority authenticator mac-based
From my understanding, the ports are currently configured for 'client-based' authentication. What is the difference between client-based and port-based authentication? Since all ports only have one client behind them, would port-based authentication be better?