I'm hoping somebody can shed a little light on this, I found it very strange. btw: we're talking about freeradius version 1.1.3 here. We currently run some lesser radius server on our network, and I have been engaged in converting the environment to freeradius (yea!). I believe we have worked out (lab and pilot-site testing) all the kinks for our authentication needs, and today we attempted to implement the change across our whole network. Our lesser radius server lives on two physical boxes and listens on ports 1645/1646 AND 1812/1813 (can freeradius mimic this and listen on both sets of ports?) Our plan has been to make sure appropriate radius client devices were all pointing to the 1812/1813 authentication ports prior to the change. The change involved stopping the lesser server and bringing up freeradius on the ports 1812/1813 on both of the two physical servers. The idea was that the clients (chiefly Cisco WAPs) would have a seemless conversion and continue to authenticate using the same IP and ports they were previously using. This however was not the observed result. What happened was almost universal failure. What we saw were requests coming into freeradius, being processed as expected, and returning the appropriate response - many Accept responses clearly visible in the logs. The radius clients however did not accept these responses and treated them as authentication failure. The pilot: We ran freeradius on ports 11812/11813 on these same physical servers, side-by-side with the lesser radius server. We then pointed the client devices to the alternate port combination. They were successful and behaved exactly as expected. Log (debug) output from freeradius for the successful pilots and the failed implementation today are identical, however, with the new ports today 1812/1813 the pilot sites who had previously been working also failed. Does anyone have an idea what could have happened here? If a radius client was talking to server X, and then suddenly recieves a response from server Y on the same IP / port combination... is there some way that the client can tell the server has changed, and thus reject any responses from it as invalid? Does the radius client bind in some way to the server (on the application layer I would assume)? Shared secrets are the same and the request is clearly visible and processed by freeradius. debug output for a request looks like the following: freeradius does it's job but the client device doesn't authenticate the user. Please note that LDAP should fail in this instance. LDAP is used for another kind of authentication. The users file which matches DEFAULT at line 7798 is where the authentication comes from. Nov 29 10:58:48 rad_recv: Access-Request packet from host 10.32.251.10:32768, id=105, length=183 Nov 29 10:58:48 User-Name = "0014a4858ad0" Nov 29 10:58:48 Called-Station-Id = "00-15-62-a9-cc-50:guest" Nov 29 10:58:48 Calling-Station-Id = "00-14-a4-85-8a-d0" Nov 29 10:58:48 NAS-Port = 29 Nov 29 10:58:48 NAS-IP-Address = 10.32.251.10 Nov 29 10:58:48 NAS-Identifier = "co-lp-wlc01" Nov 29 10:58:48 Airespace-Wlan-Id = 7 Nov 29 10:58:48 User-Password = "********" Nov 29 10:58:48 Service-Type = Call-Check Nov 29 10:58:48 Framed-MTU = 1300 Nov 29 10:58:48 NAS-Port-Type = Wireless-802.11 Nov 29 10:58:48 Tunnel-Type:0 = VLAN Nov 29 10:58:48 Tunnel-Medium-Type:0 = IEEE-802 Nov 29 10:58:48 Tunnel-Private-Group-Id:0 = "2250" Nov 29 10:58:48 Processing the authorize section of radiusd.conf Nov 29 10:58:48 modcall: entering group authorize for request 0 Nov 29 10:58:48 hints: Matched DEFAULT at 39 Nov 29 10:58:48 modcall[authorize]: module "preprocess" returns ok for request 0 Nov 29 10:58:48 rlm_realm: No '@' in User-Name = "0014a4858ad0", looking up realm NULL Nov 29 10:58:48 rlm_realm: No such realm "NULL" Nov 29 10:58:48 modcall[authorize]: module "suffix" returns noop for request 0 Nov 29 10:58:48 users: Matched entry DEFAULT at line 7798 Nov 29 10:58:48 modcall[authorize]: module "files" returns ok for request 0 Nov 29 10:58:48 radius_xlat: '/usr/local/freeradius/etc/scripts/wireless.atz 0014a4858ad0' Nov 29 10:58:48 Exec-Program: /usr/local/freeradius/etc/scripts/wireless.atz 0014a4858ad0 Nov 29 10:58:48 Exec-Program output: Requested WLAN is not restricted, deferring authentication. Nov 29 10:58:48 Exec-Program-Wait: plaintext: Requested WLAN is not restricted, deferring authentication. Nov 29 10:58:48 Exec-Program: returned: 0 Nov 29 10:58:48 modcall[authorize]: module "wireless" returns ok for request 0 Nov 29 10:58:48 rlm_ldap: - authorize Nov 29 10:58:48 rlm_ldap: performing user authorization for 0014a4858ad0 Nov 29 10:58:48 radius_xlat: '(&(uid=0014a4858ad0)(accesslist=)(isaccountenabled=true))' Nov 29 10:58:48 radius_xlat: 'o=xyz' Nov 29 10:58:48 rlm_ldap: ldap_get_conn: Checking Id: 0 Nov 29 10:58:48 rlm_ldap: ldap_get_conn: Got Id: 0 Nov 29 10:58:48 rlm_ldap: attempting LDAP reconnection Nov 29 10:58:48 rlm_ldap: (re)connect to ldapvip.co.ihc.com:389, authentication 0 Nov 29 10:58:48 rlm_ldap: bind as appl=VPN Radius Server, ou=applications, o=xyz/******** to ldapvip.xyz.com:389 Nov 29 10:58:48 rlm_ldap: waiting for bind result ... Nov 29 10:58:48 rlm_ldap: Bind was successful Nov 29 10:58:48 rlm_ldap: performing search in o=xyz, with filter (&(uid=0014a4858ad0)(accesslist=)(isaccountenabled=true)) Nov 29 10:58:48 rlm_ldap: object not found or got ambiguous search result Nov 29 10:58:48 rlm_ldap: search failed Nov 29 10:58:48 rlm_ldap: ldap_release_conn: Release Id: 0 Nov 29 10:58:48 modcall[authorize]: module "ldap" returns notfound for request 0 Nov 29 10:58:48 modcall: leaving group authorize (returns ok) for request 0 Nov 29 10:58:48 rad_check_password: Found Auth-Type Accept Nov 29 10:58:48 rad_check_password: Auth-Type = Accept, accepting the user Nov 29 10:58:48 Sending Access-Accept of id 105 to 10.32.251.10 port 32768 Nov 29 10:58:48 Finished request 0 Thanks, Lin