hi all, I've searched the list for clues but havent' found a resolution for the following: 1. On a testing network, with seven identically configured routers, four connect and three dont. They are all the same make / model. 2. They're all using different usernames and passwords, and the NAS is reporting that RADIUS is rejecting three of them but the other four are OK. 3. The box _is_ multihomed; saw the FAQ and i've set bind and port to the one address I want and also have recompiled with --with-udpfromto 4. I'm seeing fewer errors than I was, but the sites still aren't connecting. 5. When I connect from another site using ntradping to the same FreeRADIUS all seven usernames / passwords work and I get Access-Accept. 6. At the not workign sites, the routers (Draytek) report that the ADSL is in sync, sending an Access-Request, then nine seconds later they drop the PPP session. auth-detail reports the Access-Request properly AFAIK. reply-detail reports the Access-Accept properly. In the radius.log I get Wed Aug 8 18:17:35 2007 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'Redback', nas 'a.b.c.d'] Wed Aug 8 18:17:36 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:36 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:36 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:36 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:41 2007 : Auth: Login OK: [Site14@provider.net/<CHAP-Password>] (from client NAS-ocl port 1114112) Wed Aug 8 18:17:43 2007 : Auth: Login OK: [Site11@provider.net/<CHAP-Password>] (from client NAS-ocl port 1114112) Wed Aug 8 18:17:44 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:44 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:44 2007 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'Redback', nas 'a.b.c.d'] Wed Aug 8 18:17:45 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:45 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:45 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:45 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:17:50 2007 : Auth: Login OK: [Site14@provider.net/<CHAP-Password>] (from client NAS-ocl port 1114112) Wed Aug 8 18:17:50 2007 : Auth: Login incorrect: [Redback/*********] (from client NAS-ocl port 0) Wed Aug 8 18:17:50 2007 : Info: rlm_sql (sql): No matching entry in the database for request from user [redback] Wed Aug 8 18:17:50 2007 : Auth: Login incorrect: [redback/*********] (from client NAS-ocl port 0) Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'Site11@provider.net', nas 'a.b.c.d'] Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_radutmp: Logout for NAS NAS-ocl port 1114112, but no Login record Wed Aug 8 18:18:02 2007 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'Site14@provider.net', nas 'a.b.c.d'] In the detail log I get Wed Aug 8 17:34:02 2007 User-Name = "REMOVED" Acct-Status-Type = Stop Acct-Session-Id = "FF10FFFF584ECD3D-46B9FE2D" Service-Type = Framed-User Framed-Protocol = PPP NAS-Identifier = "t6-se1" NAS-Port = 1114112 NAS-Port-Type = Virtual NAS-Port-Id = "L2TP LNS 5164349" Medium-Type = DSL Connect-Info = "155520000/155520000" Platform-Type = SmartEdge-800 OS-Version = "4.0.5.4p1" Acct-Authentic = RADIUS Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IP Tunnel-Server-Endpoint:0 = "192.168.XXX.YYY" Tunnel-Client-Endpoint:0 = "192.168.XXX.ZZZ" Tunnel-Max-Sessions = 2300 Tunnel-Max-Tunnels = 32767 Tunnel-Function = LNS-Only Acct-Session-Time = 0 Acct-Terminate-Cause = User-Request Session-Error-Code = 140 Session-Error-Msg = "Received PPP Terminate Request" Acct-Input-Packets = 0 Acct-Output-Packets = 0 Acct-Input-Octets = 0 Acct-Output-Octets = 0 Acct-Input-Gigawords = 0 Acct-Output-Gigawords = 0 Acct-Input-Packets-64 = 0x0000000000000000 Acct-Output-Packets-64 = 0x0000000000000000 Acct-Input-Octets-64 = 0x0000000000000000 Acct-Output-Octets-64 = 0x0000000000000000 Acct-Mcast-In-Packets = 0 Acct-Mcast-Out-Packets = 0 Acct-Mcast-In-Octets = 0 Acct-Mcast-Out-Octets = 0 Acct-Mcast-In-Packets-64 = 0x0000000000000000 Acct-Mcast-Out-Packets-64 = 0x0000000000000000 Acct-Mcast-In-Octets-64 = 0x0000000000000000 Acct-Mcast-Out-Octets-64 = 0x0000000000000000 Event-Timestamp = "Aug 8 2007 18:32:50 BST" NAS-IP-Address = a.b.c.d Client-IP-Address = a.b.c.d Acct-Unique-Session-Id = "f727889885172d56" Timestamp = 1186590842 I can't see any differences between the usernames that work and those that dont. FR is using MySQL if that makes a difference. I'm not that concerned about the redback/***** failures as they are keepalives from the NAS, which is 3rd party (I have no access). Thanks in advance for any pointers anyone can give, and very sorry if my searching of the list missed a solution posted previously!! Andy
Andy Billington wrote:
auth-detail reports the Access-Request properly AFAIK. reply-detail reports the Access-Accept properly.
In the radius.log I get
As opposed to debug mode, which is suggested in the README, FAQ, INSTALL, etc.?
In the detail log I get
Accounting packets. NOT authentication packets. You are aware that they are different?
Thanks in advance for any pointers anyone can give, and very sorry if my searching of the list missed a solution posted previously!!
If the server sends an Access-Accept and the NAS doesn't see it, it's likely a network / routing problem. Alan DeKok.
thanks for your quick response! debug didnt seem a likely source of info given that this is a server that has been functionig without incident for six months and no changes have been made to its config. I have been looking at network / routing issues but couldnt figure out why some sites would work and not others, if it was network / routing? Surely all would work, or none, if it was that ie. the NAS woudl reject all transactions not just some of them? Not that interested in accounting packet problems except as an explanation of why sessions are dropping _in some cases_ but not in all; the authentication traffic seems to be fine. Is there any network / routing related reason why a NAS would accept some FR responses but not others? Thanks again Andy On 08/08/2007, Alan DeKok <aland@deployingradius.com> wrote:
Andy Billington wrote:
auth-detail reports the Access-Request properly AFAIK. reply-detail reports the Access-Accept properly.
In the radius.log I get
As opposed to debug mode, which is suggested in the README, FAQ, INSTALL, etc.?
In the detail log I get
Accounting packets. NOT authentication packets.
You are aware that they are different?
Thanks in advance for any pointers anyone can give, and very sorry if my searching of the list missed a solution posted previously!!
If the server sends an Access-Accept and the NAS doesn't see it, it's likely a network / routing problem.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Andy Billington wrote:
debug didnt seem a likely source of info given that this is a server that has been functionig without incident for six months and no changes have been made to its config. I have been looking at network / routing issues but couldnt figure out why some sites would work and not others, if it was network / routing?
If the RADIUS server sends packets, it's done with RADIUS. After that, check that the packets make it onto the local network, to the next router, etc.
Surely all would work, or none, if it was that ie. the NAS woudl reject all transactions not just some of them? Not that interested in accounting packet problems except as an explanation of why sessions are dropping _in some cases_ but not in all; the authentication traffic seems to be fine.
If all of the authentication traffic is OK, and accounting doesn't work, then the accounting shared secrets are likely wrong.
Is there any network / routing related reason why a NAS would accept some FR responses but not others?
If a NAS accepts one Access-Accept from a server, it should accept them all. If it accepts on Accounting-Response from a server, it should accept them all. Alan DeKok.
Thanks Alan - that last point was what I wanted to confirm before going to the NAS owner to request they start looking. As you've said, teh RADIUS server sends out packets and they hit the network - if routing / network was the cause if this, none of the auth responses would get through. I'm trying disabling accounting for the moment, using Listen, to squash accounting related error messages. Cant enable debug for another two hours when the various test sites will finally close for the day and I can restart without impacting the sites that do work. The NAS and RADIUS servers are both doing auth and accounting, same IPs and same shared secrets (although different ports obviously). Again, if auth works for some sites - even if not for others - the shared secret must be correct, no? Sorry for asking what probably seem like basic questions but want to be sure of myself :-) Andy On 08/08/2007, Alan DeKok <aland@deployingradius.com> wrote:
Andy Billington wrote:
debug didnt seem a likely source of info given that this is a server that has been functionig without incident for six months and no changes have been made to its config. I have been looking at network / routing issues but couldnt figure out why some sites would work and not others, if it was network / routing?
If the RADIUS server sends packets, it's done with RADIUS. After that, check that the packets make it onto the local network, to the next router, etc.
Surely all would work, or none, if it was that ie. the NAS woudl reject all transactions not just some of them? Not that interested in accounting packet problems except as an explanation of why sessions are dropping _in some cases_ but not in all; the authentication traffic seems to be fine.
If all of the authentication traffic is OK, and accounting doesn't work, then the accounting shared secrets are likely wrong.
Is there any network / routing related reason why a NAS would accept some FR responses but not others?
If a NAS accepts one Access-Accept from a server, it should accept them all. If it accepts on Accounting-Response from a server, it should accept them all.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The best way to verify this is to look at the debug (radiusd -X) for the requests coming from the sites that have a problem. Ivan Kalik Kalik Informatika ISP Dana 8/8/2007, "Andy Billington" <billington.andy@googlemail.com> piše:
Thanks Alan - that last point was what I wanted to confirm before going to the NAS owner to request they start looking. As you've said, teh RADIUS server sends out packets and they hit the network - if routing / network was the cause if this, none of the auth responses would get through. I'm trying disabling accounting for the moment, using Listen, to squash accounting related error messages. Cant enable debug for another two hours when the various test sites will finally close for the day and I can restart without impacting the sites that do work.
The NAS and RADIUS servers are both doing auth and accounting, same IPs and same shared secrets (although different ports obviously). Again, if auth works for some sites - even if not for others - the shared secret must be correct, no?
Sorry for asking what probably seem like basic questions but want to be sure of myself :-)
Andy
On 08/08/2007, Alan DeKok <aland@deployingradius.com> wrote:
Andy Billington wrote:
debug didnt seem a likely source of info given that this is a server that has been functionig without incident for six months and no changes have been made to its config. I have been looking at network / routing issues but couldnt figure out why some sites would work and not others, if it was network / routing?
If the RADIUS server sends packets, it's done with RADIUS. After that, check that the packets make it onto the local network, to the next router, etc.
Surely all would work, or none, if it was that ie. the NAS woudl reject all transactions not just some of them? Not that interested in accounting packet problems except as an explanation of why sessions are dropping _in some cases_ but not in all; the authentication traffic seems to be fine.
If all of the authentication traffic is OK, and accounting doesn't work, then the accounting shared secrets are likely wrong.
Is there any network / routing related reason why a NAS would accept some FR responses but not others?
If a NAS accepts one Access-Accept from a server, it should accept them all. If it accepts on Accounting-Response from a server, it should accept them all.
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
hi Ivan, Just been able to restart witout affecting working sites, have started using -X and am seeing lots of info; for a start its binding to correct IP (which counters the multi-home issue i was concerned about). The sites that have probs are all reporting RADIUS ok, my query / concern is that why do some work and not others? Surely if it was routing / network stuff, none would work or all would work; unless the NAS is not behaving? Was thinking about setting up another FR instance, separate IP and with just pure text (users) info but am not sure - what concerns me is seeing a few mails that have same symptoms (connect starts, then restarts after 10s) from other users but they dont seem to have got working. Have I upgraded FR (apt-get etc) and broken my config :( which I'm sure isnt true. Woudl setting up second FR be overkill, given stuff is working for other sites? Andy On 08/08/2007, tnt@kalik.co.yu <tnt@kalik.co.yu> wrote:
The best way to verify this is to look at the debug (radiusd -X) for the requests coming from the sites that have a problem.
Ivan Kalik Kalik Informatika ISP
Dana 8/8/2007, "Andy Billington" <billington.andy@googlemail.com> piše:
Thanks Alan - that last point was what I wanted to confirm before going to the NAS owner to request they start looking. As you've said, teh RADIUS server sends out packets and they hit the network - if routing / network was the cause if this, none of the auth responses would get through. I'm trying disabling accounting for the moment, using Listen, to squash accounting related error messages. Cant enable debug for another two hours when the various test sites will finally close for the day and I can restart without impacting the sites that do work.
The NAS and RADIUS servers are both doing auth and accounting, same IPs and same shared secrets (although different ports obviously). Again, if auth works for some sites - even if not for others - the shared secret must be correct, no?
Sorry for asking what probably seem like basic questions but want to be sure of myself :-)
Andy
On 08/08/2007, Alan DeKok <aland@deployingradius.com> wrote:
Andy Billington wrote:
debug didnt seem a likely source of info given that this is a server that has been functionig without incident for six months and no changes have been made to its config. I have been looking at network / routing issues but couldnt figure out why some sites would work and not others, if it was network / routing?
If the RADIUS server sends packets, it's done with RADIUS. After that, check that the packets make it onto the local network, to the next router, etc.
Surely all would work, or none, if it was that ie. the NAS woudl reject all transactions not just some of them? Not that interested in accounting packet problems except as an explanation of why sessions are dropping _in some cases_ but not in all; the authentication traffic seems to be fine.
If all of the authentication traffic is OK, and accounting doesn't work, then the accounting shared secrets are likely wrong.
Is there any network / routing related reason why a NAS would accept some FR responses but not others?
If a NAS accepts one Access-Accept from a server, it should accept them all. If it accepts on Accounting-Response from a server, it should accept them all.
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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Andy Billington wrote:
Was thinking about setting up another FR instance, separate IP and with just pure text (users) info but am not sure - what concerns me is seeing a few mails that have same symptoms (connect starts, then restarts after 10s)
Do those users get connected at *all*? If they do, then the problem is the NAS. It's being told to connect them, it does, and then 10s later, it disconnects them. *Please* ensure that the problem is something other than RADIUS before poking your FreeRADIUS configuration. If the NAS receives the Access-Accept and lets the user on, DON'T touch your RADIUS configuration. Buy a NAS that works. Alan DeKok.
Thankyou Alan! I don't want to shout at the NAS owner (we rely on them for customer connections on a private DSL network and the other sites are fine!) without backup / confidence that I'm not making mistakes. The users connect, both the logs earlier and now the debug output show Accept messages going out to the NAS correctly, and as i said most of our user community connects without issue. Which lead me to say it's not RADIUS, but I was given a "it's your RADIUS" response by our provider. I guess my first step tomorrow is to make sure the NAS receives the Access-Accept for all sites and then give it to them to figure out why some are being marked as Reject by the NAS and some are OK and do as i said about "new" user setups. As I said previously, Thankyou very much for your assistance - the accounting packet issue i can sort given time (and offline) and hopefully i wont need to trouble anyone further. All ideas gratefully recieved though! Andy On 09/08/2007, Alan DeKok <aland@deployingradius.com> wrote:
Andy Billington wrote:
Was thinking about setting up another FR instance, separate IP and with just pure text (users) info but am not sure - what concerns me is seeing a few mails that have same symptoms (connect starts, then restarts after 10s)
Do those users get connected at *all*? If they do, then the problem is the NAS. It's being told to connect them, it does, and then 10s later, it disconnects them.
*Please* ensure that the problem is something other than RADIUS before poking your FreeRADIUS configuration. If the NAS receives the Access-Accept and lets the user on, DON'T touch your RADIUS configuration. Buy a NAS that works.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Andy Billington -
tnt＠kalik.co.yu