On Aug 19, 2018, at 3:56 PM, WAGHORN, Jason (NHS BORDERS) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
i.e. have FreeRADIUS handle DHCP, too. On initial request, it can check the MAC address in radacct for the username who last logged in. Then, check their billing history. If their account is in arrears, give them an IP from a walled garden.
How will this work (either way) if the client supports MAC spoofing?
All clients support MAC spoofing. But you don't really care what the MAC is.
Surely you should prevent access via username, not client MAC (they could also just use another client, or W-NIC,...)
I *did* mention RADIUS first, then DHCP. That gets you a User-Name. Let me be clear, seeing as my point didn't get across: RADIUS gets you User-Name, MAC address, NAS IP, and NAS port. You can authenticate the user (PAP, CHAP, MS-CHAP, EAP), and store the MAC, NAS IP and NAS port in the radacct table. And yes, you don't really care what the MAC is. Because you authenticate the user by name && password. When you get a DHCP request, you get MAC, NAS IP, and NAS port. Hmm... it seems like we have already seen that information! What happens next? a) the MAC , NAS IP, and NAS port match something in radacct. You can now look up the User-Name, and assign IPs based on user groups. Or, check the users billing status, and assign an IP from the "walled garden" pool, with the walled garden router / captive portal. b) the MAC, NAS, IP, and NAS port *don't* match something in radacct. You can use this mismatch as definitive proof the user is doing something stupid. And... (drum roll) put them into a walled garden. There are no other possibilities. If the user behaves correctly, everything works and they get online. If the user misbehaves, they don't get online.
Seems to me like a game of whack-a-mole :)
I don't see how. What part of the above won't work? Hint: I've done this in production systems. Alan DeKok.