Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

802.1X Authentication

 

IEEE 802.1X standard for port-based network access control and protects Ethernet LANs from unauthorized user access. It blocks all traffic to and from a supplicant (client) at the interface until the supplicant's credentials are presented and matched on the authentication server (a RADIUS server). When the supplicant is authenticated, the switch stops blocking access and opens the interface to the supplicant. Read this topic for more information.

802.1X for Switches Overview

How 802.1X Authentication Works

802.1X authentication works by using an authenticator port access entity (the switch) to block ingress traffic from a supplicant (end device) at the port until the supplicant's credentials are presented and match on the authentication server (a RADIUS server). When authenticated, the switch stops blocking traffic and opens the port to the supplicant.

The end device is authenticated in single supplicant mode, single-secure supplicant mode, or multiple supplicant mode:

  • single supplicant—Authenticates only the first end device. All other end devices that connect later to the port are allowed full access without any further authentication. They effectively piggyback on the first end device’s authentication.

  • single-secure supplicant—Allows only one end device to connect to the port. No other end device is allowed to connect until the first device logs out.

  • multiple supplicant—Allows multiple end devices to connect to the port. Each end device is authenticated individually.

Network access can be further defined by using VLANs and firewall filters, both of which act as filters to separate and match groups of end devices to the areas of the LAN they require. For example, you can configure VLANs to handle different categories of authentication failures depending upon:

  • Whether or not the end device is 802.1X-enabled.

  • Whether or not MAC RADIUS authentication is configured on the switch interfaces to which the hosts are connected.

  • Whether the RADIUS authentication server becomes unavailable or sends a RADIUS access-reject message. See Configuring RADIUS Server Fail Fallback (CLI Procedure).

802.1X Features Overview

The following 802.1X features are supported on Juniper Networks Ethernet Switches:

  • Guest VLAN—Provides limited access to a LAN, typically only to the Internet, for nonresponsive end devices that are not 802.1X-enabled when MAC RADIUS authentication is not configured on the switch interfaces to which the hosts are connected. Also, a guest VLAN can be used to provide limited access to a LAN for guest users. Typically, the guest VLAN provides access only to the Internet and to other guests’ end devices.

  • Server-reject VLAN—Provides limited access to a LAN, typically only to the Internet, for responsive end devices that are 802.1X-enabled but that have sent the wrong credentials. If the end device that is authenticated using the server-reject VLAN is an IP phone, voice traffic is not allowed.

  • Server-fail VLAN—Provides limited access to a LAN, typically only to the Internet, for 802.1X end devices during a RADIUS server timeout.

  • Dynamic VLAN—Enables an end device, after authentication, to be a member of a VLAN dynamically.

  • Private VLAN—Enables configuration of 802.1X authentication on interfaces that are members of private VLANs (PVLANs).

  • Dynamic changes to a user session—Enables the switch administrator to terminate an already authenticated session. This feature is based on support of the RADIUS Disconnect Message defined in RFC 3576.

  • VoIP VLAN—Supports IP telephones. The implementation of a voice VLAN on an IP telephone is vendor-specific. If the phone is 802.1X-enabled, it is authenticated as any other supplicant is. If the phone is not 802.1X-enabled, but has another 802.1X-compatible device connected to its data port, that device is authenticated, and then VoIP traffic can flow to and from the phone (provided that the interface is configured in single supplicant mode and not in single-secure supplicant mode).

    Note

    Configuring a VoIP VLAN on private VLAN (PVLAN) interfaces is not supported.

  • RADIUS accounting—Sends accounting information to the RADIUS accounting server. Accounting information is sent to the server whenever a subscriber logs in or logs out and whenever a subscriber activates or deactivates a subscription.

  • RADIUS server attributes for 802.1X—The Juniper-Switching-Filter is a vendor-specific attribute (VSA) that can be configured on the RADIUS server to further define a supplicant's access during the 802.1X authentication process. Centrally configuring attributes on the authentication server obviates the need to configure these same attributes in the form of firewall filters on every switch in the LAN to which the supplicant might connect to the LAN. This feature is based on RLI 4583, AAA RADIUS BRAS VSA Support.

The following features are supported to authenticate devices that are not 802.1X-enabled:

  • Static MAC bypass—Provides a bypass mechanism to authenticate devices that are not 802.1X-enabled (such as printers). Static MAC bypass connects these devices to 802.1X-enabled ports, bypassing 802.1X authentication.

  • MAC RADIUS authentication—Provides a means to permit hosts that are not 802.1X-enabled to access the LAN. MAC-RADIUS simulates the supplicant functionality of the client device, using the MAC address of the client as username and password.

802.1X Authentication on Trunk Ports

Starting in Junos OS Release 18.3R1, you can configure 802.1X authentication on trunk interfaces, which allows the network access device (NAS) to authenticate an access point (AP) or another connected Layer 2 device. An AP or switch connected to the NAS will support multiple VLANs, so must connect to a trunk port. Enabling 802.1X authentication on the trunk interface protects the NAS from a security breach in which an attacker might disconnect the AP and connect a laptop to get free access to network for all the configured VLANs.

