Hi, I have the following setup: freeradius is compiled with udpfromto. The reason is that advertised public service address is on lo:1 interface (because the freeradius is behind load balancer in routed mode not in nat mode). There is also another public ip on the eth interface to receive packets from the load balancer. The freeradius itself works well in that setup. The problem is radclient. When i send the packet of type COA-Disconnect to the nas using Packet-Src-IP-Address in the request with the value of lo:0 public ip address to terminate the user session i get this response: rad_recv: Disconnect-ACK packet from host 1.1.1.1 port 3799, id=110, length=43 rad_verify: Received Disconnect-ACK packet from home server 1.1.1.1 port 3799 with invalid signature! (Shared secret is incorrect.) radclient: no response from server for ID 110 socket 3 user is disconnected properly but radclient does not recognize that response ( I've used just -r 1 in this case, when using -r 3 i see additional packets sent but they of course get a Disconnect-NAK) i traced the communication and only one packet send and one is received. Looks like the problem is in the logic of rad_verify function when using Packet-Src-IP-Address. Thanks, Vladimir
rad_recv: Disconnect-ACK packet from host 1.1.1.1 port 3799, id=110, length=43 rad_verify: Received Disconnect-ACK packet from home server 1.1.1.1 port 3799 with invalid signature! (Shared secret is incorrect.) radclient: no response from server for ID 110 socket 3
user is disconnected properly but radclient does not recognize that response ( I've used just -r 1 in this case, when using -r 3 i see additional packets sent but they of course get a Disconnect-NAK)
No. It does recognise the response, it says pretty explicitly it recognised the response, it's saying that the value of the Message-Authenticator is incorrect.
i traced the communication and only one packet send and one is received.
Looks like the problem is in the logic of rad_verify function when using Packet-Src-IP-Address.
Have you actually verified the Message-Authenticator returned in the Disconnect-Ack is correct? When a Message-Authenticator Attribute is included within a CoA- ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated. -Arran
I am just pointing out that this is not occurring when packet is sent directly over wire without PACKET-Src-IP-Address mangling over originating ip on another setup (same binaries) to the same nas. Vladimir ________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: Wednesday, October 17, 2012 11:31 AM To: FreeRadius developers mailing list Subject: Re: problem with radclient
rad_recv: Disconnect-ACK packet from host 1.1.1.1 port 3799, id=110, length=43 rad_verify: Received Disconnect-ACK packet from home server 1.1.1.1 port 3799 with invalid signature! (Shared secret is incorrect.) radclient: no response from server for ID 110 socket 3
user is disconnected properly but radclient does not recognize that response ( I've used just -r 1 in this case, when using -r 3 i see additional packets sent but they of course get a Disconnect-NAK)
No. It does recognise the response, it says pretty explicitly it recognised the response, it's saying that the value of the Message-Authenticator is incorrect.
i traced the communication and only one packet send and one is received.
Looks like the problem is in the logic of rad_verify function when using Packet-Src-IP-Address.
Have you actually verified the Message-Authenticator returned in the Disconnect-Ack is correct? When a Message-Authenticator Attribute is included within a CoA- ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 17 Oct 2012, at 10:48, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
I am just pointing out that this is not occurring when packet is sent directly over wire without PACKET-Src-IP-Address mangling over originating ip on another setup (same binaries) to the same nas.
... so the NAS probably doesn't have the correct shared secret associated with the src IP address in the packet. Check your traces to see that it's set to what you expect. In your attribute list include the AVP: Message-Authenticator = 0x00 your NAS will probably stop responding to disconnect requests (if it actually validates the Message-Authenticator). Read through the code in radclient.c https://github.com/FreeRADIUS/freeradius-server/blob/master/src/main/radclie... The call to rad_verify is just using the secret specified on the command line, it is not dependent on src IP address. UDP packet headers are *NOT* used when calculating the Message-Authenticator as shown by the RFC snippet I posted previously. -Arran
________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: Wednesday, October 17, 2012 12:15 PM To: FreeRadius developers mailing list Subject: Re: problem with radclient On 17 Oct 2012, at 10:48, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
I am just pointing out that this is not occurring when packet is sent directly over wire without PACKET-Src-IP-Address mangling over originating ip on another setup (same binaries) to the same nas.
... so the NAS probably doesn't have the correct shared secret associated with the src IP address in the packet. Check your traces to see that it's set to what you expect. if packet is created to come from PACKET-Src-Ip-Address then i have the correct secret. In your attribute list include the AVP: Message-Authenticator = 0x00 your NAS will probably stop responding to disconnect requests (if it actually validates the Message-Authenticator). It responded with an Disconnect-ACK again Read through the code in radclient.c https://github.com/FreeRADIUS/freeradius-server/blob/master/src/main/radclie... The call to rad_verify is just using the secret specified on the command line, it is not dependent on src IP address. UDP packet headers are *NOT* used when calculating the Message-Authenticator as shown by the RFC snippet I posted previously. I will need to go trough the code again... -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 17 Oct 2012, at 11:31, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: Wednesday, October 17, 2012 12:15 PM To: FreeRadius developers mailing list Subject: Re: problem with radclient
On 17 Oct 2012, at 10:48, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
I am just pointing out that this is not occurring when packet is sent directly over wire without PACKET-Src-IP-Address mangling over originating ip on another setup (same binaries) to the same nas.
... so the NAS probably doesn't have the correct shared secret associated with the src IP address in the packet. Check your traces to see that it's set to what you expect.
if packet is created to come from PACKET-Src-Ip-Address then i have the correct secret.
Have you verified it does? Without going through the code i'm not even sure if specifying Packet-Src-IP-Address is supported, can you point to documentation that says this?
In your attribute list include the AVP:
Message-Authenticator = 0x00
your NAS will probably stop responding to disconnect requests (if it actually validates the Message-Authenticator).
It responded with an Disconnect-ACK again
It may not be validating the message authenticator. If you change the shared secret (and include the Message-Authenticator) does it still respond with Disconnect-Ack? -Arran
On 10/17/2012 10:57 PM, Arran Cudbard-Bell wrote:
Have you verified it does? Without going through the code i'm not even sure if specifying Packet-Src-IP-Address is supported, can you point to documentation that says this?
IIRC, radclient looks for Packet-Src-IP-Address and then bind()s the UDP/TCP socket to that IP for sending. I never really understand how people have all these crazy problems with UDP IPs and so on, or what udpfromto is for - we just bind sockets to the correct IPs and it all works :o/
The scenario is that radius is behind load balancer which advertizes it's public ip address and forward packets to another ip address on radius (which has different ip) . Advertized public ip address on radius is binded to lo:0 interface. Hence the need for udpfromto. This is a setup to have HA cluster of radius servers and only one advertized ip for the NAS. Vladimir ________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Thursday, October 18, 2012 1:03 AM To: freeradius-devel@lists.freeradius.org Subject: Re: problem with radclient On 10/17/2012 10:57 PM, Arran Cudbard-Bell wrote:
Have you verified it does? Without going through the code i'm not even sure if specifying Packet-Src-IP-Address is supported, can you point to documentation that says this?
IIRC, radclient looks for Packet-Src-IP-Address and then bind()s the UDP/TCP socket to that IP for sending. I never really understand how people have all these crazy problems with UDP IPs and so on, or what udpfromto is for - we just bind sockets to the correct IPs and it all works :o/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Thu, Oct 18, 2012 at 1:18 PM, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
The scenario is that radius is behind load balancer which advertizes it's public ip address and forward packets to another ip address on radius (which has different ip) . Advertized public ip address on radius is binded to lo:0 interface. Hence the need for udpfromto. This is a setup to have HA cluster of radius servers and only one advertized ip for the NAS.
So ... what does that have to do with radclient, again? If I understand you correctly, you only need proxy. You can add/remove attributes in the packets you send to the remote radius, and in the packets you return back to the NAS. And you should be able to generate COA packet from the server (with unlang) instead of manually using radclient. Yes, radclient could probably be improved. I'm just saying that you might not need it at all. -- Fajar
________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Fajar A. Nugraha [list@fajar.net] Sent: Thursday, October 18, 2012 8:27 AM To: FreeRadius developers mailing list Subject: Re: problem with radclient On Thu, Oct 18, 2012 at 1:18 PM, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
The scenario is that radius is behind load balancer which advertizes it's public ip address and forward packets to another ip address on radius (which has different ip) . Advertized public ip address on radius is binded to lo:0 interface. Hence the need for udpfromto. This is a setup to have HA cluster of radius servers and only one advertized ip for the NAS.
So ... what does that have to do with radclient, again? radclient is called from the server which has radius advertized ip on lo:0 not on eth0. So if i send packet without Packet-SRC-IP-Address radclient sends it from eth0 ip address. If I understand you correctly, you only need proxy. You can add/remove attributes in the packets you send to the remote radius, and in the packets you return back to the NAS. And you should be able to generate COA packet from the server (with unlang) instead of manually using radclient. i need to call COA disconnects and other COA packet (service change) upon request from CRM . I don't see how to use the coa in the radius it self as it can be called only upon auth and acct packet processing. Yes, radclient could probably be improved. I'm just saying that you might not need it at all. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
<nice but completely irrelevant discussion>
i need to call COA disconnects and other COA packet (service change) upon request from CRM . I don't see how to use the coa in the radius it self as it can be called only upon auth and acct packet processing.
*sigh* Ok reading through the code it looks like that error message is more specific, it's actually saying the Response Authenticator is incorrect, not the Message-Authenticator. MD5(Code+ID+Length+RequestAuth+Attributes+Secret) Again the response authenticator does not include anything from the UDP packet header, so if it is incorrect, it's because the NAS has not selected the correct shared secret. I'm going to change the debug messages to remove the ambiguous terminology, as 'signature' appears nowhere in the RFCs and could conceivably refer to either the Response Authenticator or the Message-Authenticator. I still believe the root cause to be the same. -Arran
On 18 Oct 2012, at 10:02, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
<nice but completely irrelevant discussion>
i need to call COA disconnects and other COA packet (service change) upon request from CRM . I don't see how to use the coa in the radius it self as it can be called only upon auth and acct packet processing.
*sigh*
Ok reading through the code it looks like that error message is more specific, it's actually saying the Response Authenticator is incorrect, not the Message-Authenticator.
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
Again the response authenticator does not include anything from the UDP packet header, so if it is incorrect, it's because the NAS has not selected the correct shared secret.
Hmm, but I guess that doesn't make sense either. Could you just provide traces so we don't have to guess? :) -Arran
On Thu, Oct 18, 2012 at 01:27:58PM +0700, Fajar A. Nugraha wrote:
On Thu, Oct 18, 2012 at 1:18 PM, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
The scenario is that radius is behind load balancer which advertizes it's public ip address and forward packets to another ip address on radius (which has different ip) . Advertized public ip address on radius is binded to lo:0 interface. Hence the need for udpfromto. This is a setup to have HA cluster of radius servers and only one advertized ip for the NAS.
So ... what does that have to do with radclient, again?
FWIW, I use radclient in a similar way as part of a test suite. There are some cases where I need to send a test packet which appears to come from a particular IP address (so that the "preprocess" module adds a missing NAS-IP-Address based on source address) I create loopback interfaces bound to the appropriate source IPs, and then invoke radclient with an additional attribute Packet-Src-IP-Address = x.x.x.x This works fine, and I don't have any problem with message authenticators. I'm not sending CoA packets, just regular Access-Request, and I'm not behind any sort of load balancer. But since the authenticator is calculated without regard to the source/destination IP addresses or ports, it should make no difference if it is NAT'd. To debug this problem, I suggest that the OP use tcpdump -X to capture the packet, and calculate the message authenticator by hand to see if it's correct. RFC 2866 section 3 gives the algorithm (note that CoA uses the same algorithm as Accounting-Request - see RFC 3576 section 2.3) Using tcpdump -ieth0 -s0 -nnX udp port 1812, packet will look something like this: 0x0000: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX 0x0010: XXXX XXXX UUUU UUUU UUUU UUUU ccii llll 0x0020: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 0x0030: aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa 0x0040: 692e 636f 2e75 6b28 0600 0000 032c 1b30 i.co.uk(.....,.0 ... where XX = IP header, UU = UDP header, cc = code (should be 2b for CoA-Request), ii = identifier, llll = length, AAAA = message authenticator, aaaa.... = RADIUS attributes You can verify the authenticator like this, using ruby: $ irb
require 'digest/md5' => true Digest::MD5.hexdigest(["cciillll00000000000000000000000000000000aaaa...."].pack("H*") + "secret")
Substituting the appropriate hex digits for cc, ii, llll, and aaaa.... and the shared secret. Here is a worked example. echo 'Reply-Message="foo"' | radclient -x localhost coa testing123 If you run tcpdump -ilo -s0 -nnX in another window at the same time you see: 09:25:44.096721 IP 127.0.0.1.34731 > 127.0.0.1.3799: UDP, length 25 0x0000: 4500 0035 c33e 0000 4011 b977 7f00 0001 E..5.>..@..w.... 0x0010: 7f00 0001 87ab 0ed7 0021 fe34 2bf6 0019 .........!.4+... 0x0020: 363e 0b98 6d1c 69c2 2981 19c6 4ad1 74c9 6>..m.i.)...J.t. 0x0030: 1205 666f 6f ..foo Now you calculate:
Digest::MD5.hexdigest(["2bf60019"+"00000000000000000000000000000000"+"1205666f6f"].pack("H*") + "testing123") => "363e0b986d1c69c2298119c64ad174c9"
and you can see this matches the authenticator in the packet at offset 0x0020. If the authenticator is calculated correctly by radclient, but is being rejected as invalid by the NAS, then either the NAS has the wrong shared secret (most likely) or is using the wrong algorithm to calculate the authenticator for CoA. Note that the NAS will select the shared secret to use based on the source IP of the packet as seen when it arrives at the NAS. Regards, Brian.
On 18/10/12 07:18, Vladimir Grujić wrote:
The scenario is that radius is behind load balancer which advertizes it's public ip address and forward packets to another ip address on radius (which has different ip) . Advertized public ip address on radius is binded to lo:0 interface. Hence the need for udpfromto. This is a setup to have HA cluster of radius servers and only one advertized ip for the NAS.
We run a virtually identical setup, and don't need udpfromto. Instead, we bind the "listen" section to the virtual IP. Replies are always sent out of the socket they came in on, so the source IP "just works".
On 18 Oct 2012, at 00:03, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 10/17/2012 10:57 PM, Arran Cudbard-Bell wrote:
Have you verified it does? Without going through the code i'm not even sure if specifying Packet-Src-IP-Address is supported, can you point to documentation that says this?
IIRC, radclient looks for Packet-Src-IP-Address and then bind()s the UDP/TCP socket to that IP for sending.
Ah yes: https://github.com/FreeRADIUS/freeradius-server/blob/v2.1.x/src/main/radclie... It's just not in the man pages, or google...
participants (5)
-
Arran Cudbard-Bell -
Brian Candler -
Fajar A. Nugraha -
Phil Mayers -
Vladimir Grujić