I have a radius server that until recently was handling a number of realms, some with a realm suffix, others with a realm prefix. To do this someone has in the past uncommented the IPASS realm module in the default server, and also added ignore_null = true in the IPASS realm module configuration. As we were ceasing support for a number of prefix realms I removed their explicit entries from proxy.conf and added a DEFAULT entry which mapped to a virtual server that basically sent back Access-Rejects and a bit of logging so we could track down client and tell then to re-configure their devices. This all worked for the ceased realms, however, we were surprised to also note a huge drop in traffic on one of the suffix realms. We have tracked down cause of the drop in traffic on our suffix realm to the fact that some of those usernames also have a '/' character in them. Previously when the FreeRadius IPASS realm module parsed those realms, whilst it appeared to find a prefix realm, it found no match in its configuration and so would fall through to letting the suffix module try, which would match and then successfully end up proxying the packet on. With a DEFAULT realm also configured when the IPASS module encounters a suffix realm username that also has a '/' in it then rather than falling through and letting the suffix module handle it it instead matches it against the DEFAULT realm and so ends up sending an Access-Reject back. I note that the FreeRadius default config only has the suffix realm configured in the default server - I suspect that maybe the general advice would be only use prefix or suffix realms not both, and if you use both expect such edge-case such issues - would that be a fair opinion? In the case I have I can resolve it by: * Either keeping in the realm entries for the realms we are ceasing, but map them to the new virtual server that rejects/logs, and no DEFAULT realm. * Or remove the mappings for the ceased prefix realms but also instead of adding a DEFAULT realm add a NULL realm that maps to the virtual server that rejects/logs so that the IPASS module won't match, and the suffix module won't match a realm so will return the NULL realm. However, I do have another radius server that also handles prefix and suffix realms, already has a DEFAULT and NULL realm configured and I'm now concerned that it may have similar issues that we've not noticed or could in the future as an unintended side effect of another seemingly innocent change we might make. In trying to figure out what was going on I've been through the server logs in debug, through our configuration and even through the rlm_realm.c code. As already mentioned we have ignore_null = true in our IPASS realm configuration, this doesn't seem to be mention in the latest documentation (although Google will throw up an old page that does mentions it), there use to be a reference to it as a comment in the default server but that was removed in commit d5d4ba6673cce86ba058583ce7e38fb53a4ddae8 with the commit message "the parameter ignore_null doesn't exist". Looking at the rlm_realm.c C code it is still there, as well as an ignore_default. Have these become undocumented as they are going to be removed, or just because of complexity/complications of using them (and use at your own risk if you fully understand the implications in your context)? With v4 on the horizon - I've taken a brief look at it and realm handling is clearly different - do I need to be thinking of getting to a point where a radius server only handles suffix or prefix realms or will v4 handle this, or does it make it simpler , or does it remain a complex problem (simply because it is a complex problem) to handle both reliably? Thanks, Paul