Please note the following caveats when configuring 802.1X authentication on trunk interfaces.

  • Only single and single-secure supplicant modes are supported on trunk interfaces.

  • You must configure 802.1X authentication locally on the trunk interface. If you configure 802.1X authentication globally using the set protocol dot1x interface all command, the configuration is not applied to the trunk interface.

  • Dynamic VLANS are not supported on trunk interfaces.

  • Guest VLAN and server-reject VLAN are not supported on trunk interfaces.

  • Server fail fallback for VoIP clients is not supported on trunk interfaces (server-fail-voip).

  • Authentication on trunk port is not supported using captive portal.

  • Authentication on trunk port is not supported on aggregated interfaces.

  • Configuration of 802.1X authentication on interfaces that are members of private VLANs (PVLANs) is not supported on trunk ports.

Configuring 802.1X Interface Settings (CLI Procedure)

IEEE 802.1X authentication provides network edge security, protecting Ethernet LANs from unauthorized user access by blocking all traffic to and from a supplicant (client) at the interface until the supplicant's credentials are presented and matched on the authentication server (a RADIUS server). When the supplicant is authenticated, the switch stops blocking access and opens the interface to the supplicant.

Note

Before you begin, specify the RADIUS server or servers to be used as the authentication server. See Specifying RADIUS Server Connections on Switches (CLI Procedure).

To configure 802.1X on an interface:

  1. Configure the supplicant mode as single (authenticates the first supplicant), single-secure (authenticates only one supplicant), or multiple (authenticates multiple supplicants):
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name supplicant multiple
    Note

    Multiple supplicant mode is not supported on trunk interfaces.

  2. Enable reauthentication and specify the reauthentication interval:
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name reauthentication interval seconds
  3. Configure the interface timeout value for the response from the supplicant:
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name supplicant-timeout seconds
  4. Configure the timeout for the interface before it resends an authentication request to the RADIUS server:
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name server-timeout seconds
  5. Configure how long, in seconds, the interface waits before retransmitting the initial EAPOL PDUs to the supplicant:
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name transmit-period seconds
  6. Configure the maximum number of times an EAPOL request packet is retransmitted to the supplicant before the authentication session times out:
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name maximum-requests number
  7. Configure the number of times the switch attempts to authenticate the port after an initial failure. The port remains in a wait state during the quiet period after the authentication attempt.
    [edit protocols dot1x]

    user@switch# set authenticator interface interface-name retries (802.1X) number
Note

This setting specifies the number of attempts before the switch puts the interface in a HELD state.

Understanding RADIUS-Initiated Changes to an Authorized User Session

When using an authentication service that is based on a client/server RADIUS model, requests are typically initiated by the client and sent to the RADIUS server. There are instances in which a request might be initiated by the server and sent to the client in order to dynamically modify an authenticated user session already in progress. The client that receives and processes the messages is the switch, which acts as the network access server, or NAS. The server can send the switch a Disconnect message requesting to terminate a session, or a Change of Authorization (CoA) message requesting to modify the session authorization attributes.

The switch listens for unsolicited RADIUS requests on UPD port 3799, and accepts requests only from a trusted source. Authorization to send a Disconnect or CoA request is determined based on the source address and the corresponding shared secret, which must be configured on the switch as well as on the RADIUS server. For more information about configuring the source address and shared secret on the switch, see Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch.

Disconnect Messages

The RADIUS server sends a Disconnect-Request message to the switch in order to terminate a user session and discard all associated session context. The switch responds to a Disconnect-Request packet with a Disconnect-ACK message if the request is successful, that is, all associated session context is discarded and the user session is no longer connected, or with a Disconnect-NAK packet if the request fails, that is, the authenticator is unable to disconnect the session and discard all associated session context.

In Disconnect-Request messages, RADIUS attributes are used to uniquely identify the switch (NAS) and the user session. The combination of NAS identification attributes and session identification attributes included in the message must match at least one session for the request to be successful; otherwise, the switch responds with a Disconnect-NAK message. A Disconnect-Request message can contain only NAS and session identification attributes; if any other attributes are included, the switch responds with a Disconnect-NAK message.

Change of Authorization Messages

Change of Authorization (CoA) messages contain information for dynamically modifying the authorization attributes for a user session to change the authorization level. This occurs as part of a two-step authentication process, in which the endpoint is first authenticated using MAC RADIUS authentication, and is then profiled based on the type of device. The CoA message is used to apply an enforcement policy that is appropriate for the device, typically by changing the data filters or the VLAN.

The switch responds to a CoA message with a CoA-ACK message if the authorization change is successful, or a with CoA-NAK message if the change is unsuccessful. If one or more authorization changes specified in a CoA-Request message cannot be carried out, the switch responds with a CoA-NAK message.

In CoA-Request messages, RADIUS attributes are used to uniquely identify the switch (acting as the NAS) and the user session. The combination of NAS identification attributes and session identification attributes included in the message must match the identification attributes of at least one session for the request to be successful; otherwise, the switch responds with a CoA-NAK message.

CoA-Request packets also include the session authorization attributes that will be modified if the request is accepted. The supported session authorization attributes are listed below. The CoA message can contain any or all of these attributes. If any attribute is not included as part of the CoA-Request message, the NAS assumes that the value for that attribute is to remain unchanged.

  • Filter-ID

  • Tunnel-Private-Group-ID

  • Juniper-Switching-Filter

  • Juniper-VoIP-VLAN

  • Session-Timeout

