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

[Chris Griffin]

Hi Alan,
  I did some testing and I am still seeing an issue.
Although fake->reply->code = PW_CODE_ACCESS_ACCEPT is now set, a few lines
later where:

process_post_proxy(0, fake);

is called, it gets reset to PW_CODE_ACCESS_CHALLENGE and so in rad_postauth
it builds the VP with Post-Auth-Type, Challenge.

This appears to be a result of having eap in the post-proxy configuration
in proxy-inner-tunnel because we are not proxying as EAP.  When I remove
it, this patch appears effective, but EAP seems to fall apart, as the
configuration guidance would suggest.

Any further thoughts?
Tnx
Chris

On Mon, Aug 15, 2022 at 4:08 PM Alan DeKok <aland at deployingradius.com>
wrote:

> 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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>