Configuring IEEE 802.1x and IEEE 802.11i Authentication

Enable RADIUS Accounting

By default, the vEdge router never sends interim accounting updates to the 802.1x RADIUS accounting server. Accounting updates are sent only when the 802.1x session ends.

To enable the sending of interim accounting updates, configure the interval at which to send the updates:

vEdge(config-dot1x)# accounting-interval seconds

The time can be from 0 through 7200 seconds.

Enable MAC Authentication Bypass

IEEE 802.1x authentication is accomplished through an exchange of Extensible Authentication Procotol (EAP) packets. After 802.1x-compliant clients respond to the EAP packets, they can be authenticated and granted access to the network. Enabling MAC authentication bypass (MAB) provides a mechanism to allow non-802.1x–compliant clients to be authenticated and granted access to the network.

The vEdge router determines that a device is non-802.1x–compliant clients when the 802.1x authentication process times out while waiting for an EAPOL response from the client.

To enable MAC authentication bypass for an 802.1x interface on the vEdge router:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# mac-authentication-bypass

With this configuration, the vEdge router authenticates non-802.1x–compliant clients using the configured RADIUS servers. The RADIUS server must be configured with the MAC addresses of non-802.1x–compliant clients that are allowed to access the network.

To allow authentication to be performed for one or more non-802.1x–compliant clients before performing an authentication check with the RADIUS server, list their MAC addresses in the following command:

vEdge(config-dot1x)# mac-authentication-bypass allow mac-addresses

You can configure up to eight MAC addresses for MAC authentication bypass. For these devices, the vEdge router grants immediate network access based on their MAC addresses, and then sends a request to the RADIUS server to authenticate the devices.

Configure VLANs for Authenticated and Unauthenticated Clients

For clients that cannot be authenticated but that you want to provide limited network services to, you create VLANs to handle network access for these clients. You also create VLANs to handle authenticated clients.

You can create the following kinds of VLAN:

• Guest VLAN—Provide limited services to non-802.1x–compliant clients.
• Authentication Reject VLAN—Provide limited services to 802.1x-compliant clients that failed RADIUS authentication. An authentication-reject VLAN is similar to a restricted VLAN.
• Authentication Fail VLAN—Provide network access when RADIUS authentication or the RADIUS server fails. An authentication-fail VLAN is similar to a critical VLAN.
• Default VLAN—Provide network access to 802.1x–compliant clients that are successfully authenticated by the RADIUS server. If you do not configure a default VLAN on the vEdge router, successfully authenticated clients are placed into VLAN 0, which is the VLAN associated with an untagged bridge.

To configure the VLANs for authenticated and unauthenticated clients, first create the VLAN in a bridging domain, and then create the 802.1x VLANs for the unauthenticated clients by associating the bridging domain VLAN with an 802.1x VLAN.

To create the VLAN, configure a bridging domain to contain the VLAN:

vEdge(config)# bridge bridge-id
vEdge(config-bridge)# name text
vEdge(config-bridge)# vlan vlan-id
vEdge(config-bridge)# interface interface-name
vEdge(config-interface)# no shutdown

The bridging domain identifier is a number from 1 through 63. A best practice is to have the bridge domain ID be the same as the VLAN number.

The name is optional, but it is recommended that you configure a name that identifies the 802.1x VLAN type, such as Guest-VLAN and Default-VLAN.

The VLAN number can be from 1 through 4095. This is the number that you associate with an 802.1x VLAN.

The interface name is the interface that is running 802.1x.

Then configure the 802.1x VLANs to handle unauthenticated clients.

A guest VLAN provides limited services to non-802.1x–compliant clients, and it can be used to allow clients to download 802.1x client software. An interface running 802.1x assigns clients to a guest VLAN when the interface does not receive a response to EAP request/identity packets that it has sent to the client, or when the client does not send EAPOL packets and MAC authentication bypass is not enabled. To configure a guest VLAN:

vEdge(config)# vpn 0 interface interface-name interface dot1x
vEdge(config-dot1x)# guest-vlan vlan-id

The VLAN number must match one of the VLANs you configured in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

An authentication-reject VLAN provides limited services to 802.1x-compliant clients that have failed RADIUS authentication. To configure an authentication-reject VLAN:

vEdge(config-dot1x)# auth-reject-vlan vlan-id

The VLAN number must match one of the VLANs you configure in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

When the RADIUS authentication server is not available, 802.1x-compliant clients attempting to authenticate are placed in an authentication-fail VLAN if it is configured. If this VLAN is not configured, the authentication request is eventually dropped. To configure the authentication-fail VLAN:

vEdge(config-dot1x)# auth-fail-vlan vlan-id

The VLAN number must match one of the VLANs you configure in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

The following configuration snippet illustrates the interrelationship between the 802.1x configuration and the bridging domain configuration. This snippet shows that the bridging domain numbers match the VLAN numbers, which is a recommended best practice. Also, the bridging domain name identifies the type of 802.1x VLAN.