CoA Request Port Bounce

When a CoA message is used to change the VLAN for an authenticated host, end devices such as printers do not have a mechanism to detect the VLAN change, so they do not renew the lease for their DHCP address in the new VLAN. Starting in Junos OS Release 17.3, the port bounce feature can be used to force the end device to initiate DHCP re-negotiation by causing a link flap on the authenticated port.

The command to bounce the port is sent from the RADIUS server using a Juniper Networks vendor-specific attribute (VSA). The port is bounced if the following VSA attribute-value pair is received in the CoA message from the RADIUS server:

  • Juniper-AV-Pair = “Port-Bounce”

To enable the port bounce feature, you must update the Junos dictionary file (juniper.dct) on the RADIUS server with the Juniper-AV-Pair VSA. Locate the dictionary file and add the following text to the file:

For more information about adding the VSA, consult the FreeRADIUS documentation.

You can disable the feature by configuring the ignore-port-bounce statement at the [edit protocols dot1x authenticator interface interface-name mac-radius] hierachy level.

Error-Cause Codes

When a disconnect or CoA operation is unsuccessful, an Error-Cause attribute (RADIUS attribute 101) can be included in the response message sent by the NAS to the server to provide detail about the cause of the problem. If the detected error does not map to one of the supported Error-Cause attribute values, the router sends the message without an error-cause attribute. See Table 1 for descriptions of error-cause codes that can be included in response messages sent from the NAS.

Table 1: Error-Cause Codes (RADIUS Attribute 101)

Code

Value

Description

201

Residual session context removed

Sent in response to a Disconnect-Request message if one or more user sessions are no longer active, but residual session context was found and successfully removed. This code is sent only within a Disconnect-ACK message.

401

Unsupported attribute

The request contains an attribute that is not supported (for example, a third-party attribute).

402

Missing attribute

A critical attribute (for example, the session identification attribute) is missing from a request.

403

NAS identification mismatch

Request contains one or more NAS identification attributes that do not match the identity of the NAS receiving the request.

404

Invalid request

Some other aspect of the request is invalid—for example, if one or more attributes are not formatted properly.

405

Unsupported service

The Service-Type attribute included with the request contains an invalid or unsupported value.

406

Unsupported extension

The entity receiving the request (either an NAS or a RADIUS proxy) does not support RADIUS-initiated requests.

407

Invalid attribute value

The request contains an attribute with an unsupported value.

501

Administratively prohibited

The NAS is configured to prohibit honoring of Disconnect-Request or CoA-Request messages for the specified session.

503

Session context not found

The session context identified in the request does not exist on the NAS.

504

Session context not removable

The subscriber identified by attributes in the request is owned by a component that is not supported. This code is sent only within a Disconnect-NAK message.

506

Resources unavailable

A request could not be honored because of lack of available NAS resources (such as memory).

507

Request initiated

The CoA-Request message includes a Service-Type attribute with a value of Authorize Only.

508

Multiple session selection unsupported

The session identification attributes included in the request match multiple sessions, but the NAS does not support requests that apply to multiple sessions.

Filtering 802.1X Supplicants by Using RADIUS Server Attributes

There are two ways to configure the a RADIUS server with port firewall filters (Layer 2 firewall filters):

  • Include one or more filter terms in the Juniper-Switching-Filter attribute. The Juniper-Switching-Filter attribute is a vendor-specific attribute (VSA) listed under attribute ID number 48 in the Juniper dictionary on the RADIUS server. Use this VSA to configure simple filter conditions for 802.1X authenticated users. Nothing needs to be configured on the switch; all of the configuration is on the RADIUS server.

  • Configure a local firewall filter on each switch and apply that firewall filter to users authenticated through the RADIUS server. Use this method for more complex filters. The firewall filter must be configured on each switch.

    Note

    If the firewall filter configuration is modified after users are authenticated using the 802.1X authentication, then the established 802.1X authentication session must be terminated and re-established for the firewall filter configuration changes to take effect.

This topic includes the following tasks:

  1. Configuring Firewall Filters on the RADIUS Server

  2. Applying a Locally Configured Firewall Filter from the RADIUS Server

Configuring Firewall Filters on the RADIUS Server

You can configure simple filter conditions by using the Juniper-Switching-Filter attribute in the Juniper dictionary on the RADIUS server. These filters are sent to a switch whenever a new user is authenticated successfully. The filters are created and applied on all EX Series switches that authenticate users through that RADIUS server without the need for you to configure anything on each individual switch.

Note

This procedure describes using FreeRADIUS software to configure the Juniper-Switching-Filter VSA. For specific information about configuring your server, consult the AAA documentation included with your server.

To configure the Juniper-Switching-Filter attribute, enter one or more filter terms by using the CLI for the RADIUS server. Each filter term consists of match conditions with a corresponding action. Enter the filter terms enclosed within quotation marks (" ") by using the following syntax:

More than one match condition can be included in a filter term. When multiple conditions are specified in a filter term, they must all be fulfilled for the packet to match the filter term. For example, the following filter term requires a packet to match both the destination IP address and the destination MAC address to meet the term criteria:

