Radius Proxying and IP injection
Hi all We are proxying a realm for a customer that takes ADSL connections from us. Our ADSL connections terminate on a Cisco 7204 over an L2TP tunnel. The proxying seems to be working fine as all requests for the realm are sent to the customers radius server. And our log files show that the authentication was "OK". However the users that are authenticating are being dropped offline as soon as they authenticate. The account logs show the reason as being "User-Request" although the user hasn't requested a disconnect, in fact they aren't connected long enough to do so. The customer is also sending a framed IP address for each user that connects via the users radius users file entry. I'm wondering if this has something to do with the problem, although I can't really see why. The customer is issuing IP addresses from our own RIPE allocation that the Cisco knows about and we announce via BGP to upstreams. I'm trying to get some radius and cisco debugging for these users, but unfortunately everyone has buggered off home and most of the users are offices. So I guess I'm just wondering if there are any gotchas with radius proxying and injecting IP addresses that anyone may have come across. Or does anyone have any ideas what I should be looking for to help fix the problem? Thanks In Advance John
Just got some radius debugging here. ####################### rad_recv: Access-Request packet from host 212.248.232.242:1645, id=116, length=85 Framed-Protocol = PPP User-Name = "bob.ken@maxsurf" User-Password = "accutronic2" NAS-Port-Type = Virtual NAS-Port = 907 Service-Type = Framed-User NAS-IP-Address = 212.248.232.242 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 465 modcall[authorize]: module "preprocess" returns ok for request 465 modcall[authorize]: module "chap" returns noop for request 465 modcall[authorize]: module "mschap" returns noop for request 465 rlm_realm: Looking up realm "maxsurf" for User-Name = "bob.ken@maxsurf" rlm_realm: Found realm "maxsurf" rlm_realm: Proxying request from user bob.ken to realm maxsurf rlm_realm: Adding Realm = "maxsurf" rlm_realm: Preparing to proxy authentication request to realm "maxsurf" modcall[authorize]: module "suffix" returns updated for request 465 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 465 modcall[authorize]: module "files" returns notfound for request 465 modcall: group authorize returns updated for request 465 Processing the pre-proxy section of radiusd.conf modcall: entering group pre-proxy for request 465 radius_xlat: '/var/log/radius/radacct/212.248.232.242/pre-proxy-detail-20060612' rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d expands to /var/log/radius/radacct/212.248.232.242/pre-proxy-detail-20060612 modcall[pre-proxy]: module "pre_proxy_log" returns ok for request 465 modcall: group pre-proxy returns ok for request 465 Sending Access-Request of id 0 to 62.41.128.19:1645 Framed-Protocol = PPP User-Name = "bob.ken@maxsurf" User-Password = "accutronic2" NAS-Port-Type = Virtual NAS-Port = 907 Service-Type = Framed-User NAS-IP-Address = 212.248.232.242 Proxy-State = 0x313136 --- Walking the entire request list --- Waking up in 4 seconds... rad_recv: Access-Accept packet from host 62.41.128.19:1645, id=0, length=111 Class = 0x5342522d434c20444e3d22313433373830222041543d22323030222055533d22222053493d 2235363935303638352200 Session-Timeout = 7200 Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-Protocol = PPP Idle-Timeout = 600 Service-Type = Framed-User Proxy-State = 0x313136 Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 465 radius_xlat: '/var/log/radius/radacct/212.248.232.242/post-proxy-detail-20060612' rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/post-proxy-detail-%Y%m%d expands to /var/log/radius/radacct/212.248.232.242/post-proxy-detail-20060612 modcall[post-proxy]: module "post_proxy_log" returns ok for request 465 modcall: group post-proxy returns ok for request 465 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 465 modcall[authorize]: module "preprocess" returns ok for request 465 modcall[authorize]: module "chap" returns noop for request 465 modcall[authorize]: module "mschap" returns noop for request 465 rlm_realm: Proxy reply, or no User-Name. Ignoring. modcall[authorize]: module "suffix" returns noop for request 465 modcall[authorize]: module "eap" returns noop for request 465 modcall[authorize]: module "files" returns notfound for request 465 modcall: group authorize returns ok for request 465 rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [bob.ken@maxsurf/accutronic2] (from client l2tp-tunnel port 907) Sending Access-Accept of id 116 to 212.248.232.242:1645 Class = 0x5342522d434c20444e3d22313433373830222041543d22323030222055533d22222053493d 2235363935303638352200 Session-Timeout = 7200 Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-Protocol = PPP Idle-Timeout = 600 Service-Type = Framed-User Finished request 465 Going to the next request ############################## The strange thing is the Framed-IP-Address, it isn't showing the correct IP address that the user has assigned in our customer radius users file. If I run radtest from the command line against the customers radius server it returns: ################### Sending Access-Request of id 3 to 62.41.128.19:1645 User-Name = "bob.ken@maxsurf" User-Password = "accutronic2" NAS-IP-Address = cw2.eurisp.net NAS-Port = 1645 rad_recv: Access-Accept packet from host 62.41.128.19:1645, id=3, length=106 Class = 0x5342522d434c20444e3d22313433373830222041543d22323030222055533d22222053493d 2235363935313230372200 Session-Timeout = 0 Framed-IP-Address = 85.92.190.82 Framed-IP-Netmask = 255.255.255.255 Acct-Interim-Interval = 7200 Framed-Protocol = PPP Service-Type = Framed-User ####################### With the correct IP address. Any ideas why it's doing this? Thanks John _____ From: freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius.org [mailto:freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius .org] On Behalf Of John Williams Sent: 12 June 2006 20:58 To: freeradius-users@lists.freeradius.org Subject: Radius Proxying and IP injection Hi all We are proxying a realm for a customer that takes ADSL connections from us. Our ADSL connections terminate on a Cisco 7204 over an L2TP tunnel. The proxying seems to be working fine as all requests for the realm are sent to the customers radius server. And our log files show that the authentication was "OK". However the users that are authenticating are being dropped offline as soon as they authenticate. The account logs show the reason as being "User-Request" although the user hasn't requested a disconnect, in fact they aren't connected long enough to do so. The customer is also sending a framed IP address for each user that connects via the users radius users file entry. I'm wondering if this has something to do with the problem, although I can't really see why. The customer is issuing IP addresses from our own RIPE allocation that the Cisco knows about and we announce via BGP to upstreams. I'm trying to get some radius and cisco debugging for these users, but unfortunately everyone has buggered off home and most of the users are offices. So I guess I'm just wondering if there are any gotchas with radius proxying and injecting IP addresses that anyone may have come across. Or does anyone have any ideas what I should be looking for to help fix the problem? Thanks In Advance John
##############################
The strange thing is the Framed-IP-Address, it isn’t showing the correct IP address that the user has assigned in our customer radius users file.
If I run radtest from the command line against the customers radius server it returns:
If you get different results from your customers radius server when the requests originate from your nas or when the requests originate from your command line then......
With the correct IP address.
Any ideas why it’s doing this?
This is a misconfiguration of your customers radius server, possibly based upon incorrect information from you.
The proxying seems to be working fine as all requests for the realm are sent to the customers radius server.
And our log files show that the authentication was “OK”.
However the users that are authenticating are being dropped offline as soon as they authenticate.
Let me guess....you dont have any ip pools available on your nas server. So without a specified IP, the user cant/wont stay connected.
The proxying seems to be working fine as all requests for the realm are sent to the customers radius server.
And our log files show that the authentication was "OK".
However the users that are authenticating are being dropped offline as soon as they authenticate.
Let me guess....you dont have any ip pools available on your nas server. So without a specified IP, the user cant/wont stay connected.
No we don't, well certainly not for ADSL customers only dialup. But if the customer is injecting the IP's from radius we shouldn't need to. I suspect it maybe the attrs file as I describe in my last email to the group. John
John Williams wrote:
However the users that are authenticating are being dropped offline as soon as they authenticate.
The account logs show the reason as being “User-Request” although the user hasn’t requested a disconnect, in fact they aren’t connected long enough to do so.
The customer is also sending a framed IP address for each user that connects via the users radius users file entry.
Your cisco doesnt like certain attributes in the reply and closes the connections. Likely as not the attributes it doesnt like is the ones in relation to what your customer is trying to assign. debugs will show you exactly which one, but beware. debug radius debug aaa authentication debug aaa authorization debug aaa per-user debug aaa subsys debug ppp negotiation debug vtemplate ev debug vtemplate cloning debug vprofile I would also run your server in debugging mode to see exactly which attributes are being sent to your cisco nas for those users.
Joe I don't think our customer is sending any attributes that we don't send to the Cisco ourselves. However I'll get him to send me a users entry and see if that's the case before I turn all that debug on :) If you see my previous email you'll see the radius debug I sent when one the users tried to log on. For some reason the IP address being assigned is 255.255.255.254 and not the one the customer is sending. Looking through the radius files I saw this in the attrs file: ################## # The rest of this file contains the DEFAULT entry. # DEFAULT matches with all realm names. # DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, Framed-IP-Address == 255.255.255.254, Framed-IP-Netmask == 255.255.255.255, Framed-Protocol == PPP, Framed-Protocol == SLIP, Framed-Compression == Van-Jacobson-TCP-IP, Framed-MTU >= 576, Framed-Filter-ID =* ANY, Reply-Message =* ANY, Proxy-State =* ANY, Session-Timeout <= 28800, Idle-Timeout <= 600, ######### I see the default IP assigned is 255.255.255.254 which is the same as what the radius debug shows. Would this be the cause maybe? I've now commented it out and reload radius, so now I have to wait for a user to try and connect again. John -----Original Message----- From: freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius.org [mailto:freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius .org] On Behalf Of Joe Maimon Sent: 12 June 2006 21:10 To: FreeRadius users mailing list Subject: Re: Radius Proxying and IP injection John Williams wrote:
However the users that are authenticating are being dropped offline as soon as they authenticate.
The account logs show the reason as being "User-Request" although the user hasn't requested a disconnect, in fact they aren't connected long enough to do so.
The customer is also sending a framed IP address for each user that connects via the users radius users file entry.
Your cisco doesnt like certain attributes in the reply and closes the connections. Likely as not the attributes it doesnt like is the ones in relation to what your customer is trying to assign. debugs will show you exactly which one, but beware. debug radius debug aaa authentication debug aaa authorization debug aaa per-user debug aaa subsys debug ppp negotiation debug vtemplate ev debug vtemplate cloning debug vprofile I would also run your server in debugging mode to see exactly which attributes are being sent to your cisco nas for those users. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
John Williams wrote:
Looking through the radius files I saw this in the attrs file:
################## # The rest of this file contains the DEFAULT entry. # DEFAULT matches with all realm names. #
DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, Framed-IP-Address == 255.255.255.254, Framed-IP-Netmask == 255.255.255.255,
If you are using the attrs module, then this will prevent your customers attributes from being used. In your earlier email you were unclear whether you performed the radtest directly against your customers radius server or against your own. I assumed the latter. Good luck.
Is it possible to get the customers radius server to specify the IP address pool to use from the Cisco to assign an IP address? I found this attribute: Ascend-Assign-IP-Global-Pool Can our customer use: Ascend-Assign-IP-Global-Pool = IP-POOL In his radius entries to specify this pool from the Cisco? John -----Original Message----- From: freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius.org [mailto:freeradius-users-bounces+john.williams=eurisp.co.uk@lists.freeradius .org] On Behalf Of Joe Maimon Sent: 12 June 2006 22:07 To: FreeRadius users mailing list Subject: Re: Radius Proxying and IP injection John Williams wrote:
Looking through the radius files I saw this in the attrs file:
################## # The rest of this file contains the DEFAULT entry. # DEFAULT matches with all realm names. #
DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, Framed-IP-Address == 255.255.255.254, Framed-IP-Netmask == 255.255.255.255,
If you are using the attrs module, then this will prevent your customers attributes from being used. In your earlier email you were unclear whether you performed the radtest directly against your customers radius server or against your own. I assumed the latter. Good luck. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
John Williams wrote:
Is it possible to get the customers radius server to specify the IP address pool to use from the Cisco to assign an IP address?
I found this attribute:
Ascend-Assign-IP-Global-Pool
Can our customer use:
Ascend-Assign-IP-Global-Pool = IP-POOL
In his radius entries to specify this pool from the Cisco?
John
Cisco-Avpair += "ip:addr-pool=poolname"
participants (2)
-
Joe Maimon -
John Williams