Problems with FreeRADIUS in a jail

[Scott Lambert]

On Wed, Sep 19, 2007 at 09:05:38PM +0000, Bjoern A. Zeeb wrote:
> On Tue, 18 Sep 2007, Scott Lambert wrote:
> 
> Hi,
> 
> >I've been trying to get FreeRADIUS 2.0 working inside a FreeBSD
> >6.2-STABLE jail.
> >
> >The work I've been doing with the Alan DeKok of FreeRADIUS starts with
> >this message:
> >
> >https://lists.freeradius.org/pipermail/freeradius-users/2007-September/065883.html
> >
> >Here is the thread index :
> >
> >https://lists.freeradius.org/pipermail/freeradius-users/2007-September/thread.html#65883
> >
> >I am way out of my depth at this point.  I thought I had the problem
> >found yesterday in FreeRADIUS but Alan says what I did to "fix" it
> >shouldn't work at all.
> 
> if you mean the == INADDR_ANY => != change, Alan should be right from
> the code you pasted into the mails.

Yeah, I dug in and tried to prove myself right yesterday.  I was
completely wrong.  I don't know how that ended up working on all of my
test cases.

> > He seems to think it is a jail problem.
> 
> I haven't read their code but from what I got in the thread it sounds
> like they seem to be overly clever doing assumtions that are just
> wrong (no matter if it's a jail or not).

That's my impression.
 
> So it seems
> 
> C: bind(INADDR_ANY)
> C: getsockname returns an address inside the jail
> C: packet gets out to dstaddr
> 
> S: the packets gets proccessed
> S: a reply is send to the IP address from the dstaddr (as used by the 
> client)
>    and it should always be that way (no matter if the C: is in jail or not)
> 
> C: packets is recved
> C: ip address is checked and to whatever it would be checked should
>    match - in case they have the IP address it would match, in case they
>    bound to inaddr_any all addresses should match.
> 
> They might have problems matching up their internal state or
> overwriting something somewhere.
> 
> I would assume what could happen is that bind to INADDR_ANY,
> getsockname returns != INADDR_ANY thus inaddr_any = 0;
> On recv. they fill in the match from the Client = * definition
> which would be INADDR_ANY but inaddr_any is set to 0 and thus the
> check on the ip address does not match because they would need both
> INADDR_ANY and inaddr_any = 1 for that (for whatever reason they need
> to duplicate that information).
> 
> But that's just a wild guess...

I wish my wild guesses were a tenth that good.  Last night, I found a
place where they unconditionally set reply->dst_ipaddr = client_ipaddr.
I think that is exactly what you are postulating above.  It looks like
they had reasons for setting that, but I can't tell what circumstances
would necessitate it.

I posted another message to the thread about that but Alan hasn't
responded to that post just yet so either he didn't have time to
mess with me today, or he may be checking into the validity of that
unconditional assignment.  I'm hoping for the latter because I would
like to get this resolved and move on with putting it in production. :-)

Thanks for the help!

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert at lambertfam.org