Multiple filter terms should be separated with commas—for example:

See Juniper-Switching-Filter VSA Match Conditions and Actions for definitions of match conditions and actions.

Note

On EX9200 switches, and in a Junos Fusion Enterprise with EX9200 as the aggregate device, the dynamic firewall filter is strictly applied for all IP packets. If the filter is configured to allow only a specific destination IP address, packets with other IP addresses as the destination IP will be dropped per the filter rules. This includes any IP protocol packets, such as DHCP, IGMP and ARP packets.

To configure match conditions on the RADIUS server:

  1. Verify that the Juniper dictionary is loaded on your RADIUS server and includes the filtering attribute Juniper-Switching-Filter (attribute ID 48):
    [root@freeradius]# cat /usr/local/share/freeradius/dictionary.juniper
  2. Enter the match conditions and actions. For example:
    • To deny authentication based on the 802.1Q tag (here, the 802.1Q tag is 10):

      [root@freeradius]#

      cd /usr/local/etc/raddb

      vi users

      For each relevant user, add the Juniper-Switching-Filter attribute:

      Juniper-Switching-Filter = "Match Source-dot1q-tag 10 Action deny"
    • To deny access based on a destination IP address:

      [root@freeradius]# cd /usr/local/etc/raddb

      vi users

      For each relevant user, add the Juniper-Switching-Filter attribute:

      Juniper-Switching-Filter = “Match Destination-ip 192.168.1.0/31 Action deny”
    • To set the packet loss priority (PLP) to high based on a destination MAC address and the IP protocol:

      [root@freeradius]# cd /usr/local/etc/raddb

      vi users

      For each relevant user, add the Juniper-Switching-Filter attribute:

      Juniper-Switching-Filter = "Match Destination-mac 00:04:0f:fd:ac:fe, Ip-protocol 2, forwarding-class high, Action loss-priority high"
      Note

      For the forwarding-class option to be applied, the forwarding class must be configured on the switch and the packet loss priority specified. If it is not configured on the switch, this option is ignored. You must specify both the forwarding class and the packet loss priority.

  3. Stop and restart the RADIUS process to activate the configuration.

Applying a Locally Configured Firewall Filter from the RADIUS Server

You can apply a port firewall filter (Layer 2 firewall filter) to user policies centrally from the RADIUS server. The RADIUS server can then specify the firewall filters that are to be applied to each user that requests authentication, reducing the need to configure the same firewall filter on multiple switches. Use this method when the firewall filter contains a large number of conditions or you want to use different conditions for the same filter on different switches. The firewall filters must be configured on each switch.

For more information about firewall filters, see Firewall Filters for EX Series Switches Overview.

To apply a port firewall filter centrally from the RADIUS server:

Note

If port firewall filters are also configured locally for the interface, then the firewall filters configured by using VSAs take precedence if they conflict with the locally configured port firewall filters. If there is no conflict, they are merged.

  1. Create the firewall filter on the local switch. See Configuring Firewall Filters (CLI Procedure) for more information on configuring a port firewall filter.
  2. On the RADIUS server, open the users file to display the local user profiles of the end devices to which you want to apply the filter:
    [root@freeradius]#

    cat /usr/local/etc/raddb/usersvi users



  3. Apply the filter to each user profile by adding the Filter-ID attribute with the filter name as the attribute value:
    Filter-Id =filter-name

    For example, the user profile below for supplicant1 includes the Filter-ID attribute with the filter name filter1:

    [root@freeradius]# cat /usr/local/etc/raddb/users
    Note

    Multiple filters are not supported on a single interface. However, you can support multiple filters for multiple users that are connected to the switch on the same interface by configuring a single filter with policies for each of those users.

  4. Stop and restart the RADIUS process to activate the configuration.

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch

802.1X is the IEEE standard for port-based network access control (PNAC). You use 802.1X to control network access. Only users and devices providing credentials that have been verified against a user database are allowed access to the network. You can use a RADIUS server as the user database for 802.1X authentication, as well as for MAC RADIUS authentication.

This example describes how to connect a RADIUS server to an EX Series switch, and configure it for 802.1X:

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 9.0 or later for EX Series switches

  • One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

  • One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend database and contains credential information for hosts (supplicants) that have permission to connect to the network.

Before you connect the server to the switch, be sure you have:

Overview and Topology

The EX Series switch acts as an authenticator PAE. It blocks all traffic and acts as a control gate until the supplicant (client) is authenticated by the server. All other users and devices are denied access.

Figure 1 shows one EX4200 switch that is connected to the devices listed in Table 2.

Figure 1: Topology for Configuration
Topology for Configuration

Table 2: Components of the Topology

PropertySettings

Switch hardware

EX4200 access switch, 24 Gigabit Ethernet ports: 8 PoE ports (ge-0/0/0 through ge-0/0/7) and 16 non-PoE ports (ge-0/0/8 through ge-0/0/23)

VLAN name

default

One RADIUS server

Backend database with an address 10.0.0.100 connected to the switch at port ge-0/0/10

