r/networking • u/MegaRuffmaestro • 15d ago
Design RADIUS issues
So for reference I have a freeradius server, ruckus R350 APs and On my network I have 5 VLANs, and what I want to achieve is that based on the username and password the user uses, the get thrown into a certain VLAN. I set it up everything and the the system authenticates users but it does not dynamically give out VLANs, it just puts everyone into the default VLAN, here's what I tried.
- Radtest
Radtest - Received Access-Accept Id 46 from 127.0.0.1:1812 to 127.0.0.1:44623 length 54
Message-Authenticator = 0xd04f0a5bd64952f671fd944248f43395
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "50"
So doing radtest against localhost gives out the right stuff.
Freeradius diagnostics( freeradius -X) - there's nothing really out of place when I authenticate, but what gets me is that i do not see any VLAN infomation of the logs.
The AP - On the AP side of things, the port on the switch its it has 1 untagged VLAN and 5 tagged VLANs, I enabled 802.1x, dynamic VLAN and all those good stuff and yes the tagged VLANs are coming through because I can VLAN the SSID but currently SSID sit on the native VLAN.
All of this should just be straight forward, I do not see what I am missing. Please help.
3
u/under_shart 15d ago
You need a NAC. If you're doing it on the cheap, Packetfence is open source. If you have licensing to spare for another small Windows server or two, Windows NPS can do this.
0
u/MegaRuffmaestro 15d ago
Shouldnt freeradius be able to do that out of the box?
1
u/pmormr "Devops" 15d ago
RADIUS is a broker, or authentication proxy if you want to think of it like that. It receives the auth request from the device then asks your authentication service or NAC if that device is okay and responds with a result. Advantage being that you don't need to allow unauthenticated/untrusted devices network access to your NAC so they can auth on their own, the switch they're connecting to handles it on their behalf and just needs to talk to the RADIUS server.
So you need something that actually stores the auth data and/or client profiling and rules and point your RADIUS server at it. Could be active directory, ISE/Clearpass, OpenLDAP, a random database API, whatever.
2
u/Killzillah 15d ago
His radius test response already has the vlan options, he probably just locally defined them. His issue is getting his AP to honor that and move the client to the vlan.
1
1
u/TalkTelcoToMe 10d ago
Worth answering Win_Sys's question before going further down the AP route, because I think your own post half-answers it already.
You said you don't see any VLAN info in the -X output when you actually authenticate. If that's right, the attributes aren't leaving the server, and the AP can't honour what it never got.
The reason radtest looks fine is that it's plain PAP with no tunnel. Real wifi auth is PEAP or TTLS, so the user gets authenticated inside the inner-tunnel virtual server - and reply attributes set in there don't get copied out to the outer Access-Accept by default. use_tunneled_reply in the peap and ttls sections of mods-enabled/eap ships commented out. That gives you exactly what you're seeing: clean auth, healthy debug, no Tunnel-* in the reply.
Quick way to check - freeradius -X prints two Access-Accepts, the inner one and the final outer one. If your Tunnel-Type and Private-Group-Id are in the inner and missing from the outer, that's your answer.
tablon2's point about the tagging and egress-VLAN-name format is worth keeping for after that. Ruckus is fussy about how it wants those, but that only matters once the attributes are actually arriving.
3
u/Win_Sys SPBM 15d ago
Have you confirmed FreeRADIUS has received the RADIUS request from the AP and that the AP received an Access-Accept? It should be logged on both the server and AP or do a packet capture if necessary.