FreeRADIUS CoA Proxy [invalid Message-Authenticator] in response
I am trying to configure the coa proxy in latest Radius docker image 3.2.3. I have defined a client with a proper shared secret (message initiator) and also defined a home server with a shared secret (message destination). When I send the CoA message I see in debug that the radius server is proxying the request, the NAS at destination receiving it, it responds back to the radius server and then the radius server forwards that message back to the initiator. The problem is when I receive the final message from the radius server it has invalid message-authenticator. "Reply verification failed: Received packet from 192.168.2.157 with invalid Message-Authenticator! (Shared secret is incorrect.) I checked the shared secret on all sides, everything is as expected but somehow it signs the final message incorrectly. Thanks in advance. Attached is a debugfile of the freeradius And the request command and output is: echo " NAS-IP-Address = 192.168.2.224 Calling-Station-Id = 'BC:54:51:EF:70:AE' Event-Timestamp = $(date +%s) " | radclient -x 192.168.2.157:3799 disconnect testing123 Sent Disconnect-Request Id 7 from 0.0.0.0:33184 to 192.168.2.157:3799 length 51 NAS-IP-Address = 192.168.2.224 Calling-Station-Id = "BC:54:51:EF:70:AE" Event-Timestamp = "Oct 31 2023 13:29:27 MDT" (0) Reply verification failed: Received packet from 192.168.2.157 with invalid Message-Authenticator! (Shared secret is incorrect.)
On Oct 31, 2023, at 3:35 PM, Alexander Shulgin <alexs20@gmail.com> wrote:
I am trying to configure the coa proxy in latest Radius docker image 3.2.3.
I have defined a client with a proper shared secret (message initiator) and also defined a home server with a shared secret (message destination). When I send the CoA message I see in debug that the radius server is proxying the request, the NAS at destination receiving it, it responds back to the radius server and then the radius server forwards that message back to the initiator.
That's good. The Disconnect-Request packet is signed with the shared secret, so the server verifies it before processing the packet.
The problem is when I receive the final message from the radius server it has invalid message-authenticator.
Something is modifying the packet in transit. Run the server with -Xxxx (one of the few times this is necessary). It should print out the Disconnect-Request packet as hex. Run "radsniff" one the client, and it will print out the hex version of the packet it received. If they're different, then something is mangling the reply before radclient sees it. If the packets are the same, then something extremely weird is going on. Alan DeKok.
Or just run radclient -xxx ... and that will print out the hex packet, too.
On Oct 31, 2023, at 3:51 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 31, 2023, at 3:35 PM, Alexander Shulgin <alexs20@gmail.com> wrote:
I am trying to configure the coa proxy in latest Radius docker image 3.2.3.
I have defined a client with a proper shared secret (message initiator) and also defined a home server with a shared secret (message destination). When I send the CoA message I see in debug that the radius server is proxying the request, the NAS at destination receiving it, it responds back to the radius server and then the radius server forwards that message back to the initiator.
That's good. The Disconnect-Request packet is signed with the shared secret, so the server verifies it before processing the packet.
The problem is when I receive the final message from the radius server it has invalid message-authenticator.
Something is modifying the packet in transit.
Run the server with -Xxxx (one of the few times this is necessary). It should print out the Disconnect-Request packet as hex.
Run "radsniff" one the client, and it will print out the hex version of the packet it received.
If they're different, then something is mangling the reply before radclient sees it.
If the packets are the same, then something extremely weird is going on.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan, As you suggested I ran the server with -Xxxx flag and radclient with -xxx While it increased the debug level of the server, it did not change the output of the radclient. So i went forward and ran radsniff on both sides Attached are server2.txt (server log), radclient2.txt (radclient log), radsniff_client2.txt (radsniff output for the client) and radsniff_server2.txt (radsniff output for the server)
From what I see the final message from the server has exactly the same values as on client side, which means nothing changing the packet
Server: 2023-10-31 20:30:12.255945 (4) Disconnect-ACK Id 167 enp0s3: 192.168.2.227:42310 <- 192.168.2.157:3799 +0.002 +0.002 Event-Timestamp = "Oct 31 2023 20:30:12 UTC" Message-Authenticator = 0x680699937a7133452ba8dabe0e179856 Authenticator-Field = 0xf8c3e20b55fa591208f37ada73872184 Client: 2023-10-31 14:30:12.247761 (2) Disconnect-ACK Id 167 enp0s3: 192.168.2.227:42310 <- 192.168.2.157:3799 +0.002 +0.002 Event-Timestamp = "Oct 31 2023 14:30:12 MDT" Message-Authenticator = 0x680699937a7133452ba8dabe0e179856 Authenticator-Field = 0xf8c3e20b55fa591208f37ada73872184 Thanks, Alex On Tue, Oct 31, 2023 at 1:52 PM Alan DeKok <aland@deployingradius.com> wrote:
Or just run
radclient -xxx ...
and that will print out the hex packet, too.
On Oct 31, 2023, at 3:51 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 31, 2023, at 3:35 PM, Alexander Shulgin <alexs20@gmail.com> wrote:
I am trying to configure the coa proxy in latest Radius docker image
3.2.3.
I have defined a client with a proper shared secret (message initiator)
and
also defined a home server with a shared secret (message destination). When I send the CoA message I see in debug that the radius server is proxying the request, the NAS at destination receiving it, it responds back to the radius server and then the radius server forwards that message back to the initiator.
That's good. The Disconnect-Request packet is signed with the shared secret, so the server verifies it before processing the packet.
The problem is when I receive the final message from the radius server it has invalid message-authenticator.
Something is modifying the packet in transit.
Run the server with -Xxxx (one of the few times this is necessary). It should print out the Disconnect-Request packet as hex.
Run "radsniff" one the client, and it will print out the hex version of the packet it received.
If they're different, then something is mangling the reply before radclient sees it.
If the packets are the same, then something extremely weird is going on.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 31, 2023, at 4:45 PM, Alexander Shulgin <alexs20@gmail.com> wrote:
As you suggested I ran the server with -Xxxx flag and radclient with -xxx While it increased the debug level of the server, it did not change the output of the radclient. So i went forward and ran radsniff on both sides Attached are server2.txt (server log), radclient2.txt (radclient log), radsniff_client2.txt (radsniff output for the client) and radsniff_server2.txt (radsniff output for the server)
From what I see the final message from the server has exactly the same values as on client side, which means nothing changing the packet
Hmm... that's weird. Looking at the server debug output in more detail, the issue is that the home server is sending Message-Authenticator in the Disconnect-ACK. And the proxy is copying it back to the client unchanged. The proxy should instead calculate the correct value for Message-Authenticator when replying to the client. I've pushed a fix to the v3.2.x and v3.0.x branches. Alan DeKok.
participants (2)
-
Alan DeKok -
Alexander Shulgin