In this example, connect the RADIUS server to access port ge-0/0/10 on the EX4200 switch. The switch acts as the authenticator and forwards credentials from the supplicant to the user database on the RADIUS server. You must configure connectivity between the EX4200 and the RADIUS server by specifying the address of the server and configuring the secret password. This information is configured in an access profile on the switch.

Note

For more information about authentication, authorization, and accounting (AAA) services, see the Junos OS System Basics Configuration Guide.

Configuration

CLI Quick Configuration

To quickly connect the RADIUS server to the switch, copy the following commands and paste them into the switch terminal window:

[edit]


set access radius-server 10.0.0.100 secret juniper
set access radius-server 10.0.0.200 secret juniper
set access profile profile1 authentication-order radius
set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]

Step-by-Step Procedure

To connect the RADIUS server to the switch:

  1. Define the address of the servers, and configure the secret password. The secret password on the switch must match the secret password on the server:
    [edit]

    user@switch# set access radius-server 10.0.0.100 secret juniper
    user@switch# set access radius-server 10.0.0.200 secret juniper
  2. Configure the authentication order, making radius the first method of authentication:
    [edit]

    user@switch# set access profile profile1 authentication-order radius
  3. Configure a list of server IP addresses to be tried in sequential order to authenticate the supplicant:
    [edit]

    user@switch# set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]

Results

Display the results of the configuration:

Verification

To confirm that the configuration is working properly, perform these tasks:

Verify That the Switch and RADIUS Server Are Properly Connected

Purpose

Verify that the RADIUS server is connected to the switch on the specified port.

Action

Ping the RADIUS server to verify the connection between the switch and the server:

user@switch> ping 10.0.0.100

Meaning

ICMP echo request packets are sent from the switch to the target server at 10.0.0.100 to test whether the server is reachable across the IP network. ICMP echo responses are being returned from the server, verifying that the switch and the server are connected.

Understanding Dynamic Filters Based on RADIUS Attributes

You can use RADIUS server attributes to implement port firewall filters on a RADIUS authentication server. These filters can be dynamically applied to supplicants that request authentication through that server. RADIUS server attributes are clear-text fields encapsulated in Access-Accept messages sent from the authentication server to the switch when a supplicant connected to the switch is successfully authenticated. The switch, acting as the authenticator, uses the information in the RADIUS attributes to apply the related filters to the supplicant. Dynamic filters can be applied to multiple ports on the same switch, or to multiple switches that the use same authentication server, providing centralized access control for the network.

You can define firewall filters directly on the RADIUS server by using the Juniper-Switching-Filter attribute, which is a RADIUS attribute specific to Juniper Networks, also known as a vendor-specific attribute (VSA). VSAs are described in RFC 2138, Remote Authentication Dial In User Service (RADIUS). The Juniper-Switching-Filter VSA is listed under attribute ID number 48 in the Juniper dictionary on the RADIUS server, with the vendor ID set to the Juniper Networks ID number 2636. Using this attribute, you define filters on the authentication server, which are applied on all switches that authenticate supplicants through that server. This method eliminates the need to configure the same filters on multiple switches.

Alternatively, you can apply a port firewall filter to multiple ports on the same switch by using the Filter-ID attribute, which is RADIUS attribute ID number 11. To use the Filter-ID attribute, you must first configure a filter on the switch, and then add the filter name to user policies on the RADIUS server as the value of the Filter-ID attribute. When a supplicant defined in one of those policies is authenticated by the RADIUS server, the filter is applied to the switch port that has been authenticated for the supplicant. Use this method when the firewall filter has complex conditions, or if you want to use different conditions for the same filter on different switches. The filter named in the Filter-ID attribute must be configured locally on the switch at the [edit firewall family ethernet-switching filter] hierarchy level.

VSAs are supported only for 802.1X single supplicant configurations and multiple supplicant configurations.

Understanding Dynamic VLAN Assignment Using RADIUS Attributes

VLANs can be dynamically assigned by a RADIUS server to supplicants requesting 802.1X authentication through that server. You configure the VLAN on the RADIUS server using RADIUS server attributes, which are clear-text fields encapsulated in messages sent from the authentication server to the switch when a supplicant connected to the switch requests authentication. The switch, acting as the authenticator, uses the information in the RADIUS attributes to assign the VLAN to the supplicant. Based on the results of the authentication, a supplicant that began authentication in one VLAN might be assigned to another VLAN.

Successful authentication requires that the VLAN ID or VLAN name is configured on the switch acting as 802.1X authenticator, and that it matches the VLAN ID or VLAN name sent by the RADIUS server during authentication. If neither exists, the end device is not authenticated. If a guest VLAN is established, the unauthenticated end device is automatically moved to the guest VLAN.

The RADIUS server attributes used for dynamic VLAN assignment described in RFC 2868, RADIUS Attributes for Tunnel Protocol Support.

  • Tunnel-Type—Defined as RADIUS attribute type 64. The value should be set to VLAN.

  • Tunnel-Medium-Type—Defined as RADIUS attribute type 65. The value should be set to IEEE-802.

  • Tunnel-Private-Group-ID—Defined as RADIUS attribute type 81. The value should be set to the VLAN ID or the VLAN name.

For more information about configuring dynamic VLANs on your RADIUS server, see the documentation for your RADIUS server.

