EAP-TLS constant disconnects
Hi all! We've been using freeradius 2.1.12 with EAP-TLS authentication. The problem we experience is constant disconnects of the clients. After an some time (it seems like the intervals are random) of usage the connection drops. I don't have a debug output, since the server is in production allready and because of the valid traffic it's hard to efficiently debug it that way. A similar problem was allready reported some years ago (without an answer - at least not in that thread): http://bit.ly/10o9xkG Any ideas (what may the cause be, how to debug it efficiently etc.) are welcome! Regards!
On 11/23/2012 08:03 AM, Uros Kolar wrote:
Hi all!
We've been using freeradius 2.1.12 with EAP-TLS authentication. The problem we experience is constant disconnects of the clients. After an some time (it seems like the intervals are random) of usage the connection drops. I don't have a debug output, since the server is in production allready and because of the valid traffic it's hard to efficiently debug it that way.
A similar problem was allready reported some years ago (without an answer - at least not in that thread): http://bit.ly/10o9xkG
The issue described in that post is symptomatic of wireless problems - interference, low signal, etc. - not RADIUS problems. The "EAP Identity" retries he mentions are on the *wireless* side i.e. the AP asking the client to start a re-auth. You problem also sounds like wireless to me; FreeRADIUS either: * receives auth requests and sends an accept * receives auth requests and sends a reject * receives auth requests that the client never completes It doesn't somehow magically disconnect the client (well, unless you're using the CoA functionality and you *ask* it to). I would suggest starting the debugging at the wireless side. Wait for a report of a disconnect, then search your logs. You could also start a rolling tcpdump on the RADIUS server of all auth traffic, and then search it for an auth request - I bet you don't see one.
Phil, thank you for your reply! I've tried to debug as you suggest. I run wireshark on the remote side + tcpdump on the server side. The results are really interesting and not expected. As the client is disconnected, it sends an auth request to the server. Server gets the request and after a successful authentication it sends back Access-Accept. Client gets this message. However, immediately after a successful authantication, it starts with the authentication process again and it loops like that. In the test time Access-Accept was granted 7 times, but client was still without connection and retrying. For tests I used a linux client on the remote side. After running dhclient for a couple of times the connection is usualy restored, sometimes it even takes to take down the interface and bring it up again to restore the connection. As of my understanding this does not prove a weak wifi as a reason for failure, as it does not prove that it is not the cause for trouble. Additionaly, there seems te be something else, besides wireless, which I can't explain, so feel free to commend and sugest! Regards! On Fri, Nov 23, 2012 at 10:54 AM, Phil Mayers <p.mayers@imperial.ac.uk>wrote:
On 11/23/2012 08:03 AM, Uros Kolar wrote:
Hi all!
We've been using freeradius 2.1.12 with EAP-TLS authentication. The problem we experience is constant disconnects of the clients. After an some time (it seems like the intervals are random) of usage the connection drops. I don't have a debug output, since the server is in production allready and because of the valid traffic it's hard to efficiently debug it that way.
A similar problem was allready reported some years ago (without an answer - at least not in that thread): http://bit.ly/10o9xkG
The issue described in that post is symptomatic of wireless problems - interference, low signal, etc. - not RADIUS problems. The "EAP Identity" retries he mentions are on the *wireless* side i.e. the AP asking the client to start a re-auth.
You problem also sounds like wireless to me; FreeRADIUS either:
* receives auth requests and sends an accept * receives auth requests and sends a reject * receives auth requests that the client never completes
It doesn't somehow magically disconnect the client (well, unless you're using the CoA functionality and you *ask* it to).
I would suggest starting the debugging at the wireless side. Wait for a report of a disconnect, then search your logs.
You could also start a rolling tcpdump on the RADIUS server of all auth traffic, and then search it for an auth request - I bet you don't see one. - List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
Hi, I've interrupted the test after the described process was allready going on for 2 min. Don't know exactly what timers you mean. I checked time setings on servers. NAS has GMT+1 and FreeRADIUS server UTC. Will change NAS time to GMT. Please correct me if that's not what you meant. On Mon, Nov 26, 2012 at 10:29 AM, alan buxey <A.L.M.Buxey@lboro.ac.uk>wrote:
Hi,
The results are really interesting and not expected.
how long does the process take? what are your NAS timers and FreeRADIUS timers?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I've interrupted the test after the described process was allready going on for 2 min.
Don't know exactly what timers you mean. I checked time setings on servers. NAS has GMT+1 and FreeRADIUS server UTC. Will change NAS time to GMT. Please correct me if that's not what you meant.
I mean the number of seconds you have for eg RADIUS authentication, failure time, cleapup delay etc. also, if your clients and RADIUS server dont have correct time synchonisation then things will go wrong. alan
Thanks for the additional info on timers. Here are the values, hope i didn't leave out something. Basically we left them set to default. timer expire for eap is 60 cleanup delay is se to 5 reject delay to 1 max request time is 30 uros On Mon, Nov 26, 2012 at 12:14 PM, alan buxey <A.L.M.Buxey@lboro.ac.uk>wrote:
Hi,
I've interrupted the test after the described process was allready going on for 2 min.
Don't know exactly what timers you mean. I checked time setings on servers. NAS has GMT+1 and FreeRADIUS server UTC. Will change NAS time to GMT. Please correct me if that's not what you meant.
I mean the number of seconds you have for eg RADIUS authentication, failure time, cleapup delay etc. also, if your clients and RADIUS server dont have correct time synchonisation then things will go wrong.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
alan buxey -
Phil Mayers -
Uros Kolar