proxy issue

[adrian.p.smith at bt.com]

Thanks for the explanation. I think our issues are caused by some slightly dubious config and/or software on the downstream vendor service.

We will be updating that to do things in a different way.

Ragards.

-----Original Message-----
From: Freeradius-Users <freeradius-users-bounces+adrian.p.smith=bt.com at lists.freeradius.org> On Behalf Of Alan DeKok
Sent: 16 October 2020 13:44
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: Re: proxy issue

On Oct 16, 2020, at 3:56 AM, <adrian.p.smith at bt.com> <adrian.p.smith at bt.com> wrote:
> Using FreeRadius (3.0.15) to proxy some traffic and under certain circumstances the Access-Accept from the remote server appears to be ignored and we see the log message from this code in process.c.

  Yup.

> /*
>            *          No reply, BUT the current packet fails verification:
>            *          ignore it.  This does the MD5 calculations in the
>            *          server core, but I guess we can fix that later.
>            */
>            if (!request->proxy_reply &&
>                (rad_verify(packet, request->proxy,
>                                    request->home_server->secret) != 0)) {
>                        DEBUG("Ignoring spoofed proxy reply.  Signature is invalid");
>                        return 0;
>            }

  There's a reply, but it's getting mangled in transit.  *Or*, the other end is using the wrong shared secret, which is very unlikely.

> If we use radclient to send the same packet direct to the remote server, the reply is received with no issues. We have tried upgrading to 3.0.21 but the same code seems to be invoked. The comment in the code is a little cryptic and I'm wondering if anyone can shed any light on what might be causing this?

  FreeRADIUS sends a proxied packe to a home server.  Say Access-Request, ID 1, using a particular src/dst IP/port.  That packet also contains a 16-byte authenticator field.  Which is used to sign the reply.

  So when an Access-Accept reply comes back, the server finds the original Access-Request by swapping src/dst ip/port.  And then finds an Access-Accept for ID 1.  This reply packet *must* be signed using both the shared secret, and the 16-byte authenticator field from the Access-Request.

  FreeRADIUS calculates what the signature *should* be, and compares it to what's in the Access-Accept packet.  If they differ, then it's a spoofed / incorrect packet.  And is dropped.

  TBH, there's nothing that can be done on the FreeRADIUS side to fix this.  You *don't* want it accepting replies which are incorrectly signed.  That way lies madness (and exploits).  You just have to realize that it's 2020, and the network is imperfect.  Some small amount of packets will get lost or corrupted.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=04%7C01%7Cadrian.p.smith%40bt.com%7Ce2bbaeaea2bb4796695508d871d13f64%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637384490818959969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B4%2FL9mNbFSVjSaIcrn6qS5Du7rQY9Qd9yxiRDDKP3pc%3D&reserved=0