Understanding Guest VLANs for 802.1X on Switches

Guest VLANs can be configured on switches that are using 802.1X authentication to provide limited access—typically only to the Internet—for:

  • Corporate guests

  • End devices that are not 802.1X-enabled

  • Nonresponsive end devices when MAC RADIUS authentication has not been configured on the switch interfaces to which the hosts are connected

A guest VLAN is not used for supplicants that send incorrect credentials. Those supplicants are directed to the server-reject VLAN instead.

For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from which the non-802.1X-enabled end device can download the supplicant software and attempt authentication again.

A guest VLAN is not used when MAC RADIUS authentication has been configured on the switch interfaces to which the hosts are connected.

Example: Configuring 802.1X Authentication Options When the RADIUS Server Is Unavailable to an EX Series Switch

Server fail fallback enables you to specify how 802.1X supplicants connected to the switch are supported if the RADIUS authentication server becomes unavailable or sends a RADIUS access-reject message.

You use 802.1X to control network access. Only users and devices (supplicants) providing credentials that have been verified against a user database are allowed access to the network. You use a RADIUS server as the user database.

This example describes how to configure an interface to move a supplicant to a VLAN in the event of a RADIUS server timeout:

Requirements

This example uses the following software and hardware components:

Note

This example also applies to QFX5100 switches.

  • Junos OS Release 9.3 or later for EX Series switches

  • One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

  • One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend database and contains credential information for hosts (supplicants) that have permission to connect to the network.

Before you connect the server to the switch, be sure you have:

Overview and Topology

A RADIUS server timeout occurs if no authentication RADIUS servers are reachable when a supplicant logs in and attempts to access the LAN. Using server fail fallback, you configure alternative options for supplicants attempting LAN access. You can configure the switch to accept or deny access to supplicants or to maintain the access already granted to supplicants before the RADIUS server timeout. Additionally, you can configure the switch to move supplicants to a specific VLAN if a RADIUS timeout occurs or if the RADIUS server sends an EAP Access-Reject message.

Figure 2 shows the topology used for this example. The RADIUS server is connected to the EX4200 switch on access port ge-0/0/10. The switch acts as the authenticator port access entity (PAE) and forwards credentials from the supplicant to the user database on the RADIUS server. The switch blocks all traffic and acts as a control gate until the supplicant is authenticated by the authentication server. A supplicant is connected to the switch through interface ge-0/0/1.

Note

This figure also applies to QFX5100 switches.

Figure 2: Topology for Configuring 802.1X Options
Topology for Configuring
802.1X Options

Table 3 describes the components in this topology.

Table 3: Components of the Topology

PropertySettings

Switch hardware

EX4200 access switch, 24 Gigabit Ethernet ports: 16 non-PoE ports and 8 PoE ports.

VLAN names

default VLAN

vlan-sf VLAN

Supplicant

Supplicant attempting access on interface ge-0/0/1

One RADIUS server

Backend database with an address of 10.0.0.100 connected to the switch at port ge-0/0/10

In this example, configure interface ge-0/0/1 to move a supplicant attempting access to the LAN during a RADIUS timeout to another VLAN. A RADIUS timeout prevents the normal exchange of EAP messages that carry information from the RADIUS server to the switch and permit the authentication of a supplicant. The default VLAN is configured on interface ge-0/0/1. When a RADIUS timeout occurs, supplicants on the interface will be moved from the default VLAN to the VLAN named vlan-sf.

Configuration

CLI Quick Configuration

To quickly configure server fail fallback on the switch, copy the following commands and paste them into the switch terminal window:

[edit protocols dot1x authenticator]


set interface ge-0/0/1 server-fail vlan-name vlan-sf

Step-by-Step Procedure

To configure an interface to divert supplicants to a specific VLAN when a RADIUS timeout occurs (here, the VLAN is vlan-sf):

  1. Define the VLAN to which supplicants are diverted:
    [edit protocols dot1x authenticator]

    user@switch# set interface ge-0/0/1 server-fail vlan-name vlan-sf

Results

Display the results of the configuration:

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying That the Supplicants Are Moved to an Alternative VLAN During a RADIUS Timeout

Purpose

Verify that the interface moves supplicants to an alternative VLAN during a RADIUS timeout.

Note

On switches running Junos OS for EX Series with support for ELS, the output for the show vlans command will contain additional information. If your switch runs software that supports ELS, see show vlans. For ELS details, see Using the Enhanced Layer 2 Software CLI

Action

Display the VLANs configured on the switch; the interface ge-0/0/1.0 is a member of the default VLAN:

user@switch> show vlans

Display 802.1X protocol information on the switch to view supplicants that are authenticated on interface ge-0/0/1.0:

user@switch> show dot1x interface brief

A RADIUS server timeout occurs. Display the Ethernet switching table to show that the supplicant with the MAC address 00:00:00:00:00:01 previously accessing the LAN through the default VLAN is now being learned on the VLAN named vlan-sf:

user@switch> show ethernet-switching table

Display 802.1X protocol information to show that interface ge-0/0/1.0 is connecting and will open LAN access to supplicants:

user@switch> show dot1x interface brief

Meaning

