[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    RE: proxy issue
From:       <adrian.p.smith () bt ! com>
Date:       2020-10-19 10:47:29
Message-ID: CWXP123MB19583B9225D49A86FF1E4B0BA91E0 () CWXP123MB1958 ! GBRP123 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

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@lists.freeradius.org> On Behalf Of \
                Alan DeKok
Sent: 16 October 2020 13:44
To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>
Subject: Re: proxy issue

On Oct 16, 2020, at 3:56 AM, <adrian.p.smith@bt.com> <adrian.p.smith@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%2F \
list%2Fusers.html&amp;data=04%7C01%7Cadrian.p.smith%40bt.com%7Ce2bbaeaea2bb4796695508d \
871d13f64%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637384490818959969%7CUnknown%7C \
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2B4%2FL9mNbFSVjSaIcrn6qS5Du7rQY9Qd9yxiRDDKP3pc%3D&amp;reserved=0


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]