Hi Alan,
Do you reckon that using tunneled reply (which we obviously need to support CUI on eduroam) shouldn't break MACSEC? If so, why are is activating it in the FR default config breaking MACSEC in my lab and what might be a possible fix for this?
this sort of thing is usually because you are leaking things from the inner to the outer which clash with the NAS's idea of whats going on - eg you are leaking the User-Name from the inner to the outer...thus negating the point of an anonymous outerID - which is what CUI is actually for ;-)
Thanks for the hint. I've already implemented a reset of the outer User-Name reply in post-auth to the one received in the outer tunnel request. Somewhat that feels a bit counter intuitive but it was the logical consequence of the howto telling me I'd need use_tunneled_reply for CUI to work at all. I'd love to not use use_tunneled_reply, but so far my tests failed to update the outer reply with the value from the inner tunnel directly. So, how would I be leaking just this info about the "real" user-Name from the inner tunnel alone without use_tunneled_reply?
to confirm/verify, either dont play with/expose the inner User-Name or set the client to have the same outerid as its innerid (eg classic Windows behaviour)
We never exposed the inner User-Name for obvious reasons. So do you reckon it's either CUI or MACSEC working? Can use_tunneled_reply be updated dynamically based upon NAS-Port-Type? I'm also still trying to understand what breaks PEAP-MSCHAPv2 when pulling authentication from AD rather than using local accounts on the FR (the latter works just fine with MACSEC). Best, Kilian