The show vlans command displays interface ge-0/0/1.0 as a member of the default VLAN. The show dot1x interface brief command shows that a supplicant (abc) is authenticated on interface ge-0/0/1.0 and has the MAC address 00:00:00:00:00:01. A RADIUS server timeout occurs, and the authentication server cannot be reached by the switch. The show-ethernet-switching table command shows that MAC address 00:00:00:00:00:01 is learned on VLAN vlan-sf. The supplicant has been moved from the default VLAN to the vlan-sf VLAN. The supplicant is then connected to the LAN through the VLAN named vlan-sf.

Example: Configuring Fallback Options on EX Series Switches for EAP-TTLS Authentication and Odyssey Access Clients

For 802.1X user authentication, EX Series switches support RADIUS authentication servers that are using Extensible Authentication Protocol–Tunneled TLS (EAP-TTLS) to authenticate Odyssey Access Client (OAC) supplicants. OAC networking software runs on endpoint computers (desktop, laptop, or notepad computers and supported wireless devices) and provides secure access to both wired and wireless networks.

This example describes how to configure an 802.1X-enabled interface on the switch to provide fallback support for OAC users who have entered incorrect login credentials:

Requirements

This example uses the following software and hardware components:

Note

This example also applies to QFX5100 switches.

  • Junos OS Release 11.2 or later for EX Series switches

  • One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

  • One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend database and contains credential information for hosts (supplicants) that have permission to connect to the network.

  • One OAC end device acting as a supplicant.

Before you begin configuring the fallback option, ensure that you have:

Overview and Topology

OAC is networking software that runs on endpoint computers (desktop, laptop, or notepad) and supported wireless devices. OAC provides full support for EAP, which is required for secure wireless LAN access.

In this topology, OAC is deployed with an 802.1X-enabled switch and a RADIUS server. The switch functions as an enforcement point in the network security architecture. This topology:

  • Ensures that only authorized users can connect.

  • Maintains privacy of login credentials.

  • Maintains data privacy over the wireless link.

This example includes the configuration of a server-reject VLAN on the switch, which can be used to prevent accidental lockout for users who have entered incorrect login credentials. These users can be given limited LAN access.

However, this fallback configuration is complicated by the fact that the OAC supplicant and RADIUS server are using EAP-TTLS. EAP-TTLS creates a secure encrypted tunnel between the server and the end device to complete the authentication process. When the user enters incorrect login credentials, the RADIUS server sends EAP failure messages directly to the client through this tunnel. The EAP failure message causes the client to restart the authentication procedure, so that the switch’s 802.1X authentication process tears down the session that was established with the switch using the server-reject VLAN. You can enable the remedial connection to continue by configuring:

  • eapol-block—Enable the EAPoL block timer on the 802.1X interface that is configured to belong to the server-reject VLAN. The block timer causes the authentication port access entity to ignore EAP start messages from the client, attempting to restart the authentication procedure.

    Note

    The EAPoL block timer is triggered only after the configured number of allowed reattempts (using the retries option) on the 802.1X interface have been exhausted. You can configure retries to specify the number of times the switch attempts to authenticate the port after an initial failure. The default is three retries.

  • block-interval—Configure the amount of time that you want the EAPoL block timer to continue to ignore EAP start messages. If you do not configure the block interval, the EAPoL block timer defaults to 120 seconds.

When the 802.1X interface ignores the EAP start messages from the client, the switch allows the existing remedial session that was established through the server-reject VLAN to remain open.

These configuration options apply to single, single-secure, and multiple supplicant authentication modes. In this example, the 802.1X interface is configured in single supplicant mode.

Figure 3 shows an EX Series switch connecting an OAC end device to a RADIUS server, and indicates the protocols being used to connect the network entities.

Note

This figure also applies to QFX5100 switches.

Figure 3: EX Series Switch Connecting OAC to RADIUS Server Using EAP-TTLS Authentication
EX Series Switch Connecting
OAC to RADIUS Server Using EAP-TTLS Authentication

Table 4 describes the components in this OAC deployment:.

Table 4: Components of the OAC Deployment

PropertySettings

Switch hardware

EX Series switch

VLANs

default

server-reject-vlan: VLAN name is remedial and VLAN ID is 700

802.1X interface

ge-0/0/8

OAC supplicant

EAP-TTLS

One RADIUS authentication server

EAP-TTLS

Configuration

CLI Quick Configuration

To quickly configure the fallback options for EAP-TTLS and OAC supplicants, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans remedial vlan-id 700

set protocols dot1x authenticator interface ge-0/0/8 retries 4

set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan remedial

set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan eapol-block

set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan block-interval 130

Step-by-Step Procedure

To configure the fallback options for EAP-TTLS and OAC supplicants:

Tip