system
 ...
 radius
  server 10.1.15.150
   tag              freerad1
   source-interface ge0/0
   secret-key       $4$L3rwZmsIic8zj4BgLEFXKw==
   priority         1
  exit
  server 10.20.24.150
   auth-port        2000
   acct-port        2001
   tag              freerad2
   source-interface ge0/4
   secret-key       $4$L3rwZmsIic8zj4BgLEFXKw==
   priority         2
  exit
 !
!
bridge 1
 name Untagged_bridge
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 10
 name Authorize_VLAN
 vlan 10
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 20
 name Guest_VLAN
 vlan 20
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 30
 name Critical_VLAN
 vlan 30
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 40
 name Restricted_VLAN
 vlan 40
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
vpn 0
 interface ge0/0
  ip address 10.1.15.15/24
  tunnel-interface
   encapsulation ipsec
   ...
  !
  no shutdown
 !
 interface ge0/1
  ip address 60.0.1.16/24
  no shutdown
 !
 interface ge0/2
  ip address 10.1.19.15/24
  no shutdown
 !
 interface ge0/4
  ip address 10.20.24.15/24
  no shutdown
 !
 interface ge0/5
  dot1x
   auth-reject-vlan 40
   auth-fail-vlan   30
   guest-vlan       20
   default-vlan     10
   radius-servers   freerad1
  !
  no shutdown
 !
 interface ge0/7
  ip address 10.0.100.15/24
  no shutdown
 !
!
vpn 1
 interface ge0/2.1
  ip address 10.2.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb1
  ip address 56.0.1.15/24
  mac-address 00:00:00:00:aa:01
  no shutdown
  dhcp-server
   address-pool 56.0.1.0/25
   offer-time   600
   lease-time   86400
   admin-state  up
   options
    default-gateway 56.0.1.15
   !
  !
 !
!
vpn 10
 interface ge0/2.10
  ip address 10.10.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb10
  ip address 56.0.10.15/24
  mac-address 00:00:00:00:aa:10
  no shutdown
  dhcp-server
   address-pool 56.0.10.0/25
   offer-time   600
   lease-time   86400
   admin-state  up
   options
    default-gateway 56.0.10.15
   !
  !
 !
!
vpn 20
 interface ge0/2.20
  ip address 10.20.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb20
  ip address 56.0.20.15/24
  mac-address 00:00:00:00:aa:20
  no shutdown
 !
!
vpn 30
 interface ge0/2.30
  ip address 10.30.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb30
  ip address 56.0.30.15/24
  mac-address 00:00:00:00:aa:30
  no shutdown
 !
!
vpn 40
 interface ge0/2.40
  ip address 10.40.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb40
  ip address 56.0.40.15/24
  mac-address 00:00:00:00:aa:40
  no shutdown
 !
!
vpn 512
 interface eth0
  ip dhcp-client
  no shutdown
 !
!

Configure Control Direction

To configure how the 802.1x interface handles traffic when the client is unauthorized, set the control direction:

vEdge(config-dot1x)# control-direction (in-and-out | in-only)

The direction can be one of the following:

• in-and-out—The 802.1x interface can both send packets to and receive packets from the authorized client. Bidirectional control is the default behavior.
• in-only—The 802.1x interface can send packets to the unauthorized client, but cannot receive packets from that client.

Configure Authentication with Wake on LAN

IEEE 802.1X authentication wake on LAN (WoL) allows dormant clients to be powered up when the vEdge router receives a type of Ethernet frame called the magic packet. Administrators can use wake on LAN when to connect to systems that have been powered down.

When a client that uses wake on LAN and that attaches through an 802.1X port powers off, the 802.1X port becomes unauthorized. The port can only receive and send EAPOL packets, and wake-on-LAN magic packets cannot reach the client. When the device is powered off, it is not authorized, and the switch port is not opened.

Without wake on LAN, when an 802.1x port is unauthorized, the router's 802.1x interface block traffic other than EAPOL packets coming from unauthorized clients.

When you enable wake on LAN on an 802.1x port, the vEdge router is able to send magic packets even if the 802.1x port is unauthorized.

To enable wake on LAN on an 802.1x interface, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# wake-on-lan

Configure 802.1x Host Mode

The host mode of an 802.1x interfaces determines whether the interface grants access to a single client or to multiple clients. Three host modes are available:

• Single-host mode—The 802.1x interface grants access only to the first authenticated client. All other clients attempting access are denied and dropped.
• Multiple-host mode—A single 802.1x interface grants access to multiple clients. In this mode, only one of the attached clients must be authorized for the interface to grant access to all clients. If the interface becomes unauthorized, the vEdge router denies network access to all the attached clients.
• Multiple-authentication mode—A single 802.1x interface grants access to multiple authenticated clients on data VLANs.

