Hello! I have set up my freeradius 1.1.3 server to use proxy feature. User@domain1 are redirected to the radius2 which store the usernames and password for that user. It seems that my nas is sending encrypted passwords but radius2 only accept clear text passwords. And my radius1 is proxying the request of the user@doamin1 with encrypted passwords to radius2. What can I do to send the clear-text passwords to radius2? Thanks. Luis
Luis Galan wrote:
It seems that my nas is sending encrypted passwords
No. If the User-Password field is garbage in debugging mode, it's because the shared secret is wrong. Fix it.
but radius2 only accept clear text passwords. And my radius1 is proxying the request of the user@doamin1 with encrypted passwords to radius2.
What can I do to send the clear-text passwords to radius2?
Use the correct shared secret between the NAS and radius1. Alan DeKok.
Hello! The secret key between nas and radius1 is right. In debug mode I receive a clear password: Sending Access-Request of id 0 to radius2 port 1645 User-Password = "estestA243" NAS-Identifier = "10.1.0.102" User-Name = "estest@domain1" Acct-Session-Id = "0000033C" Called-Station-Id = "908274434" Calling-Station-Id = "933326800" NAS-Port = 17236233 NAS-Port-Type = Async Framed-Protocol = PPP Service-Type = Framed-User NAS-IP-Address = 10.1.0.102 Proxy-State = 0x313832 --- Walking the entire request list --- rad_recv: Access-Reject packet from host radius2:1645, id=0, length=85 Received Access-Reject packet from client radius2 port 1645 with invalid signature (err=2)! (Shared secret is incorrect.) Dropping packet without response. Finished request 0 But, with tcpdump, I only see garbage and radius2 receive garbage. And we have checked the secret key between radius1 and radius2 and it is right. Radius2 detect the access-request as bad password request (it receives grabage in the password) There is others local users in radius1 working fine, using teh same nas and shared secret. thanks. Luis Alan DeKok escribió:
Luis Galan wrote:
It seems that my nas is sending encrypted passwords
No. If the User-Password field is garbage in debugging mode, it's because the shared secret is wrong. Fix it.
but radius2 only accept clear text passwords. And my radius1 is proxying the request of the user@doamin1 with encrypted passwords to radius2.
What can I do to send the clear-text passwords to radius2?
Use the correct shared secret between the NAS and radius1.
Alan DeKok.
Hi,
The secret key between nas and radius1 is right.
yep. but look a little further down!
rad_recv: Access-Reject packet from host radius2:1645, id=0, length=85 Received Access-Reject packet from client radius2 port 1645 with invalid signature (err=2)! (Shared secret is incorrect.) Dropping packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^
which bit of that debug is not clear? the secret key shared between radius1 and radius2 is not set correctly. alan
But, with tcpdump, I only see garbage and radius2 receive garbage.
As you should. Radius packets are encrypted (that's what the secret is for).
Received Access-Reject packet from client radius2 port 1645 with invalid signature (err=2)! (Shared secret is incorrect.) Dropping packet without response. .. And we have checked the secret key between radius1 and radius2 and it is right. Radius2 detect the access-request as bad password request (it receives grabage in the password)
Well both servers tend to disagree. Type in again proxy secret on radius1 and client secret on radius2. Ivan Kalik Kalik Informatika ISP
Hi!
The secret key between nas and radius1 is right.
In debug mode I receive a clear password:
Sending Access-Request of id 0 to radius2 port 1645 User-Password = "estestA243" <...>
This does not mean you receive a cleartext password, it only means that the shared secret between the nas and radius1 is correct. The password is always encrypted on the network, using the shared secret (try it, put a tcpdump between the nas and radius1). In debugging mode, FreeRADIUS doesn't print the packet literally as it is on the network, but it tries to decrypt the password first.
rad_recv: Access-Reject packet from host radius2:1645, id=0, length=85 Received Access-Reject packet from client radius2 port 1645 with invalid signature (err=2)! (Shared secret is incorrect.) Dropping packet without response. Finished request 0
But, with tcpdump, I only see garbage and radius2 receive garbage.
As it should, because the password is _always_ encrypted on the wire. If radius2 gives a garbage password in its debug output, it means that it couldn't decode the password because the shared secrets between radius1 and radius2 are not configured to be the same. The error above, which you receive on radius1 makes this very clear, because radius1 can immediately see from the reply that the shared secret is incorrect (this is not a guess, radius1 can be very sure about this: it calculates a checksum over the reply and the shared secret, if this checksum is not the same as the one radius2 sent in the packet, the shared secret is wrong) The only other possibility is that one of your radius servers is so broken that it should never work with any other proxy or NAS because it doesn't calculate its checksums correctly. If both are FreeRADIUS, I really doubt that...
And we have checked the secret key between radius1 and radius2 and it is right. Radius2 detect the access-request as bad password request (it receives grabage in the password)
It's not. The _only_ way radius2 can see that the shared secret is correct in an Access-Request packet is if it is able to decode the password correctly. The password is garbage in the debug log, so radius2 couldn't decode the password, ergo: the shared secret is wrong.
There is others local users in radius1 working fine, using teh same nas and shared secret.
This only means that the shared secret between the NAS and radius1 is configured correctly, not that the one between radius1 and radius2 is correct. (Note, you didn't post any configuration files, but from what I could find here (don't have any proxy experience), the shared secret on radius2 is not the same as the one between the NAS and radius1. The shared secret between radius1 and radius2 should be configured in clients.conf on radius2 and in proxy.conf on radius1. Any comments on this from proxy-users are welcome...) Gtnx Marcel
Hello! great!! Fantastic!! it works!! Thank you very much for your help. You put me in the right direction and you help me to understand the whole thing. You should work as a teacher :-) I was really lost! Thanks Luis Marcel De Boer escribió:
Hi!
The secret key between nas and radius1 is right.
In debug mode I receive a clear password:
Sending Access-Request of id 0 to radius2 port 1645 User-Password = "estestA243" <...>
This does not mean you receive a cleartext password, it only means that the shared secret between the nas and radius1 is correct. The password is always encrypted on the network, using the shared secret (try it, put a tcpdump between the nas and radius1). In debugging mode, FreeRADIUS doesn't print the packet literally as it is on the network, but it tries to decrypt the password first.
rad_recv: Access-Reject packet from host radius2:1645, id=0, length=85 Received Access-Reject packet from client radius2 port 1645 with invalid signature (err=2)! (Shared secret is incorrect.) Dropping packet without response. Finished request 0
But, with tcpdump, I only see garbage and radius2 receive garbage.
As it should, because the password is _always_ encrypted on the wire. If radius2 gives a garbage password in its debug output, it means that it couldn't decode the password because the shared secrets between radius1 and radius2 are not configured to be the same. The error above, which you receive on radius1 makes this very clear, because radius1 can immediately see from the reply that the shared secret is incorrect (this is not a guess, radius1 can be very sure about this: it calculates a checksum over the reply and the shared secret, if this checksum is not the same as the one radius2 sent in the packet, the shared secret is wrong)
The only other possibility is that one of your radius servers is so broken that it should never work with any other proxy or NAS because it doesn't calculate its checksums correctly. If both are FreeRADIUS, I really doubt that...
And we have checked the secret key between radius1 and radius2 and it is right. Radius2 detect the access-request as bad password request (it receives grabage in the password)
It's not. The _only_ way radius2 can see that the shared secret is correct in an Access-Request packet is if it is able to decode the password correctly. The password is garbage in the debug log, so radius2 couldn't decode the password, ergo: the shared secret is wrong.
There is others local users in radius1 working fine, using teh same nas and shared secret.
This only means that the shared secret between the NAS and radius1 is configured correctly, not that the one between radius1 and radius2 is correct. (Note, you didn't post any configuration files, but from what I could find here (don't have any proxy experience), the shared secret on radius2 is not the same as the one between the NAS and radius1. The shared secret between radius1 and radius2 should be configured in clients.conf on radius2 and in proxy.conf on radius1. Any comments on this from proxy-users are welcome...)
Gtnx Marcel
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Luis Galan -
Marcel De Boer -
tnt＠kalik.co.yu