In this example, the switch has only one server-reject VLAN. Therefore, the configuration specifies eapol-block and block-interval directly after server-reject-vlan. However, if you have configured multiple VLANs on the switch, you must include the VLAN name or VLAN ID directly after server-reject-vlan to indicate which VLAN is being modified.

  1. Configure a VLAN that will function as the server-reject VLAN to provide limited LAN access for users who have entered incorrect login credentials:
    [edit]

    user@switch# set vlans remedial vlan-id 700
  2. Configure the number of times for the client to be prompted for username and password before an incorrect login is directed to the server-reject VLAN:
    [edit protocols dot1x authenticator interface ge-0/0/8]

    user@switch# set retries 4
  3. Configure the 802.1X authenticator interface to use the server-reject VLAN as a fallback for incorrect logins:
    [edit protocols dot1x authenticator interface ge-0/0/8]

    user@switch# set server-reject-vlan remedial
  4. Enable the EAPoL block timer on the 802.1X interface that is configured to belong to the server-reject VLAN.
    [edit protocols dot1x authenticator interface ge-0/0/8]

    user@switch# set server-reject-vlan eapol-block
  5. Configure the amount of time for the EAPoL block to remain in effect:
    [edit protocols dot1x authenticator interface ge-0/0/8]

    user@switch# set server-reject-vlan block-interval 130

Results

Check the results of the configuration:

Verification

To confirm that the configuration and the fallback options are working correctly, perform this task:

Verifying the Configuration of the 802.1X Interface

Purpose

Verify that the 802.1X interface is configured with the desired options.

Action

user@switch> show dot1x interface ge-0/0/8.0 detail

Meaning

The show dot1x ge-0/0/8 detail command output shows that the ge-0/0/8 interface is in the Authenticated state and that it is using the remedial VLAN.

Monitoring 802.1X Authentication

Purpose

Note

This topic applies only to the J-Web Application package.

J-Web Application package Release 14.1X53-A2 does not support 802.1X authentication on EX4600 switches.

Use the monitoring feature to display details of authenticated users and users that failed authentication.

Action

To display authentication details in the J-Web interface, select Monitoring > Security > 802.1X.

To display authentication details in the CLI, enter the following commands:

  • show dot1x interface detail | display xml

  • show dot1x interface detail <interface> | display xml

  • show dot1x auth-failed-users

Meaning

The details displayed include:

  • A list of authenticated users.

  • The number of connected users.

  • A list of users that failed authentication.

You can also specify an interface for which the details must be displayed.

Verifying 802.1X Authentication

Purpose

Verify that supplicants are being authenticated on an interface on a switch with the interface configured for 802.1X authentication, and display the method of authentication being used.

Action

Display detailed information about an interface configured for 802.1X (here, the interface is ge-0/0/16):

user@switch> show dot1x interface ge-0/0/16.0 detail

Meaning

The sample output from the show dot1x interface detail command shows that the Number of connected supplicants is 1. The supplicant that was authenticated and is now connected to the LAN is known as user5 on the RADIUS server and has the MAC address 00:30:48:8C:66:BD. The supplicant was authenticated by means of the 802.1X authentication method called RADIUS authentication, as indicated by Radius in the output. When RADIUS authentication is used, the supplicant is configured on the RADIUS server, the RADIUS server communicates this to the switch, and the switch opens LAN access on the interface to which the supplicant is connected. The sample output also shows that the supplicant is connected to VLAN v200.

Other 802.1X authentication methods supported on EX Series switches in addition to RADIUS authentication are:

  • Guest VLAN—A nonresponsive host is granted Guest-VLAN access.

  • MAC Radius—A nonresponsive host is authenticated based on its MAC address. The MAC address is configured as permitted on the RADIUS server, the RADIUS server notifies the switch that the MAC address is a permitted address, and the switch grants LAN access to the nonresponsive host on the interface to which it is connected.

  • Server-fail deny—If the RADIUS servers time out, all supplicants are denied access to the LAN, preventing traffic from the supplicant from traversing through the interface. This is the default.

  • Server-fail permit—When the RADIUS server is unavailable, a supplicant is still permitted access to the LAN as if the supplicant were successfully authenticated by the RADIUS server.

  • Server-fail use-cache—If the RADIUS servers time out during reauthentication, previously authenticated supplicants are granted LAN access, but new supplicants are denied LAN access.

  • Server-fail VLAN—A supplicant is configured to be moved to a specified VLAN if the RADIUS server is unavailable to reauthenticate the supplicant. (The VLAN must already exist on the switch.)

Troubleshooting Authentication of End Devices on EX Series Switches

Problem

Description: End devices configured using static MAC addresses lose connection to the switch after the clear dot1x interface command is run to clear all learned MAC addresses.

Before clearing MAC addresses:

To clear MAC addresses:

After clearing MAC addresses:

Note that there are no end devices on the authentication bypass list.

Cause

Static MAC addresses are treated the same as other learned MAC addresses on an interface. When the clear dot1x interface command is run, it clears all learned MAC addresses from the interface, including the static MAC bypass list (also known as the exclusion list).

Solution

If you run the clear dot1x interfaces command for an interface that has static MAC addresses configured for authentication bypass, re-add the static MAC addresses to the static MAC bypass list.

Release History Table
Release
Description
Starting in Junos OS Release 18.3R1, you can configure 802.1X authentication on trunk interfaces, which allows the network access device (NAS) to authenticate an access point (AP) or another connected Layer 2 device.
Starting in Junos OS Release 17.3, the port bounce feature can be used to force the end device to initiate DHCP re-negotiation by causing a link flap on the authenticated port.
J-Web Application package Release 14.1X53-A2 does not support 802.1X authentication on EX4600 switches.