Monday, April 5, 2010

Local RADIUS on Cisco Autonomous APs

Cisco autonomous access points may be configured as a local RADIUS server to provide AAA authentication services. This is typically done for a small wireless LAN which can't afford a centralized solution, to provide a backup authentication service, or to facilitate infrastructure connections between access points for bridging or WDS operation.

As a local RADIUS server, the access point performs LEAP, EAP-FAST, and MAC-based authentication for up to 50 client devices. The access point performs up to 5 authentications per second.

When you configure the local authenticator as a backup to your main servers, the access points periodically check the link to the main servers and stop using the local authenticator automatically when the link to the main servers is restored.

Deployment guidelines:
  • The local RADIUS server only listens on UDP ports 1812 and 1812, not the legacy ports 1645 and 1646
  • Do not use an AP that serves a large number of clients because performance may be degraded
  • Secure the AP because it contains sensitive credentials in the configuration file
Configuration of local RADIUS is fairly simple when keeping a few architecture points in mind as a reference point:
  1. The AP serves the role of the 802.1x authentication server once local RADIUS is enabled
  2. The AP also serves as the 802.1x authenticator (NAS), the same as when using a central RADIUS server
  3. The two roles must be tied together
  4. The same AAA new-model architecture and commands are used for configuration of RADIUS servers, including AAA groups, method-lists, and assignment of method-lists to SSIDs, WDS, etc.
Here is an example configuration to illustrate. The local AP has an IP address of and is configured to point to itself as for client authentication on the SSID "bridge".

aaa new-model
! Define a AAA group containing the local RADIUS server.
aaa group server radius rad_local
   server auth-port 1812 acct-port 1813
! Define a AAA login method-list.
! This list will be applied to SSIDs, WDS, etc.
aaa authentication login eap_local group rad_local
! Apply the method-list to an SSID if desired. This
! SSID example shows a bridge-link with this AP as the Root.
dot11 ssid bridge
   vlan 4
   authentication open eap eap_local
   authentication network-eap eap_local
   authentication key-management wpa
! Enable the local 802.1x authentiation server on the AP.
! Define what authentication methods (LEAP, EAP-FAST, MAC) are
! not allowed, what NAS clients are allowed, and create local
! users on the AP.

! Configure the local AP and any other APs authenticating clients
! as NAS entries.
radius-server local
   no authentication mac
   nas key nas-shared-secret
   user wds password wds-user-password
   user bridge password bridge-user-password
! Configure the local AP 802.1x authenticator. Create an entry
! for the local RADIUS server.
radius-server host auth-port 1812 acct-port 1813 key nas-shared-secret
The configuration of local RADIUS is straightforward as long as you remember that the AP is serving both 802.1x roles which must be configured independently.
Several additional features may be configured in the local RADIUS server, which are not illustrated in the example above:
  • User groups, which may restrict users to specific VLANs or SSIDs, define client re-authentication timers, and specify EAP-FAST PAC expiry periods.
  • MAC authentication is provided when user's are defined using the hexadecimal MAC address (without delimiters) as both the username and password.
  • EAP-FAST server identity (authority ID, server-key)
  • Manual PAC file generation and export for installation on client devices

Although defining a local RADIUS server is fairly easy, remember that it is not a scalable solution. However, it may have a place in your network design strategy for small sites, backup authentication service, or authentication of infrastructure components without relying on a centralized solution.

I have most-often seen local RADIUS deployed to ensure bridge links and WDS services remain in operation even though connection to central RADIUS servers is interrupted.



  1. Amazing Andrew. Thank you. But I have a major concern: Will LEAP work fine if I did not use network-eap? I mean if I use normal open with eap only and configure LEAP as the EAP type on the client? I am trying to get it to work since two days with no hope :(

    1. No, network EAP is required for LEAP to work.


  2. Hello Andrew, I have a problem to start this type of authentication with my AP.
    I used the config you posted but I'm not getting login.
    I enabled some debugs and what happens is these posts:

    an 3 12:15:11.896: AAA/BIND(000000A5): Bind i/f Jan 3 12:15:11.896: dot1x-registry:registry:dot1x_ether_macaddr called Jan 3 12:15:14.943: dot1x-ev:dot1x_mgr_process_eapol_pak: dot1x eapol on dot11 interface Jan 3 12:15:14.944: dot1x-ev:dot1x_mgr_pre_process_eapol_pak: Role determination not required on Dot11Radio0.1. Jan 3 12:15:14.944: dot1x-packet:dot1x_mgr_process_eapol_pak: queuing an EAPOL pkt on Authenticator Q Jan 3 12:15:14.944: dot1x-registry:registry:dot1x_ether_macaddr called Jan 3 12:15:27.512: dot1x-ev:dot1x_mgr_process_eapol_pak: dot1x eapol on dot11 interface Jan 3 12:15:27.512: dot1x-ev:dot1x_mgr_pre_process_eapol_pak: Role determination not required on Dot11Radio0.1. Jan 3 12:15:27.512: dot1x-err:No dot1x subblock Jan 3 12:15:27.512: dot1x-packet:dot1x_mgr_process_eapol_pak: queuing an EAPOL pkt on Authenticator

    Could you and give help?
    Thanks in advance.