On Aug 12, 2022, at 12:05 PM, Chris Griffin <cgriffin352@gmail.com> wrote:
1. The rad_postauth wasn't being called because "proxy_tunneled_request_as_eap" was commented out. I had made the wrong assumption about what the default was. I uncommented it and set it to no and rad_postauth was correctly called. That was set to no in my production 3.2 platform but not this test instance.
OK.
2. Digging into the auth.c:
Based on this code:
/* * If a method was chosen, use that. */ if (vp) { postauth_type = vp->vp_integer; RDEBUG2("Using Post-Auth-Type %s", dict_valnamebyattr(PW_POST_AUTH_TYPE, 0, postauth_type)); }
It is setting the postauth_type to "Challenge" and I am getting this feedback in the debugs:
(8) eap: EAP session adding &reply:State = 0x784b1b4e799f01a6 (8) [eap] = ok (8) } # post-proxy = ok (8) Using Post-Auth-Type Challenge (8) Post-Auth-Type sub-section not found. Ignoring.
It seems that it is only looking for a Post-Auth-Type Challenge section in post-auth and if it doesn't have it, the section is ignored.
It only sets "Post-Auth-Type = Challenge" when running an Access-Challenge though the "post-auth" section. It should be using the fake request here for the running post-auth in the "inner-tunnel" virtual server.
Just as a test I changed it it:
if (0) {....
To avoid setting the postauth_type and the post-auth section is now properly called:
(8) # Executing section post-auth from file /opt/freeradius-test/etc/raddb/sites-enabled/proxy-inner-tunnel (8) post-auth {
In my very brief testing, everything seems to work now, but this feels "very wrong" as a solution. Do you have any feedback as to the correct thing to do? Should I just put everything for post-auth in a challenge section or is that being mis-set somewhere and causing this result?
It should be running post-auth { ... }, and not the "challenge" bit. I've pushed a fix in 851cb91 which should fix that. Alan DeKok.