To configure the host mode of the 802.1x interface, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# host-mode (multi-auth | multi-host | single-host)

Set the Timeout for Inactive Clients

By default, when a client has been inactive on the network for 1 hour, its authentication is revoked, and the client is timed out. To change the timeout interval, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# timeout inactivity minutes

The timeout interval can be from 0 through 1440 minutes (24 hours).

Enable Periodic Client Reauthentication

By default, once a client session is authenticated, that session remains functional indefinitely. To enable the periodic reauthentication of 802.1x clients, configure the number of minutes between reauthentication attempts:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# reauthentication minutes

The time can be from 0 through 1440 minutes (24 hours)

Configure Dynamic Authorization Service for RADIUS Change of Authorization

Dynamic authorization service (DAS) allows an 802.1x interface on a vEdge router to accept change of authorization (CoA) requests from a RADIUS or other authentication server and to act on the requests. The Viptela implementation of DAS supports disconnect packets, which immediately terminate user sessions, and reauthentication CoA requests, which modify session authorization attributes.

DAS, defined in RFC 5176, is an extension to RADIUS that allows the RADIUS server to dynamically change 802.1x session information without requiring the vEdge router to initiate the change request. When you enable DAS on the vEdge router, the router opens a socket to listen for CoA requests from the RADIUS server. If the network administrator of a RADIUS server modifies the authentication of an 802.1x client, the RADIUS server sends a CoA request to inform the router about the change of authorization. When the router receives the CoA request, it processes the requested change.

To enable DAS for an 802.1x interface, you configure information about the RADIUS server from which the interface can accept CoA requests. In the context of configuring DAS, the vEdge router is the server and the RADIUS server (or other authentication server) is the client.

To configure the RADIUS server from which to accept CoA requests, configure the server's IP address and the password that the RADIUS server uses to access the router's 802.1x interface:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# das
vEdge(config-das)# client ip-address
vEdge(config-das)# secret-key password

You can configure the VPN through which the RADIUS server is reachable:

vEdge(config-das)# vpn vpn-id

By default, the 802.1x interface uses UDP port 3799 to listen for CoA request from the RADIUS server. You can change the port number:

vEdge(config-das)# port port-number

The port number can be a value from 1 through 65535. If you configure DAS on multiple 802.1x interfaces on a vEdge router, you must configure each interface to use a different UDP port.

By default, the CoA requests that the vEdge router receives from the DAS client are all honored, regardless of when the router receives them. To have the router handle CoA within a specified time, you require that the DAS client timestamp all CoA requests:

vedge(config-das)# require-timestamp

With this configuration, the vEdge router processes only CoA requests that include an event timestamp. Non-timestamped CoA requests are dropped immediately.

When timestamping is configured, both the vEdge router and the RADIUS server check that the timestamp in the CoA request is current and within a specific time window. The default time window is 300 seconds (5 minutes). This behavior means that if the DAS timestamps a CoA at 15:00 and the router receives it at 15:04, the router honors the request. However, if the router receives the request at 15:10, the router drops the CoA request. You can change the time window to a time from 0 through 1000 seconds:

vEdge(config-das)# time-window seconds

Configure RADIUS Authentication and Accounting Attributes

For IEEE 802.1x authentication and accounting, the vEdge router, acting as a network access server (NAS), sends RADIUS attribute–value (AV) pairs to the RADIUS server. These AV pairs are defined in RFC 2865, RADIUS, RFC 2866, RADIUS Accounting, and RFC 2869, RADIUS Extensions. The AV pairs are placed in the Attributes field of the RADIUS packet.

By default, when you enable IEEE 802.1x port security, the following authentication attributes are included in messages sent to the RADIUS server:

When you enable RADIUS accounting, the following accounting attributes are included, by default, in messages sent to the RADIUS server:

Several configuration commands allow you to add additional attribute information to RADIUS packets.

To include the NAS-IP-Address (attribute 4) in messages sent to the RADIUS server, to indicate the IP address of the vEdge router that is acting as a NAS server:

vEdge(config-dot1x) nas-ip-address ip-address

To include the NAS-Identifier (attribute 32) in messages sent to the RADIUS server, use the following command:

vEdge(config-dot1x)# nas-identifier string

The NAS identifier is a unique string from 1 through 255 characters long that identifies the vEdge router that is acting as a NAS server.

To include a RADIUS authentication or accounting attribute of your choice in messages sent to the RADIUS server, use the following commands:

vEdge(config-dot1x)# auth-req-attr attribute-number (integer integer | octet octet | string string)
vEdge(config-dot1x)# acct-req-attr attribute-number (integer integer | octet octet | string string)

Specify the desired value of the attribute as an integer, octet value, or string, depending on the attribute. For example, to set the Service-Type attribute to be authenticate-only:

vEdge(config-dot1x)# auth-req-attr 6 integer 8