Now if I have only 1 to 4 user login then this hnguyen user will able to login. I similated it by comments out some users in the users file. This how I was able to determine the system only allow 5 user to sign in.
As you can see in the log file these information did not pass to the radius when it is over five user or not working Tunnel-Server-Endpoint:0 = "12.12.126.5" Tunnel-Client-Endpoint:0 = "12.12.126.6" I am thinking the problem is with the NAS devices (7204). However, I can figure out what. Thanks again for look into my issues. **********This one doesn't work************ rad_recv: Access-Request packet from host 172.17.17.1:1645, id=202, length=95 NAS-IP-Address = 172.17.17.1 NAS-Port = 7 NAS-Port-Type = ISDN User-Name = "[EMAIL PROTECTED]" CHAP-Password = 0xc892e3c15917124c44f86fdbda34f524e7 Service-Type = Framed-User Framed-Protocol = PPP Processing the authorize section of radiusd.conf modcall: entering group authorize for request 18 modcall[authorize]: module "preprocess" returns ok for request 18 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 18 modcall[authorize]: module "mschap" returns noop for request 18 rlm_realm: Looking up realm "campbell.com" for User-Name = "[EMAIL PROTECTED]" rlm_realm: Found realm "campbell.com" rlm_realm: Adding Stripped-User-Name = "hnguyen" rlm_realm: Proxying request from user hnguyen to realm campbell.com rlm_realm: Adding Realm = "campbell.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 18 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 18 users: Matched entry hnguyen at line 166 modcall[authorize]: module "files" returns ok for request 18 modcall: group authorize returns ok for request 18 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied CHAP-Password matches local User-Password Sending Access-Accept of id 202 to 172.17.17.1:1645 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 192.168.172.15 Framed-IP-Netmask = 255.255.255.128 Framed-MTU = 1492 Finished request 18 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 18 ID 202 with timestamp 44f8a72e Nothing to do. Sleeping until we see a request. ******************************************************** **** THis one is working *********************** rad_recv: Accounting-Request packet from host 172.17.17.1:1646, id=199, length=232 NAS-IP-Address = 172.17.17.1 NAS-Port = 6 NAS-Port-Type = ISDN User-Name = "[EMAIL PROTECTED]" Acct-Status-Type = Stop Acct-Authentic = RADIUS Service-Type = Framed-User Acct-Session-Id = "00000CD8" Framed-Protocol = PPP Tunnel-Server-Endpoint:0 = "12.12.126.5" Tunnel-Client-Endpoint:0 = "12.12.126.6" Tunnel-Type:0 = L2TP Tunnel-Client-Auth-Id:0 = "CAMPBELL" Tunnel-Server-Auth-Id:0 = "sfldse26rr.mi.AADS" Acct-Tunnel-Connection = "13441125" Framed-IP-Address = 192.168.172.12 Acct-Terminate-Cause = Admin-Reset Acct-Input-Octets = 281672 Acct-Output-Octets = 266074 Acct-Input-Packets = 4390 Acct-Output-Packets = 4154 Acct-Session-Time = 1967 Acct-Delay-Time = 0 Processing the preacct section of radiusd.conf modcall: entering group preacct for request 15 modcall[preacct]: module "preprocess" returns noop for request 15 rlm_acct_unique: Hashing 'NAS-Port = 6,Client-IP-Address = 172.17.17.1,NAS-IP-Address = 172.17.17.1,Acct-Session-Id = "00000CD8",User-Name = "[EMAIL PROTECTED]"' rlm_acct_unique: Acct-Unique-Session-ID = "eb18422da9f1337f". modcall[preacct]: module "acct_unique" returns ok for request 15 rlm_realm: Looking up realm "campbell.com" for User-Name = "[EMAIL PROTECTED]" rlm_realm: Found realm "campbell.com" rlm_realm: Adding Stripped-User-Name = "knguyen" rlm_realm: Proxying request from user knguyen to realm campbell.com rlm_realm: Adding Realm = "campbell.com" rlm_realm: Accounting realm is LOCAL. modcall[preacct]: module "suffix" returns noop for request 15 modcall[preacct]: module "files" returns noop for request 15 modcall: group preacct returns ok for request 15 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 15 radius_xlat: '/usr/local/var/log/radius/radacct/172.17.17.1/ detail-20060901' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP- Address}/detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/172.17.17.1/detail- 20060901 modcall[accounting]: module "detail" returns ok for request 15 modcall[accounting]: module "unix" returns ok for request 15 radius_xlat: '/usr/local/var/log/radius/radutmp' radius_xlat: '[EMAIL PROTECTED]' modcall[accounting]: module "radutmp" returns ok for request 15 modcall: group accounting returns ok for request 15 Sending Accounting-Response of id 199 to 172.17.17.1:1646 Finished request 15 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.17.17.1:1645, id=200, length=95 NAS-IP-Address = 172.17.17.1 NAS-Port = 3 NAS-Port-Type = ISDN User-Name = "[EMAIL PROTECTED]" CHAP-Password = 0xcc3aeb78c7482c25ab08dc0625fcb4007e Service-Type = Framed-User Framed-Protocol = PPP Processing the authorize section of radiusd.conf modcall: entering group authorize for request 16 modcall[authorize]: module "preprocess" returns ok for request 16 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 16 modcall[authorize]: module "mschap" returns noop for request 16 rlm_realm: Looking up realm "campbell.com" for User-Name = "[EMAIL PROTECTED]" rlm_realm: Found realm "campbell.com" rlm_realm: Adding Stripped-User-Name = "knguyen" rlm_realm: Proxying request from user knguyen to realm campbell.com rlm_realm: Adding Realm = "campbell.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 16 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 16 users: Matched entry knguyen at line 187 modcall[authorize]: module "files" returns ok for request 16 modcall: group authorize returns ok for request 16 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied CHAP-Password matches local User-Password Sending Access-Accept of id 200 to 172.17.17.1:1645 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 192.168.172.12 Framed-IP-Netmask = 255.255.255.128 Framed-MTU = 1492 Finished request 16 Going to the next request --- Walking the entire request list --- Waking up in 3 seconds... rad_recv: Accounting-Request packet from host 172.17.17.1:1646, id=201, length=196 NAS-IP-Address = 172.17.17.1 NAS-Port = 3 NAS-Port-Type = ISDN User-Name = "[EMAIL PROTECTED]" Acct-Status-Type = Start Acct-Authentic = RADIUS Service-Type = Framed-User Acct-Session-Id = "00000CDE" Framed-Protocol = PPP Tunnel-Server-Endpoint:0 = "12.12.126.5" Tunnel-Client-Endpoint:0 = "12.12.126.6" Tunnel-Type:0 = L2TP Tunnel-Client-Auth-Id:0 = "CAMPBELL" Tunnel-Server-Auth-Id:0 = "sfldse26rr.mi.AADS" Acct-Tunnel-Connection = "13443112" Framed-IP-Address = 192.168.172.12 Acct-Delay-Time = 0 Processing the preacct section of radiusd.conf modcall: entering group preacct for request 17 modcall[preacct]: module "preprocess" returns noop for request 17 rlm_acct_unique: Hashing 'NAS-Port = 3,Client-IP-Address = 172.17.17.1,NAS-IP-Address = 172.17.17.1,Acct-Session-Id = "00000CDE",User-Name = "[EMAIL PROTECTED]"' rlm_acct_unique: Acct-Unique-Session-ID = "1bc07890bf12381b". modcall[preacct]: module "acct_unique" returns ok for request 17 rlm_realm: Looking up realm "campbell.com" for User-Name = "[EMAIL PROTECTED]" rlm_realm: Found realm "campbell.com" rlm_realm: Adding Stripped-User-Name = "knguyen" rlm_realm: Proxying request from user knguyen to realm campbell.com rlm_realm: Adding Realm = "campbell.com" rlm_realm: Accounting realm is LOCAL. modcall[preacct]: module "suffix" returns noop for request 17 modcall[preacct]: module "files" returns noop for request 17 modcall: group preacct returns ok for request 17 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 17 radius_xlat: '/usr/local/var/log/radius/radacct/172.17.17.1/ detail-20060901' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP- Address}/detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/172.17.17.1/detail- 20060901 modcall[accounting]: module "detail" returns ok for request 17 modcall[accounting]: module "unix" returns ok for request 17 radius_xlat: '/usr/local/var/log/radius/radutmp' radius_xlat: '[EMAIL PROTECTED]' modcall[accounting]: module "radutmp" returns ok for request 17 modcall: group accounting returns ok for request 17 Sending Accounting-Response of id 201 to 172.17.17.1:1646 Finished request 17 Going to the next request Waking up in 3 seconds... --- Walking the entire request list --- Cleaning up request 15 ID 199 with timestamp 44f8a6aa Waking up in 3 seconds... --- Walking the entire request list --- Cleaning up request 16 ID 200 with timestamp 44f8a6ad Cleaning up request 17 ID 201 with timestamp 44f8a6ad Nothing to do. Sleeping until we see a request. ---- Original message ---- >Date: Wed, 04 Oct 2006 14:11:04 +1000 >From: James Wakefield <[EMAIL PROTECTED]> >Subject: Re: only work with 5 users or clients >To: [EMAIL PROTECTED] >Cc: FreeRadius users mailing list <freeradius- [EMAIL PROTECTED]> > >Hi Tom, > >I see nothing that should cause the behaviour you're seeing, though bear >in mind I'm not a VPDN expert. > >Could you post: > >* An Access-Request packet logged when your setup is working >* The Access-Accept packet that corresponds with the above Access-Request >* An Access-Request packet when your setup is *not* working >* The Access-Accept packet that corresponds with the above Access-Request > >Could you also perhaps check on the general health of your router and >the AAA server when the setup isn't working? Does it coincide with >anomalous CPU usage, load average, memory usage etc? > >I don't *think* you need to check or reply with any tunnelling-related >attributes in simple cases of a VPDN setup, but as I say, I'm not an >expert in that area. > >Cheers, >James. > > >Tom Miller wrote: >> Here is a more details list of aaa for my Cisco 7204 >> configuration: >> >> aaa new-model >> aaa authentication login default local >> aaa authentication login console enable >> aaa authentication login telnet line >> aaa authentication login localauth local >> aaa authentication ppp default group radius local >> aaa authorization network default group radius local >> aaa accounting delay-start >> aaa accounting nested >> aaa accounting exec default start-stop group radius >> aaa accounting network default start-stop group radius >> >> >> ! >> vpdn enable >> vpdn aaa override-server 172.17.17.17 >> ! >> vpdn-group 1 >> accept-dialin >> protocol l2tp >> virtual-template 1 >> terminate-from hostname aaaabbbr.ca.AADS >> local name abc123456789cha >> lcp renegotiation always >> l2tp tunnel password 7 xxxxxxxxxxxxxxxx >> ! >> >> radius-server host 172.17.17.17 auth-port 1645 acct-port 1646 >> >> >> ! >> interface Virtual-Template1 >> mtu 1492 >> ip address 192.168.172.1 255.255.255.128 >> peer default ip address pool DSLCustomer >> ppp authentication chap callin >> ! >> ip local pool DSLCustomer 192.168.172.51 192.168.172.125 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ---- Original message ---- >>> Date: Mon, 02 Oct 2006 09:18:59 +1000 >>> From: James Wakefield <[EMAIL PROTECTED]> >>> Subject: Re: only work with 5 users or clients >>> To: [EMAIL PROTECTED], FreeRadius users mailing list >> <freeradius-users@lists.freeradius.org> >>> Tom Miller wrote: >>>> I have a 7204 (12.0(22)S1) terminating DSL L2TP VPDN and >>>> freeradius ( 1.0.4) >>>> >>>> I am having problem when number of users (clients) >>>> increase from 6 and up. >>>> >>>> It worked fine when I have only 5 users (clients) using >>>> the system. >>>> >>>> >>>> I found the max_requests was set at 1024 in radiusd.conf >> and >>>> have inscrease the number up to 50 clients (50x256=12800) >>>> >>>> max_requests = 12800 >>>> >>>> >>>> >>>> However, It doesn't seem to have any effect. What am I >> doing >>>> wrong. >>>> >>>> >>>> One things I noticed. The two users that can not connect >>>> will sent incomplete information >>>> to the radius server from NAS (7204) such as: >>>> >>>> >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host >> 192.168.17.1:1645, >>>> id=200, length=95 >>>> NAS-IP-Address = 192.168.17.1 >>>> NAS-Port = 3 >>>> NAS-Port-Type = ISDN >>>> User-Name = "[EMAIL PROTECTED]" >>>> CHAP-Password = 7482c25ab08ffsddfddc0625fcb4007e >>>> Service-Type = Framed-User >>>> Framed-Protocol = PPP >>>> >>>> auth: user supplied CHAP-Password matches local User- >> Password >>>> Sending Access-Accept of id 200 to 192.168.17.1:1645 >>>> Service-Type = Framed-User >>>> Framed-Protocol = PPP >>>> Framed-IP-Address = 209.101.222.12 >>>> Framed-IP-Netmask = 255.255.255.128 >>>> Framed-MTU = 1492 >>>> Finished request 16 >>>> Going to the next request >>>> >>>> >>>> >>>> >>>> *********** This is a log when it connected. It >> included >>>> the Tunnel server and client end point ********* >>>> >>>> >>>> >>>> rad_recv: Accounting-Request packet from host >>>> 192.168.17.1:1646, id=199, length=232 >>>> NAS-IP-Address = 192.168.17.1 >>>> NAS-Port = 6 >>>> NAS-Port-Type = ISDN >>>> User-Name = "[EMAIL PROTECTED]" >>>> Acct-Status-Type = Stop >>>> Acct-Authentic = RADIUS >>>> Service-Type = Framed-User >>>> Acct-Session-Id = "00000CD8" >>>> Framed-Protocol = PPP >>>> Tunnel-Server-Endpoint:0 = "10.10.6.5" >>>> Tunnel-Client-Endpoint:0 = "10.10.6.6" >>>> Tunnel-Type:0 = L2TP >>>> Tunnel-Client-Auth-Id:0 = "12345678" >>>> Tunnel-Server-Auth-Id:0 = "sfldse26rr.wi.AADS" >>>> Acct-Tunnel-Connection = "13441125" >>>> Framed-IP-Address = 209.101.222.12 >>>> Acct-Terminate-Cause = Admin-Reset >>>> Acct-Input-Octets = 281672 >>>> Acct-Output-Octets = 266074 >>>> Acct-Input-Packets = 4390 >>>> Acct-Output-Packets = 4154 >>>> Acct-Session-Time = 1967 >>>> Acct-Delay-Time = 0 >>>> Processing the preacct section of radiusd.conf >>>> >>> This is an accounting stop record, as opposed to the access >> accept >>> record you display above and below. It isn't necessarily >> indicative of >>> what freeradius sent to the NAS, or anything else that >> happened when the >>> client connected. >>> >>>> --- Walking the entire request list --- >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host >> 172.17.17.1:1645, >>>> id=200, length=95 >>>> NAS-IP-Address = 172.17.17.1 >>>> NAS-Port = 3 >>>> NAS-Port-Type = ISDN >>>> User-Name = "[EMAIL PROTECTED]" >>>> CHAP-Password = >> 0xcc3aeb78c7482c25ab08dc0625fcb4007e >>>> Service-Type = Framed-User >>>> Framed-Protocol = PPP >>>> >>>> auth: user supplied CHAP-Password matches local User- >> Password >>>> Sending Access-Accept of id 200 to 172.17.17.1:1645 >>>> Service-Type = Framed-User >>>> Framed-Protocol = PPP >>>> Framed-IP-Address = 38.101.172.12 >>>> Framed-IP-Netmask = 255.255.255.128 >>>> Framed-MTU = 1492 >>>> Finished request 16 >>>> Going to the next request >>>> >>>> >>>> What am I missing here? >>> How are you authenticating and authorizing your users? >> users file, some >>> sort of database or directory? Could you send some >> relevant excerpts >>>from those sources, eg: some users file stanzas if you're >> using the >>> users file, objects from your LDAP directory in LDIF if >> you're using LDAP? >>> My hunch is that freeradius isn't configured to send the >> necessary >>> attributes and your NAS is defaulting those attributes, but >> can't do >>> that for more than 5 concurrent users. Unless you're >> observing >>> considerable delay between the receipt of access-request >> and the sending >>> of access-accept (ie: more than a couple of seconds), or >> freeradius is >>> sending different attributes with the access-accept for the >> same user >>> when things seem to be going wrong to when they're going >> right, I think >>> you're missing some attributes or your NAS is misconfigured >> or both. >>> >>> Cheers, >>> -- >>> James Wakefield, >>> Unix Administrator, Information Technology Services Division >>> Deakin University, Geelong, Victoria 3217 Australia. >>> >>> Phone: 03 5227 8690 International: +61 3 5227 8690 >>> Fax: 03 5227 8866 International: +61 3 5227 8866 >>> E-mail: [EMAIL PROTECTED] >>> Website: http://www.deakin.edu.au > > >-- >James Wakefield, >Unix Administrator, Information Technology Services Division >Deakin University, Geelong, Victoria 3217 Australia. > >Phone: 03 5227 8690 International: +61 3 5227 8690 >Fax: 03 5227 8866 International: +61 3 5227 8866 >E-mail: [EMAIL PROTECTED] >Website: http://www.deakin.edu.au - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html