Issues with post-auth not running in inner-tunnel/proxy-inner-tunnel

[Alan DeKok]

On Aug 12, 2022, at 12:05 PM, Chris Griffin <cgriffin352 at 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.