Accounting-Request with invalid signature
Hello gents, I've been trying to solve this problem for a couple of days now. I'm asking for your expert advise since I'm not getting anywhere near a solution: The problem is when FreeRADIUS receives a Accounting-Request it drops the packet without response due to a problem with the signature: rad_recv: Accounting-Request packet from host x.x.x.x port 64514, id=1, length=287 Received Accounting-Request packet from x.x.x.x with invalid signature! (Shared secret is incorrect.) Dropping packet without response. The Access-Request are ok: rad_recv: Access-Request packet from host x.x.x.x port 64986, id=236, length=102 User-Name = "test" User-Password = "\2517Rq\2308Uv\"\204\220\341\377\244(\363" NAS-IP-Address = x.x.x.x NAS-Identifier = "NPR_GGSN_01" Called-Station-Id = "wap1.btcbahamas.com" Framed-Protocol = GPRS-PDP-Context Service-Type = Framed-User NAS-Port-Type = Virtual +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 61 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Found existing Auth-Type, not changing it. ++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 236 to x.x.x.x port 64986 The shared secret key has special characters in it such as $-sign and /-sign. The client is a Juniper NAS. These are the questions I have: - Any issues with FreeRADIUS Accounting-Request in combination with a secret key containing special characters? - Why is the access-request having no issues with these special characters? - Anyone bumped into a similar problems in combination with a juniper NAS - Is there a way to figure out the secret-key the client is using? Thank you. Regards, Shurbann Martes
Shurbann Martes wrote:
The problem is when FreeRADIUS receives a Accounting-Request it drops the packet without response due to a problem with the signature:
rad_recv: Accounting-Request packet from host x.x.x.x port 64514, id=1, length=287 Received Accounting-Request packet from x.x.x.x with invalid signature! (Shared secret is incorrect.) Dropping packet without response.
That message is pretty clear.
The Access-Request are ok:
No, they're not.
rad_recv: Access-Request packet from host x.x.x.x port 64986, id=236, length=102 User-Name = "test" User-Password = "\2517Rq\2308Uv\"\204\220\341\377\244(\363"
The password is garbage. This means that the shared secret is wrong.
[files] users: Matched entry DEFAULT at line 61
In which you set "Auth-Type := Accept", which doesn't check the password.
The shared secret key has special characters in it such as $-sign and /-sign.
If you enter it correctly, that should work. So.. you probably didn't enter it correctly.
The client is a Juniper NAS.
These are the questions I have:
* Any issues with FreeRADIUS Accounting-Request in combination with a secret key containing special characters?
No.
* Why is the access-request having no issues with these special characters?
Because you edited the default configuration and broke it.
* Anyone bumped into a similar problems in combination with a juniper NAS
No. This isn't a Juniper problem.
* Is there a way to figure out the secret-key the client is using?
No. Try using a simple shared secret. Alan DeKok.
Hi Alan, Ok I understand what you're saying. I'm just copy-pasting the secret-key to the clients.conf: client x.x.x.x/16 { secret = <secret key with special characters in it> shortname = private-network-2 } You're saying that the only reason for this failure is wrong secret key? In other words they gave me the wrong secret. Regards, Shurbann Martes On Sun, Mar 18, 2012 at 4:20 PM, Alan DeKok <aland@deployingradius.com>wrote:
Shurbann Martes wrote:
The problem is when FreeRADIUS receives a Accounting-Request it drops the packet without response due to a problem with the signature:
rad_recv: Accounting-Request packet from host x.x.x.x port 64514, id=1, length=287 Received Accounting-Request packet from x.x.x.x with invalid signature! (Shared secret is incorrect.) Dropping packet without response.
That message is pretty clear.
The Access-Request are ok:
No, they're not.
rad_recv: Access-Request packet from host x.x.x.x port 64986, id=236, length=102 User-Name = "test" User-Password = "\2517Rq\2308Uv\"\204\220\341\377\244(\363"
The password is garbage. This means that the shared secret is wrong.
[files] users: Matched entry DEFAULT at line 61
In which you set "Auth-Type := Accept", which doesn't check the password.
The shared secret key has special characters in it such as $-sign and /-sign.
If you enter it correctly, that should work.
So.. you probably didn't enter it correctly.
The client is a Juniper NAS.
These are the questions I have:
* Any issues with FreeRADIUS Accounting-Request in combination with a secret key containing special characters?
No.
* Why is the access-request having no issues with these special characters?
Because you edited the default configuration and broke it.
* Anyone bumped into a similar problems in combination with a juniper NAS
No. This isn't a Juniper problem.
* Is there a way to figure out the secret-key the client is using?
No.
Try using a simple shared secret.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
One more question: Are there any limitation to the secret key? I.e. some special characters not allowed or length? I'm asking this because I can not believe this problem is caused by to this person giving me the wrong secret-key. Regards, Shurbann Martes On Sun, Mar 18, 2012 at 5:15 PM, Shurbann Martes <shurbann@gmail.com> wrote:
Hi Alan,
Ok I understand what you're saying.
I'm just copy-pasting the secret-key to the clients.conf:
client x.x.x.x/16 { secret = <secret key with special characters in it> shortname = private-network-2 }
You're saying that the only reason for this failure is wrong secret key? In other words they gave me the wrong secret.
Regards, Shurbann Martes
On Sun, Mar 18, 2012 at 4:20 PM, Alan DeKok <aland@deployingradius.com>wrote:
Shurbann Martes wrote:
The problem is when FreeRADIUS receives a Accounting-Request it drops the packet without response due to a problem with the signature:
rad_recv: Accounting-Request packet from host x.x.x.x port 64514, id=1, length=287 Received Accounting-Request packet from x.x.x.x with invalid signature! (Shared secret is incorrect.) Dropping packet without response.
That message is pretty clear.
The Access-Request are ok:
No, they're not.
rad_recv: Access-Request packet from host x.x.x.x port 64986, id=236, length=102 User-Name = "test" User-Password = "\2517Rq\2308Uv\"\204\220\341\377\244(\363"
The password is garbage. This means that the shared secret is wrong.
[files] users: Matched entry DEFAULT at line 61
In which you set "Auth-Type := Accept", which doesn't check the password.
The shared secret key has special characters in it such as $-sign and /-sign.
If you enter it correctly, that should work.
So.. you probably didn't enter it correctly.
The client is a Juniper NAS.
These are the questions I have:
* Any issues with FreeRADIUS Accounting-Request in combination with a secret key containing special characters?
No.
* Why is the access-request having no issues with these special characters?
Because you edited the default configuration and broke it.
* Anyone bumped into a similar problems in combination with a juniper NAS
No. This isn't a Juniper problem.
* Is there a way to figure out the secret-key the client is using?
No.
Try using a simple shared secret.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shurbann Martes wrote:
Are there any limitation to the secret key? I.e. some special characters not allowed or length?
All characters are allowed. HOWEVER, some characters, like "$" and "\" require escaping. Put single quotes around the secret, and it could work, too. See "man unlang" for how strings work in the configuration files. Alan DeKok.
participants (2)
-
Alan DeKok -
Shurbann Martes