douglas eseng wrote:
Trying to find a configuration that allow accurate accounting when PEAP / TTLS having anonymous outer user-id.
Using FR 2.2.3 with default configuration. - add a testing user - enable eap.conf use_tunneled_reply for both PEAP & TTLS
Observed that, - PEAP sent inner user-id in the Access-Accept - TTLS-PAP sent outer user-id in the Access-Accept instead. (debug output attached)
OK, I see the same.
Additionally enable 'update outer.reply' in post-auth section for the inner-tunnel virtual server.
Don't do that. If you have "use_tunneled_reply" set, then what will happen is this: - you update outer.reply with the User-Name - when TTLS / PEAP finishes, it will toss the outer reply - and replace it with the reply from the inner tunnel
Observed that, - PEAP failed due to identity mismatch. (debug output attached)
Your NAS is broken. And arguably your FreeRADIUS configuration. The server is sending User-Name = "testing" back in an Access-Challenge. The NAS is using this User-Name in the next Access-Request. There are two things wrong here. One, you can filter Access-Challenge packets in FreeRADIUS. See raddb/sites-available/default. Look for Access-Challenge. Two, the NAS shouldn't be changing the User-Name in the middle of a session. This is ridiculous behavior. My $0.02 would be to file a bug with the NAS vendor, asking them to fix their software, so that it ignores User-Name in the Access-Challenge.
- TTLS-PAP sent inner user-id in the Access-Accept.
Seem like both use_tunneled_reply option and update outer.reply in post-auth section have inconsistent behavior.
Patches are welcome.
What would be the correct configuration to allow accurate accounting?
Set use_tunneled_reply = yes In the inner-tunnel post_auth section, do: update reply { User-Name := "%{User-Name}" } That works for me. Also, enable filtering of Access-Challenge packets as described above. And file a bug with the NAS vendor. Alan DeKok.