Proxying with radsec/TLS, Access-Reject leads to "spoofed proxy reply"

Alan DeKok aland at deployingradius.com
Wed Dec 23 17:09:27 CET 2015


On Dec 23, 2015, at 10:23 AM, Susan Barnes <barnes at rrz.uni-koeln.de> wrote:
> I am playing with radsec. I have set up a proxy-connection between our staging server and an additional testserver to act as homeserver.
> 
> Both servers are v3.0.10.
> 
> What I have managed so far is:
> The staging-server can contact the homeserver and establish a TLS-secured connection.
> 
> The staging server sends a request to the homeserver and the homeserver will process it.
> 
> The homeserver replies.
> 
> If the homeserver rejects the Request, the staging-server will not accept the reply, but discards it with
> "Ignoring spoofed proxy reply. Signature is invalid"
>
> If the homeserver sends an Access-Accept, the staging-server will accept the reply.

  That's weird.  The code path is pretty much the same for both packets.

> I have tried the proxy setup without radsec/TLS. In that case both Accept and Reject work.

  OK.  I'll have to take a look at it.  Probably next week.

> I have poked around with gdb on the staging server a bit.
> Within rad_verify() at the point of calc_replydigest() we get to the point of
> "Received %s packet from home server %s port %d with invalid Response Authenticator! (Shared secret is incorrect.)",
> (did not appear anywhere in the Debug Output).
> 
> 
> Does anyone have an idea what the problem could be?

  Not really.. the code paths for accept / reject are pretty much identical.  Apparently not identical enough, though.

  Either the home server is calculating the authenticator wrong, or the proxy is calculating it wrong.  Knowing which one would help.

  I'd suggest using gdb to look at rad_verify() on the proxy, and rad_sign() on the home server.  Ensure that the "secret" variable is set to "radsec" on both ends.

  Alan DeKok.




More information about the Freeradius-Users mailing list