Thanks for the help, Phil and Alan. This message is pretty much an FYI/wrapup for the archives (and for me, since it might be a bit before I get back to it.) The users I want to proxy have a fairly programmatic username pattern, so I think the best thing for me is to expression match in a users file (as opposed to hints or realms.) My setup looks like: authorize { preprocess eap files Autz-Type EAPINNER { eapfiles mschap } files has a DEFAULT line that catches the RADIUS server stripping through the tunnels, and applies it to the EAPINNER Autz-Type: DEFAULT NAS-IP-Address == "127.0.0.1", Autz-Type := EAPINNER The eapfiles is a second instance of the users file with the line: DEFAULT User-Name =~ "^vpn[0123456789]+$", Proxy-to-Realm := "VPNaccts" (I wonder if I couldn't combine the NAS-IP-Address, User-Name and Proxy-to-Realm in the first users file. Maybe I'll try that later. If I did it on the outer loop, it proxied the full EAP session, instead of just the inner authentication.) In eap.conf, setting peap's proxy_tunneled_request_as_eap toggle let me control whether I sent on EAP messages or MSCHAP messages. (My copy of the config didn't have that option, but it worked when I added it from the 1.1.3 eap.conf) Unfortunately, my upstream RADIUS server doesn't yet support MSCHAP or EAP, so I'm waiting on that. But I'm pleased with what I've been able to do so far. The catch I ran into involved the mschap section not authenticating off the User-Password in the users file if I had ntlm_auth line configured. This is my test system, and I don't have samba/winbindd configured so those attempts always failed, but it never seemed to fall back to figuring out itself. That made troubleshooting difficult when I couldn't get the simple users file entry to work. Commenting out the ntlm_auth line did the trick. I haven't changed anything on our production servers, but it must do things differently as we have ntlm_auth configured and authenticating from the AD or a sql database with local passwords. Maybe FreeRADIUS handles different ntlm_auth failures differently (cannot bind versus bad user password?) Until the upstream server gets the functionality I'm looking for, there were a few possible future issues I wanted to document before I lost them. If I set copy_request_to_tunnel in peap to yes, my NAS-IP-Address == 127.0.0.1 trick doesn't work. I was also concerned that proxying seems to keep the NAS-IP-Address set to 127.0.0.1, and I didn't know if the upstream provider would be concerned about that. I put a setting in the preproxy_users file to set that to an allowed NAS IP, but didn't get to fully test/confirm that worked. Thanks again for the help, and great product! Dave