Multiple secrets per IP for radius client

Question

I have various routers which connect to my radius system, their IP might change as it's all over the net via NAT networks..

Each router has a unique secret. All known in a local DB

Now I'm looking to set radius up in a way that every router can authenticate with their custom secret, via whatever IP, but freeradius won't let me configure it like this:

client 0.0.0.0/0 {
    shortname = test1
    secret = AA
}   
client 0.0.0.0/0 {
    shortname = test2
    secret = AB
}

Is there a way so I can either disable the freeradius IP check (and check on secret only?), or to force a client (/ip) to have more than 1 secret ?

Reconfigurating the secret to all the same is unfortunately not possible, as some routers already have been deployed with very limited network access.

I'm using:

 freeradius: FreeRADIUS Version 2.2.8, for host x86_64-pc-linux-gnu, built on Apr  5 2016 at 13:40:43
 Copyright (C) 1999-2015 The FreeRADIUS server project and contributors.

Answer 1

Why what you want doesn't work with RADIUS/FreeRADIUS alone

FreeRADIUS does the packet to client matching before the packet is decoded. Decoding the packet before performing the matching makes DoS attacks against the server easier, as spurious requests cause the server to use more CPU time.

Ignoring the secret isn't an option either. The secret is used by the Access point to decode protected attributes like the MPPE key attributes for WPA2 Enterprise.

For walled gardens with PAP the shared secret is used to encrypt the cleartext password provided by the user, so if you don't know the shared secret you can't get the plaintext value back for validation.

In v4.0.x the plan is to send packets from unknown IP addresses down to the worker threads for processing. At this point the worker would have full knowledge of all attributes, and could bind a secret to the IP address using that additional information.

It still wouldn't let you map incoming packets using RADIUS attributes, but you're unlikely to see a conflict where two APs swap their WAN IPs... Apart from possibly in a CGN environment with a small public pool.

Available options

• Use RADSEC (DTLS/TLS). Clients are validated using a certificate, and the shared secret is fixed.
• Establish a tunnel (L2TP/IPSEC/PPP) between the AP and your RADIUS server. Use that to provide consistent local IP addresses.
• Run the APs dual stack, hopefully bypassing the NAT. Some ISPs have begun offering IPv6 connectivity with prefix delegation. In these cases, all devices behind the CPE get publicly accessible IPv6 addresses. The prefix may change occasionally, so you'd need to use some sort of 'phone home' system, where the AP could inform your servers of its public address.
• Develop your own software, which snoops on incoming RADIUS packets, and checks to see if the IP matches one in your client database. If it doesn't, it tries all the shared secrets to see if any can be used to validate the packet contents, and then updates the IP binding for that client. This might work best with your set of restrictions.

I think there's also some patches out there for v2.x.x which allow dynamic clients to be created using decoded attributes, but v2.x.x was EOL'd a while back, and they're not officially supported.