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.