radius server dynamic vlan assignment

• Skip to content
• Skip to search
• Skip to footer

Configure a RADIUS Server and WLC for Dynamic VLAN Assignment

Available languages, download options.

• PDF (906.6 KB) View with Adobe Reader on a variety of devices

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document introduces the concept of dynamic VLAN assignment. The document describes how to configure the wireless LAN controller (WLC) and a RADIUS server to assign wireless LAN (WLAN) clients into a specific VLAN dynamically.

Prerequisites

Requirements.

Ensure that you meet these requirements before you attempt this configuration:

Have basic knowledge of the WLC and Lightweight Access Points (LAPs)

Have functional knowledge of the AAA server

Have thorough knowledge of wireless networks and wireless security issues

Have basic knowledge of Lightweight AP Protocol (LWAPP)

Components Used

The information in this document is based on these software and hardware versions:

Cisco 4400 WLC that runs firmware release 5.2

Cisco 1130 Series LAP

Cisco 802.11a/b/g Wireless Client Adapter that runs firmware release 4.4

Cisco Aironet Desktop Utility (ADU) that runs version 4.4

CiscoSecure Access Control Server (ACS) that runs version 4.1

Cisco 2950 series switch

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Dynamic VLAN Assignment with RADIUS Server

In most WLAN systems, each WLAN has a static policy that applies to all clients associated with a Service Set Identifier (SSID), or WLAN in the controller terminology. Although powerful, this method has limitations because it requires clients to associate with different SSIDs in order to inherit different QoS and security policies.

However, the Cisco WLAN solution supports identity networking. This allows the network to advertise a single SSID, but allows specific users to inherit different QoS or security policies based on the user credential.

Dynamic VLAN assignment is one such feature that places a wireless user into a specific VLAN based on the credentials supplied by the user. This task of assigning users to a specific VLAN is handled by a RADIUS authentication server, such as CiscoSecure ACS. This can be used, for example, to allow the wireless host to remain on the same VLAN as it moves within a campus network.

Therefore, when a client attempts to associate to a LAP registered with a controller, the LAP passes the credentials of the user to the RADIUS server for validation. Once the authentication is successful, the RADIUS server passes certain Internet Engineering Task Force (IETF) attributes to the user. These RADIUS attributes decide the VLAN ID that should be assigned to the wireless client. The SSID (WLAN, in terms of WLC) of the client does not matter because the user is always assigned to this predetermined VLAN ID.

The RADIUS user attributes used for the VLAN ID assignment are:

IETF 64 (Tunnel Type)—Set this to VLAN.

IETF 65 (Tunnel Medium Type)—Set this to 802

IETF 81 (Tunnel Private Group ID)—Set this to VLAN ID.

In this section, you are presented with the information to configure the features described in this document.

Network Diagram

This document uses this network setup:

These are the configuration details of the components used in this diagram:

The IP address of the ACS (RADIUS) server is 172.16.1.1.

The Management Interface address of the WLC is 172.16.1.30.

The AP-Manager Interface address of the WLC is 172.16.1.31.

The DHCP server address 172.16.1.1 is used to assign IP addresses to the LWAPP. The internal DHCP server on the controller is used to assign the IP address to wireless clients.

VLAN10 and VLAN11 are used throughout this configuration. The user1 is configured to be placed into the VLAN10 and user2 is configured to be placed into VLAN11 by the RADIUS server.

Note:  This document only shows all the configuration information related to user1. Complete the same procedure explained in this document for the user2.

This document uses 802.1x with LEAP as the security mechanism.

Note:  Cisco recommends that you use advanced authentication methods, such as EAP-FAST and EAP-TLS authentication, in order to secure the WLAN. This document uses LEAP only for simplicity.

Configuration

Prior to the configuration, this document assumes that the LAP is already registered with the WLC. Refer to Wireless LAN Controller and Lightweight Access Point Basic Configuration Example for more information. Refer to Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC) for information about the registration procedure involved.

Configuration Steps

This configuration is separated into three categories:

RADIUS Server Configuration

Configure the switch for multiple vlans, wlc configuration, wireless client utility configuration.

This configuration requires these steps:

Configure the WLC as an AAA Client on the RADIUS Server

Configure the Users and the RADIUS (IETF) Attributes Used for Dynamic VLAN Assignment on the RADIUS Server

Configure the aaa client for the wlc on the radius server.

This procedure explains how to add the WLC as a AAA client on the RADIUS server so that the WLC can pass the user credentials to the RADIUS server.

Complete these steps:

From the ACS GUI, click Network Configuration .

Click the Add Entry section under the AAA Clients field.

Enter the AAA Client IP Address and Key.

The IP address should be the Management Interface IP address of the WLC.

Make sure that the key you enter is the same as the one configured on the WLC under the Security window. This is the secret key used for communication between the AAA client (WLC) and the RADIUS server.

Choose RADIUS (Cisco Airespace) from the Authenticate Using field for the authentication type.

This procedure explains how to configure the users in the RADIUS server and the RADIUS (IETF) attributes used to assign VLAN IDs to these users.

From the ACS GUI, click User Setup .

In the User Setup window, enter a username in the User field and click Add/Edit .

On the Edit page, enter the necessary user information as shown here:

In this diagram, notice that the password you provide under the User Setup section should be the same as the one provided at the client side during the user authentication.

Scroll down the Edit page and find the IETF RADIUS Attributes field.

In the IETF RADIUS Attributes field, check the check boxes next to the three Tunnel attributes and configure the attribute values as shown here:

Note:  In the initial configuration of the ACS server, IETF RADIUS attributes might not be displayed.

Choose Interface Configuration > RADIUS (IETF) in order to enable IETF attributes in the user configuration window.

Then, check the check boxes for attributes 64, 65, and 81 in the User and Group columns.

Note:  In order for the RADIUS server to dynamically assign the client to a specific VLAN, it is required that the VLAN-ID configured under the IETF 81 (Tunnel-Private-Group-ID) field of the RADIUS server exist on the WLC.

Check the Per User TACACS+/RADIUS attribute check box under Interface Configuration > Advanced Options in order to enable the RADIUS server for per user configurations.

Also, because LEAP is used as the Authentication protocol, ensure that LEAP is enabled in the System Configuration window of the RADIUS server as shown here:

Configure the ACS with Cisco Airespace VSA Attributes for Dynamic VLAN Assignment

In the latest ACS versions, you can also configure the Cisco Airespace [VSA (Vendor-Specific)] attribute to assign a successfully authenticated user with a VLAN interface name (not the VLAN ID) as per the user configuration on the ACS. In order to accomplish this, perform the steps in this section.

Note:  This section uses ACS 4.1 version to configure the Cisco Airespace VSA attribute.

Configure the ACS Group with Cisco Airespace VSA Attribute Option

From the ACS 4.1 GUI, click Interface Configuration from the navigation bar. Then, select RADIUS (Cisco Airespace) from the Interface Configuration page in order to configure the Cisco Airespace attribute option.

From the RADIUS (Cisco Airespace) window, check the User check box (Group check box if needed) next to Aire-Interface-Name in order to display it on the User Edit page. Then, click Submit .

Go to the user1's Edit page.

From the User Edit page, scroll down to the Cisco Airespace RADIUS Attributes section. Check the check box next to the Aire-Interface-Name attribute and specify the name of the dynamic interface to be assigned upon successful user authentication.

This example assigns the user to admin VLAN.

Click Submit .

In order to allow multiple VLANs through the switch, you need to issue these commands to configure the switch port connected to the controller:

Switch(config-if)# switchport mode trunk

Switch(config-if)# switchport trunk encapsulation dot1q

Note:  By default, most of the switches allow all VLANs created on that switch via the trunk port.

These commands vary for a Catalyst operating system (CatOS) switch.

If a wired network is connected to the switch, then this same configuration can be applied to the switch port that connects to the wired network. This enables the communication between the same VLANs in the wired and wireless network.

Note:  This document does not discuss inter-VLAN communication. This is beyond the scope of this document. You must understand that for inter-VLAN routing, a Layer 3 switch or an external router with proper VLAN and trunking configurations is needed. There are several documents that explain inter-VLAN routing configuration.

Configure the WLC with the Details of the Authentication Server

Configure the dynamic interfaces (vlans), configure the wlans (ssid).

It is necessary to configure the WLC so it can communicate with the RADIUS server to authenticate the clients, and also for any other transactions.

From the controller GUI, click Security .

Enter the IP address of the RADIUS server and the Shared Secret key used between the RADIUS server and the WLC.

This Shared Secret key should be the same as the one configured in the RADIUS server under Network Configuration > AAA Clients > Add Entry. Here is an example window from the WLC:

This procedure explains how to configure dynamic interfaces on the WLC. As explained earlier in this document, the VLAN ID specified under the Tunnel-Private-Group ID attribute of the RADIUS server must also exist in the WLC.

In the example, the user1 is specified with the Tunnel-Private-Group ID of 10 (VLAN =10) on the RADIUS server. See the IETF RADIUS Attributes section of the user1 User Setup window.

You can see the same dynamic interface (VLAN=10) configured in the WLC in this example. From the controller GUI, under the Controller > Interfaces window, the dynamic interface is configured.

Click Apply on this window.

This takes you to the Edit window of this dynamic interface (VLAN 10 here).

Enter the IP Address and default Gateway of this dynamic interface.

Note:  Because this document uses an internal DHCP server on the controller, the primary DHCP server field of this window points to the Management Interface of the WLC itself. You can also use an external DHCP server, a router, or the RADIUS server itself as a DHCP server to the wireless clients. In such cases, the primary DHCP server field points to the IP address of that device used as the DHCP server. Refer to your DHCP server documentation for more information.

Click Apply .

Now you are configured with a dynamic interface in your WLC. Similarly, you can configure several dynamic interfaces in your WLC. However, remember that the same VLAN ID must also exist in the RADIUS server for that particular VLAN to be assigned to the client.

This procedure explains how to configure the WLANs in the WLC.

From the controller GUI, choose WLANs > New in order to create a new WLAN.

The New WLANs window is displayed.

Enter the WLAN ID and WLAN SSID information.

You can enter any name to be the WLAN SSID. This example uses VLAN10 as the WLAN SSID.

Click Apply in order to go to the Edit window of the WLAN SSID10.

Normally, in a wireless LAN controller, each WLAN is mapped to a specific VLAN (SSID) so that a particular user that belongs to that WLAN is put into the specific VLAN mapped. This mapping is normally done under the Interface Name field of the WLAN SSID window.

In the example provided, it is the job of the RADIUS server to assign a wireless client to a specific VLAN upon successful authentication. The WLANs need not be mapped to a specific dynamic interface on the WLC. Or, even though the WLAN to dynamic interface mapping is done on the WLC, the RADIUS server overrides this mapping and assigns the user that comes through that WLAN to the VLAN specified under the user Tunnel-Group-Private-ID field in the RADIUS server.

Check the Allow AAA Override check box in order to override the WLC configurations by the RADIUS server.

Enable the Allow AAA Override in the controller for each WLAN (SSID) configured.

When AAA Override is enabled, and a client has AAA and controller WLAN authentication parameters that conflict, client authentication is performed by the AAA (RADIUS) server. As part of this authentication, the operating system moves clients to a VLAN returned by the AAA server. This is predefined in the controller interface configuration.

For instance, if the corporate WLAN primarily uses a Management Interface assigned to VLAN 2, and if the AAA Override returns a redirect to VLAN 100, the operating system redirects all client transmissions to VLAN 100 even if the physical port to which VLAN 100 is assigned. When AAA Override is disabled, all client authentication defaults to the controller authentication parameter settings, and authentication is only performed by the AAA server if the controller WLAN does not contain any client-specific authentication parameters.

This document uses ADU as the client utility for the configuration of the user profiles. This configuration also uses LEAP as the authentication protocol. Configure the ADU as shown in the example in this section.

From the ADU Menu bar, choose Profile Management > New in order to create a new profile.

The example client is configured to be a part of SSID VLAN10. These diagrams show how to configure a user profile on a client:

Activate the user profile you have configured in the ADU. Based on the configuration, you are prompted for a username and password. You can also instruct the ADU to use the Windows username and password for authentication. There are a number of options from which the client can receive authentication. You can configure these options under the Security > Configure tab of the user profile you have created.

In the previous example, notice that user1 is assigned to the VLAN10 as specified in the RADIUS server.

This example uses this username and password from the client side to receive authentication and to be assigned to a VLAN by the RADIUS server:

User Name = user1

Password = user1

This example shows how the SSID VLAN10 is prompted for the username and password. The username and password are entered in this example:

Once the authentication and the corresponding validation is successful, you receive success as the status message.

Then, you need to verify that your client is assigned to the proper VLAN as per the RADIUS attributes sent. Complete these steps in order to accomplish this:

From the controller GUI, choose Wireless > AP .

Click Clients , which appears on the left corner of the Access Points (APs) window.

The client statistics are displayed.

Click Details in order to identify the complete details of the client, such as IP address, the VLAN to which it is assigned, and so forth.

This example displays these details of the client, user1:

From this window, you can observe that this client is assigned to VLAN10 as per the RADIUS attributes configured on the RADIUS server.

Note:  If the dynamic VLAN assignment is based on the Cisco Airespace VSA Attribute setting, the Interface name will display it as admin as per this example on the client details page.

Use this section to confirm that your configuration works properly.

debug aaa events enable —This command can be used to ensure successful transfer of the RADIUS attributes to the client via the controller. This portion of the debug output ensures a successful transmission of RADIUS attributes:

Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[0]: attribute 64, vendorId 0, valueLen 4 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[1]: attribute 65, vendorId 0, valueLen 4 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[2]: attribute 81, vendorId 0, valueLen 3 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[3]: attribute 79, vendorId 0, valueLen 32 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Received EAP Attribute (code=2, length=32,id=0) for mobile 00:40:96:ac:e6:57 Fri Jan 20 02:25:08 2006: 00000000: 02 00 00 20 11 01 00 18 4a 27 65 69 6d e4 05 f5 ........J'eim...00000010: d0 98 0c cb 1a 0c 8a 3c ........44 a9 da 6c 36 94 0a f3 <D..l6... Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[4]: attribute 1, vendorId 9, valueLen 16 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[5]: attribute 25, vendorId 0, valueLen 28 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[6]: attribute 80, vendorId 0, valueLen 16 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Tunnel-Type 16777229 should be 13 for STA 00:40:96:ac:e6:57 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Tunnel-Medium-Type 16777222 should be 6 for STA 00:40:96:ac:e6:57 Fri Jan 20 02:30:00 2006: 00:40:96:ac:e6:57 Station 00:40:96:ac:e6:57 setting dot1x reauth timeout = 1800

These commands can also be useful:

debug dot1x aaa enable

debug aaa packets enable

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Note:  Dynamic VLAN assignment does not work for web authentication from a WLC.

Related Information

• EAP Authentication with RADIUS Server
• Cisco Wireless LAN Controller Configuration Guide, Release 4.0
• Technical Support & Documentation - Cisco Systems

Revision History

Was this document helpful.

Contact Cisco

• (Requires a Cisco Service Contract )

This Document Applies to These Products

• Aironet Wireless LAN Client Adapters

Networking | Cloud | DevOps | IaC

IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server is an important element to networking in the real world. User location cannot be predicted as they may be at and out of a desk and up and about should they need to do so. Tying them to a local VLAN may only be helpful if they are bound to desks in those locations, although the most ideal outcome, it is not the most practical.

It is only wise to incorporate IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server in areas where you expect different teams to come to. Meeting rooms could for a moment have the accounting group or the development group meeting there and based on the intelligent and dynamic vlan assignmnet with 802.1x authentication, users port-access are defined their appropriate vlans for their respective access to resources on the network.

How to Provision 802.1 X Authentication Step By Step With Dynamic VLAN Assignment With Windows Radius Server For 802.1x Clients.

A typical configuration for a system under IEEE 802.1x Authentication control is shown in the following figure.

In this scenario, “Lady Smith” wishes to use services offered by servers on the LAN behind the switch. There are multiple VLANs with resources available based on user vlan membership. Her laptop computer is connected to a port on the Aruba 2920 Edge Switch that has 802.1x port authentication control enabled.

The laptop computer must therefore act in a supplicant role. Message exchanges take place between the supplicant and the authenticator which is the Aruba 2920 Switch, and the authenticator passes the supplicant’s credentials which is her (Windows Active Directory User Account Credentials) to the authentication server for verification. The NPS Server which is the authentication server then informs the authenticator whether or not the authentication attempt succeeded, at which point “Lady Smith” is either granted or denied access to the LAN behind the switch.

Setup Structure for IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

• Supplicant: Laptop running Microsoft Windows 10 or Windows 7
• Authenticator: HP Aruba 2920 Edge Switch
• Authentication Server: Microsoft NPS (Network Policy Server) running on Windows Server 2012 R2.
• User Database : Active Directory

For Windows Infrastructure

Create NPS Server – Add Role on Windows Server 2012 R2

• Create DHCP Scopes for VLANS

Create RADIUS Client on NAC using Network Policy Server

• Create Network Policies
• Configure a Network Policy for VLANs
• Start Wired Auto-Config Service
• Enable Network Authentication

Create the DHCP Scopes for VLAN100 and VLAN200 Groups

• Development Group Scope – VLAN 100

SVI: ip address 172.16.80.254 255.255.255.0 Scope Subnet: 172.16.80.1/24

• Accounting Group Scope – VLAN 200

SVI:ip address 172.16.70.254 255.255.255.0 Scope Subnet: 172.16.70.0/24

Secret Key: secret12

Add Edge Switch Management IP as the RADIUS Client

The Shared Secret Key: secret12 will be used in the Switch Configuration.

Create Network Policy Settings for Accounting Group for VLAN 200

Configuration Example

Here’s an example of how you might consider when configuring Microsoft NPS Server to assign users to a VLAN based on their user group, using NPS for the authentication and authorization of users. This configuration has worked flawlessly on the HP Aruba 2920 Switch. The key to getting this to work is the use of a RADIUS element called: ‘Tunnel-PVT-Group-ID’. This is a RADIUS attribute that may be passed back to the authenticator (i.e. the Aruba 2920 Switch) by the authentication server (i.e. Microsoft NPS Server) when a successful authentication has been achieved. There are a few other elements which need to accompany it, but this is the key element, as it specifies the VLAN number that the user should be assigned to.

The other elements that need to be returned by the NPS Server are as follows:

• Tunnel-PVT-Group-ID: 200
• Service-Type: Framed
• Tunnel-Type: VLAN
• Tunnel-Medium-Type: 802

For Client Infrastructure

On the Supplicant, Windows 7 or 10 configure the following steps on the Ethernet Adapter to enable IEEE 802.1X Authentication

For Network Infrastructure

Connect Server Infrastructure to VLAN 400

Create VLAN for Accounting Group

Create VLAN for Development Group

Create AAA Configuration on Switch for Radius Authentication

Download the Switch Configuration:

Test the IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

Verify Port-Access with the following user groups – VLAN 100 and VLAN 200

Think of what other clever things you can do from the information below;

Breakdown of Commands for RADIUS Authentication

Verification Commands

Thanks for reading. Please share your thoughts in the comment box below;

Published in Configuring , Design , Installing and Configuring , Networking , Security and Switching

• 802.1 x authentication step by step aruba
• 802.1 x authentication step by step cisco
• 802.1 x wireless authentication step by step
• 802.1x authentication process
• 802.1x authentication windows 10
• 802.1x authentication windows server 2012
• 802.1x certificate authentication
• assignment wlc
• cisco dot1x
• cisco ise dynamic vlan
• cisco ise dynamic vlan assignment wlc
• cisco wireless radius attributes
• configuration example
• dynamic vlan assignment cisco 2960 dynamic vlan configuration in packet tracer
• dynamic vlan assignment with windows radius server
• dynamic vlan cisco
• dynamic vlan ruckus
• meraki dynamic vlan assignment
• nps mac authentication wired
• nps policy for mac-based authentication
• radius multiple vlans
• vlan radius server
• vlan steering
• vmps server

• PORTNOX CLOUD Unified Access Control Any Device. Any Data. Anywhere.

Zero Trust Network Access Control

• Cloud-native RADIUS Stand up Portnox’s cloud-native RADIUS is minutes.
• Passwordless authentication Leverage certificates for passwordless network authentication.
• Risk posture assessment Monitor the potential risk of every connected device.
• Compliance enforcement Automate device remediation & stay compliant 24/7.
• Explore Pricing

Zero Trust Conditional Access

• How does it work? Discover how to better secure your apps with Portnox.
• Passwordless authentication Bolster application access by going passwordless.
• 24/7 risk monitoring Ensure only trusted devices gain access to your apps.
• Automated remediation Automate device-based compliance enforcement.

Zero Trust Infrastructure Administration

• How does it work? Explore cloud-native TACACS+ from Portnox.
• Admin authentication Get started with simple, secure admin authentication.
• Access policy enforcement Make sure not just anyone can tinker with your infrastructure.
• Granular accounting Keep auditors at bay with cloud-native TACACS+.

Unified Zero Trust Security

• How does it work? Learn the ins and outs of the Portnox Cloud.
• Cloud-native RADIUS authentication Spin up our cloud-native RADIUS server in minutes.
• Passwordless application security Bolster application access by going passwordless.
• Zero trust network access control See and control access for every device across your network.
• Network device administration Keep auditors at bay with cloud-native TACACS+.

• Authentication
• Access Control
• Risk Monitoring
• Remediation
• IoT Security
• Guest Access

Applications

Infrastructure.

• Authorization

Integrations

• Case Studies
• Infographics
• Product Briefs
• White Papers
• Cloud Documentation

Compliance Center

Regulations, cybersecurity center.

• What is 802.1X? What are the benefits of NAC? How does zero trust work? Why go passwordless? What is IoT profiling? Explore All »
• Reseller Program
• Managed Services
• Become a Partner
• Register a Deal
• Get Started

Network Access Control , Network Security

Segmenting your network with dynamic vlan.

What is Dynamic VLAN?

VLANs (Virtual Local Area Networks) enable segmentation of the main organizational network. In practice, VLANs allow network administrators to keep devices and network resources separated despite being connected to the same physical network.

Dynamic VLAN assignment separates and isolates devices into different network segments based on the device or user authorization and their characteristics. The flow of traffic between those VLANs is governed by a firewall or another routing device which can then enforce specific network access rules.

Why Use Dynamic VLANs?

Segmenting the network is a security best practice, and in some cases is even a regulatory requirement – such as with PCI. Network segmentation is a measure that improves the effectiveness of all the current investments in other security tools, and can by itself help to prevent significant damage to critical organizational data across the network after a company has been breached.

Automating VLAN assignments and eliminating the need for manual intervention has historically been a challenge for network security teams. Today, automatic VLAN assignment is best implemented by the use of a RADIUS service, which functions as follows:

• A device connects to one of several the network access layers: wired ethernet switch or WiFi SSID
• The network access layer sends a request to the RADIUS server with the user’s credentials or certificates (using 802.1X)
• The RADIUS server sends a reply which contains attributes that provide the switch or access point with information on the device VLAN, result in properly VLAN assignment

Common Dynamic VLAN Assignment Use Cases

Network and security administrator most commonly encounter these use cases for dynamic VLAN assignment:

• The Sales & Marketing department does not need access to R&D resources, while R&D should not have access to the Finance Department resources. Using dynamic VLANs, each department will be placed in the correct VLAN with the required access.
• Devices that fail to authenticate due to wrong credentials or incorrect/expired certificate will be placed in a quarantine VLAN with internet access only.
• IP Phones using a dedicated voice VLAN and should be placed on that VLAN upon successful authentication.
• MAC bypass for devices that do not support 802.1X should be placed in their own dedicated VLAN.
• Devices that fail posture assessment (such as those without updated AntiVirus) should be placed in a quarantine VLAN with limited access.
• Employees connecting to one single WiFi SSID and get different access (VLANs) based on their authentication repository LDAP groups.

Dynamic VLAN Assignment with Portnox CLEAR

As mentioned earlier, the implementation of dynamic VLAN assignment has often been challenging for organizations since additional servers were needed on-site at the datacenter. This forced network teams to manage redundancies, complex configurations, and on-going maintenance.

To paint a clearer picture of this headache, consider this:

Take the case of connecting a new department, branch, or merely onboarding a lot of new employees at once…this can cause a surge in demand, which will in turn cause the whole network to “shutdown,” thus not accepting anyone who tries to connect.

Portnox CLEAR  is a network access control solution, deployed as a cloud service, that provides all the mentioned use cases and more. CLEAR simplifies the implementation process of dynamic VLAN assignment. CLEAR allows you to easily set-up a cloud RADIUS server in a single click, and integrate with various authentication repositories like on-premise Active Directory, Azure AD, GSuite, OKTA. Plus, you can enforce your own unique access control policy to dynamically assign users to their respective VLANs.

In addition to VLAN assignment based on credentials authorization, CLEAR also allows you to implement dynamic VLAN assignment based on risk violation. This means that even devices that have authenticated successfully to the wired or wireless network can be dynamically moved to a dedicated VLAN if they fall out of compliance.

In the diagram above:

• PCs are dynamically assigned to the VLAN based on their credentials/certificate.
• IP Phones are assigned to the VOIP VLAN.
• Printers are assigned to the printers VLAN.
• Guests devices assigned to the internet-only access/quarantine VLAN.

How it Works – Setting up Dynamic VLAN Assignment in Portnox CLEAR:

1. enable cloud radius.

In the CLEAR portal, create your one-click cloud RADIUS server: Go to  Settings > Services > CLEAR RADIUS Service , and add your RADIUS service instance:

And point your network equipment: wired switches and/or wireless controllers to work with these CLEAR Radius service details.

2. Creating an Access Control Policy – Dynamic VLAN Assignment:

In Policies > Access Control Policies , add or edit your existing access control policy, select the required access layer and add the correct VLAN ID or VLAN name for each event you want to create dynamic VLAN assignment for: successful authentication, authentication violation, risk assessment, blocked by admin. Then, map the access control policy to the relevant groups and users.

Related Reading

Understanding the Relationship Between Unified Access and Zero Trust

The Case for Cloud-Based: Evaluating Portnox Against Traditional On-Premises NAC Solutions

NAC’s Role in the Larger IAM Eco-System

Try portnox cloud for free today.

Gain access to all of Portnox's powerful zero trust access control free capabilities for 30 days!

Privacy Overview

WEBINAR 5/15 @ 12 PM EST: Deep Dive into Conditional Access

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment

Configuration Example Here’s an example of how to configure NPS to assign users to a VLAN based on their user group, using NPS for the authentication and authorization of users. The key to getting this to work is the use of a RADIUS element called: ‘Tunnel-PVT-Group-ID’.  This is a RADIUS attribute that may be passed back to the authenticator (i.e. the WLC or AP) by the authentication server (i.e.NPS) when a successful authentication has been achieved. There are a few other elements which need to accompany it, but this is the key element, as it specifies the VLAN number that the user should be assigned to. The other elements that need to be returned by NPS are:

• Service-Type: Framed
• Tunnel-Type: VLAN
• Tunnel-Medium-Type: 802
• Tunnel-PVT-Group-ID: <VLAN Number>

We’ll have  a look at how we specify each of these attributes in an NPS policy.  For our example, we’ll assign all ‘staff’ users to VLAN 10 and all ‘student’ users to VLAN 20.  Here is an overview of what the network might look like (this is obviously very simplified, but gives an overview of the type of thing that might be achieved):

VLAN 10 has an ACL (access control list) that allows users on this VLAN to access all systems across the school network. The ACL would generally be configured on the layer 3 switch or router that interconnects the school VLANs) VLAN 20 has an ACL which only allow access to the learning system VLAN and the Internet related services. By studying the example above, you can see that if we can control a users VLAN assignment, based on their AD group membership, we can ensure that they only receive the network access to which they are entitled (purely via their AD group membership). Also, note that this is all being done on a single SSID (“School” in this case). Now we’ll take a look at how we achieve this using NPS. NPS Configuration To configure NPS to provide the VLAN assignments outlined above, we will create 2 policies within NPS:

• School Wireless – Staff  (to assigned members of the staff AD group to VLAN 10)
• School Wireless – Students  (to assign members of the students AD group to VLAN 20)

The screen-shots below outline the configuration required. Here is the policy summary screen within NPS. Note that when configuring multiple policies, the order of the policies is important. Policies are assessed top-down, so make sure the policies that need to be hit are enabled and above any disabled polices.

Staff Policy 1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions (must be members of the staff group):

3. Select and configure an EAP type (note this may be PEAP or EAP-TLS – we’ve shown PEAP just as an example)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 10:

Students Policy 1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions: (must be members of the students group to match this policy)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 20:

Once NPS has been configured with policies similar to those shown above, users can be dynamically assigned to an appropriate VLAN based on their AD group membership.  As we’ve already discussed, this provides great benefits in reducing additional overheads associated with multiple SSIDs on a WiFi network. In addition, it simplifies user wireless management by allowing all users to be configured with a single wireless client profile, with their access being configured via Microsoft AD. One caveat to note when trying to use this technique is that all users must be using the same security mechanisms to join the SSID. For instance, all users must be using 802.1x (EAP) – you can’t have a mix of PSK & 802.1x authenticated devices on the same SSID. Generally, they should also be using the same WPA version (i.e. WPA or WPA2).

Related Articles

How to use openpath mobile pass (avigilon alta), integrate your existing network policy server (nps) infrastructure with azure ad multi-factor authentication, how to find out who the user profile disk belongs to terminal server rds, how to sign up and use chatgpt, sage 50 payroll – change database path, generate a report of all passwords for all cameras on your milestone xprotect vms., leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Power by IT Capture

You are using an outdated browser. Please upgrade your browser to improve your experience.

Your browser does not support JavaScript. Please turn it on for the best experience.

Configuration Guide on Dynamic VLAN with the VLAN Assignment function of RADIUS

OC200 , OC300 , Omada Software Controller , Omada Cloud-Based Controller

Recent updates may have expanded access to feature(s) discussed in this FAQ. Visit your product's support page, select the correct hardware version for your device and check either the Datasheet or the firmware section for the latest improvements added to your product.

With the VLAN Assignment feature of RADIUS, the Omada SDN solution can put clients authenticated by different accounts to the corresponding VLANs. In this way, clients will obtain IP addresses from different VLANs, and you don't have to create many SSIDs bound with different VLANs for wireless networks, or bind the PVIDs of the switch ports to specific VLANs for wired networks.

To achieve the above features, you will need the Omada SDN Controller, EAP for wireless assignment, JetStream Switch for wired assignment, and an external RADIUS server. In this article, we will share the configuration guide for below network topology.

Step 1. Set up the RADIUS server.

Here we run a FreeRADIUS ® server on a Linux server. For more information on installation and configuration, please refer to the official website: https://freeradius.org/

First, edit the “ clients.conf ” file, set the client IP address as “192.168.0.0/24” and the password as “tplink”.

Next, edit the “ users ” file, create two accounts “test10” and “test20” in VLAN10 and VLAN20, respectively.

You may also edit the “ eap.conf ” to modify the EAP type for WPA-Enterprise. After configuration, run the RADIUS server to listen for access requests.

Step 2. Create the RADIUS profile.

Go to Authentication --- RADIUS Profile, create a new profile bound with the RADIUS server, and check “Enable VLAN Assignment for Wireless Network” to assign VLANs for wireless clients.

Step 3. Create more VLAN for VLAN assignments.

Assuming all Omada devices have been adopted by the controller, go to Settings --- Wired Networks --- LAN, and create two interfaces with VLAN10 and VLAN20.

Step 4. VLAN assignment for wireless networks.

Go to Settings – Wireless Networks, and create a new SSID with WPA-Enterprise as below. For differences between WPA-Personal and WPA-Enterprise, please refer to FAQ500 .

When connecting your client to the SSID, you will be asked to choose the authentication type of WPA-Enterprise, and enter the account username and password. After successfully authenticating with account “test10”, the client will obtain an IP address from VLAN10, while with account “test20”, it will get that from VLAN20.

Step 5. VLAN assignment for wired networks.

Go to Authentication --- 802.1X and enable the feature, select Authentication Type as “Port Based”, enable “VLAN Assignment” and check the Ports to be authenticated according to your requirements.

Not to click the ports twice to enable MAB for them.

Then go to Wired Networks --- LAN --- Profile, create a new port profile, add VLAN10 and VLAN20 to untagged networks, and make sure the 802.1X Control mode is Auto.

Then Go to Devices, click your switch, go to Ports, check the authentication ports, and batch edit to change the port profile to the one created just now.

For 802.1X authentication, you may need to run TP-Link 802.1X Client Software (click here to download) for authentication. Please refer to FAQ787 and Step 3. For detailed guidance.

Is this faq useful?

Your feedback helps improve this site.

What’s your concern with this article?

• Dissatisfied with product
• Too Complicated
• Confusing Title
• Does not apply to me

We'd love to get your feedback, please let us know how we can improve this content.

We appreciate your feedback. Click here to contact TP-Link technical support.

Recommend Products

Omada Cloud-Based Controller

Omada Software Controller

Omada Hardware Controller

TP-Link Community

Still need help? Search for answers, ask questions, and get help from TP-Link experts and other users around the world.

Visit the Community >

We have updated our Policies. Read Privacy Policy and Terms of Use here. This website uses cookies to improve website navigation, analyze online activities and have the best possible user experience on our website. You can object to the use of cookies at any time. You can find more information in our privacy policy .

Basic Cookies

These cookies are necessary for the website to function and cannot be deactivated in your systems.

accepted_local_switcher, tp_privacy_base, tp_privacy_marketing, tp_smb-select-product_scence, tp_smb-select-product_scenceSimple, tp_smb-select-product_userChoice, tp_smb-select-product_userChoiceSimple, tp_smb-select-product_userInfo, tp_smb-select-product_userInfoSimple, tp_top-banner, tp_popup-bottom, tp_popup-center, tp_popup-right-middle, tp_popup-right-bottom, tp_productCategoryType

__livechat, __lc2_cid, __lc2_cst, __lc_cid, __lc_cst, CASID

id, VISITOR_INFO1_LIVE, LOGIN_INFO, SIDCC, SAPISID, APISID, SSID, SID, YSC, __Secure-1PSID, __Secure-1PAPISID, __Secure-1PSIDCC, __Secure-3PSID, __Secure-3PAPISID, __Secure-3PSIDCC, 1P_JAR, AEC, NID, OTZ

Analysis and Marketing Cookies

Analysis cookies enable us to analyze your activities on our website in order to improve and adapt the functionality of our website.

The marketing cookies can be set through our website by our advertising partners in order to create a profile of your interests and to show you relevant advertisements on other websites.

Google Analytics & Google Tag Manager

_gid, _ga_<container-id>, _ga, _gat_gtag_<container-id>

Google Ads & DoubleClick

test_cookie, _gcl_au

cebsp_, _ce.s, _ce.clock_data, _ce.clock_event, cebs

OptanonConsent, _sctr, _cs_s, _hjFirstSeen, _hjAbsoluteSessionInProgress, _hjSessionUser_14, _fbp, ajs_anonymous_id, _hjSessionUser_<hotjar-id>, _uetsid, _schn, _uetvid, NEXT_LOCALE, _hjSession_14, _hjid, _cs_c, _scid, _hjAbsoluteSessionInProgress, _cs_id, _gcl_au, _ga, _gid, _hjIncludedInPageviewSample, _hjSession_<hotjar-id>, _hjIncludedInSessionSample_<hotjar-id>

lidc, AnalyticsSyncHistory, UserMatchHistory, bcookie, li_sugr, ln_or

Dynamic VLAN Assignment for Cloud RADIUS

The landscape of cybersecurity is always changing, but there are a few constants. One unchanging aspect is the use of VLANs as a primary method of segmenting users and network resources. Like the Local Area Network it emulates, a VLAN is a useful tool for isolating sensitive resources and sheltering it from risk created by unnecessary access. 

Our networks are becoming increasingly virtual, as illustrated by the industry trend of moving to the cloud. That makes VLAN more important than ever and, fortunately, VLAN technology is keeping pace. In this article we will discuss the methods through which users are assigned to VLANs and how to automate the process for ease-of-use and increased security.

What is Dynamic VLAN Assignment?

Dynamic VLAN Assignment, also referred to as “ VLAN Steering ”, is exactly what it sounds like. The process of assigning users or groups of users to VLAN can be handled by a RADIUS at the time of authentication, though the infrastructure and expertise needed for dynamic VLAN assignment has historically been an obstacle for smaller organizations.

Why use Dynamic VLAN Assignment?

The default state of a wireless (or wired) network is sometimes described as “flat”. Every user in the organization is tossed into a shared network that also contains all of the resources that organization has (files, data, source code, applications, etc.). Everyone potentially has access to everything, even if there is another login portal between them and, say, the payroll system. 

That’s an unnecessary risk. Developers need access to very sensitive resources like the source code for their app, but that doesn’t imply that they require access to everything that is less confidential. It’s a basic tenet of security, cyber or not, to restrict access to only people that require it.

Those are the guiding principles that lead us to implement VLANs, but the “dynamic assignment” portion of dynamic VLAN assignment is equally important. There needs to be an automated process by which users are automatically shunted to the appropriate VLAN. Relying on IT to manually assign VLANs is short-sighted – humans are fallible and it doesn’t scale past a couple dozen users.

RADIUS Attributes for Dynamic VLAN Assignment

That’s why we configure a RADIUS server to assign users for us. It already has the responsibility of authorizing and authenticating users for network access, so it’s a relatively simple task to configure it to send users to a switch that can further sort users to a specific access point and/or a specific VLAN. 

How does a RADIUS decide where to send the user? By the attributes assigned to them. Attributes are often stored as part of the user profile in the directory or as a part of the device/client profile for MAC authentication. SecureW2’s Cloud PKI can even amend attributes to digital certificates for seamless certificate-based EAP-TLS authentication with dynamic VLAN assignment.

The majority of VLAN assignment is done by configuring these 3 attributes:

• Tunnel-Type
• Tunnel-Medium-Type
• Tunnel-Private-Group-ID

SecureW2’s Cloud RADIUS supports additional VLAN assignment attributes such as:

• Custom groups

These additional parameters allow you an even greater degree of control and flexibility in assigning users to VLANs so that you can efficiently maximize your network security.

Which RADIUS for Dynamic VLAN Assignment?

Most, though not all, RADIUS servers can be configured to support dynamic VLAN assignment. Keep in mind the other needs of your organization when choosing which to configure. 

Microsoft’s NPS is a popular DIY RADIUS solution because many organizations are already using a Microsoft environment. The ubiquitous Active Directory remains one of the most popular identity providers even though it’s mostly incompatible with many cloud-based applications and services  (including Microsoft’s own Azure AD). The lack of compatibility with cloud services more or less eliminates NPS as a choice. 

FreeRADIUS is another DIY RADIUS which actually is able to interact with cloud directories and the like. Unfortunately, the lack of a GUI is a turn off for most enterprises that want deep customizability and reporting.

SecureW2’s Cloud RADIUS is equipped with the latest in VLAN technology. Our Dynamic Policy Engine enables the RADIUS to make runtime-level policy decisions by directly referencing user attributes stored in any directory (including cloud directories like Google, Azure, and Okta). Not only does this reinforce the network segmentation of VLAN, but it also enables passwordless authentication for any cloud directory via the use of digital certificates. 

If your organization already has an 802.1X network, SecureW2’s turnkey solutions can integrate into your network without any forklift upgrades. If you’re still considering the transition to a secure WPA2-Enterprise network, you’ll be interested in our managed Cloud PKI which has all the components necessary for top-of-the-line X.509 digital certificate security right out of the box. 

We have affordable options for organizations of all sizes. See our pricing here.

Patrick Grubbs

Patrick is an experienced SEO specialist at SecureW2 who also enjoys running, hiking, and reading. With a degree in Biology from College of William & Mary, he got his start in digital content by writing about his ever-expanding collection of succulents and cacti.

Related Posts

How To Test RADIUS Response Time

Evil Twin Attacks Explained

Breaking Down the 802.1X Protocol

Configure EAP-TLS Authentication for Cloud Networks

Sync AD to Google for Cloud Authentication

How RADIUS/802.1X authentication affects VLAN operation

Static vlan requirement:.

RADIUS authentication for an 802.1X client on a given port can include a (static) VLAN requirement. (Refer to the documentation provided with your RADIUS application.) The static VLAN to which a RADIUS server assigns a client must already exist on the switch. If it does not exist or is a dynamic VLAN (created by GVRP), authentication fails. Also, for the session to proceed, the port must be an untagged member of the required VLAN. If it is not, the switch temporarily reassigns the port as described below.

If the port used by the client is not configured as an untagged member of the required static VLAN:

When a client is authenticated on port “N”, if port “N” is not already configured as an untagged member of the static VLAN specified by the RADIUS server, then the switch temporarily assigns port “N” as an untagged member of the required VLAN (for the duration of the 802.1X session). At the same time, if port “N” is already configured as an untagged member of another VLAN, port “N” loses access to that other VLAN for the duration of the session. (This is because a port can be an untagged member of only one VLAN at a time.)

Using a RADIUS server to authenticate clients, you can provide port-level security protection from unauthorized network access for the following authentication methods:

802.1X: Port-based or client-based access control to open a port for client access after authenticating valid user credentials.

MAC address: Authenticates a device’s MAC address to grant access to the network

WebAgent: Authenticates clients for network access using a web page for user login.

VLAN assignment on a port

Following client authentication, VLAN configurations on a port are managed as follows when you use 802.1X, MAC, or Web authentication:

The port resumes membership in any tagged VLANs for which it is already assigned in the switch configuration. Tagged VLAN membership allows a port to be a member of multiple VLANs simultaneously.

The port is temporarily assigned as a member of an untagged (static or dynamic) VLAN for use during the client session according to the following order of options.

The port joins the VLAN to which it has been assigned by a RADIUS server during client authentication.

If RADIUS authentication does not include assigning the port to a VLAN, then the switch assigns the port to the authorized-client VLAN configured for the authentication method.

If the port does not have an authorized-client VLAN configured, but is configured for membership in an untagged VLAN, the switch assigns the port to this untagged VLAN.

Operating notes

During client authentication, a port assigned to a VLAN by a RADIUS server or an authorized-client VLAN configuration is an untagged member of the VLAN for the duration of the authenticated session. This applies even if the port is also configured in the switch as a tagged member of the same VLAN. The following restrictions apply:

If the port is assigned as a member of an untagged static VLAN, the VLAN must already be configured on the switch. If the static VLAN configuration does not exist, the authentication fails. If the port is assigned as a member of an untagged dynamic VLAN that was learned through GVRP, the dynamic VLAN configuration must exist on the switch at the time of authentication and GVRP-learned dynamic VLANs for port-access authentication must be enabled.

If the dynamic VLAN does not exist or if you have not enabled the use of a dynamic VLAN for authentication sessions on the switch, the authentication fails.

To enable the use of a GVRP-learned (dynamic) VLAN as the untagged VLAN used in an authentication session, enter the aaa port-access gvrp-vlans command.

Enabling the use of dynamic VLANs in an authentication session offers the following benefits:

You avoid the need of having static VLANs pre-configured on the switch.

You can centralize the administration of user accounts (including user VLAN IDs) on a RADIUS server.

For information on how to enable the switch to dynamically create 802.1Q-compliant VLANs on links to other devices using the GARP VLAN Registration Protocol (GVRP), see “GVRP” in the Advanced Traffic Management Guide .

For an authentication session to proceed, a port must be an untagged member of the (static or dynamic) VLAN assigned by the RADIUS server (or an authorized-client VLAN configuration). The port temporarily drops any current untagged VLAN membership.

If the port is not already a member of the RADIUS-assigned (static or dynamic) untagged VLAN, the switch temporarily reassigns the port as an untagged member of the required VLAN (for the duration of the session). At the same time, if the port is already configured as an untagged member of a different VLAN, the port loses access to the other VLAN for the duration of the session. (A port can be an untagged member of only one VLAN at a time.)

When the authentication session ends, the switch removes the temporary untagged VLAN assignment and re-activates the temporarily disabled, untagged VLAN assignment.

If GVRP is already enabled on the switch, the temporary untagged (static or dynamic) VLAN created on the port for the authentication session is advertised as an existing VLAN.

If this temporary VLAN assignment causes the switch to disable a different untagged static or dynamic VLAN configured on the port (as described in the preceding bullet and in Example of untagged VLAN assignment in a RADIUS-based authentication session , the disabled VLAN assignment is not advertised. When the authentication session ends, the switch:

Removes the temporary untagged VLAN assignment and stops advertising it.

Re-activates and resumes advertising the temporarily disabled, untagged VLAN assignment.

If you modify a VLAN ID configuration on a port during an 802.1X, MAC, or Web authentication session, the changes do not take effect until the session ends.

When a switch port is configured with RADIUS-based authentication to accept multiple 802.1X and/or MAC or Web authentication client sessions, all authenticated clients must use the same port-based, untagged VLAN membership assigned for the earliest, currently active client session.

Therefore, on a port where one or more authenticated client sessions are already running, all such clients are on the same untagged VLAN.

(See MAC-based VLANs ).

If a RADIUS server subsequently authenticates a new client, but attempts to re-assign the port to a different, untagged VLAN than the one already in use for the previously existing, authenticated client sessions, the connection for the new client will fail.

Example of untagged VLAN assignment in a RADIUS-based authentication session

The following example shows how an untagged static VLAN is temporarily assigned to a port for use during an 802.1X authentication session. In the example, an 802.1X-aware client on port A2 has been authenticated by a RADIUS server for access to VLAN 22. However, port A2 is not configured as a member of VLAN 22 but as a member of untagged VLAN 33 as shown in Active VLAN configuration .

For example, suppose that a RADIUS-authenticated, 802.1X-aware client on port A2 requires access to VLAN 22, but VLAN 22 is configured for no access on port A2, and VLAN 33 is configured as untagged on port A2:

Active VLAN configuration

In Active VLAN configuration , if RADIUS authorizes an 802.1X client on port A2 with the requirement that the client use VLAN 22, then:

VLAN 22 becomes available as Untagged on port A2 for the duration of the session.

VLAN 33 becomes unavailable to port A2 for the duration of the session (because there can be only one untagged VLAN on any port).

To view the temporary VLAN assignment as a change in the active configuration, use the show vlan < vlan-id > command as shown in The active configuration for VLAN 22 temporarily changes for the 802.1X session where < vlan-id > is the (static or dynamic) VLAN used in the authenticated client session.

The active configuration for VLAN 22 temporarily changes for the 802.1X session

However, as shown in Active VLAN configuration , because VLAN 33 is configured as untagged on port A2 and because a port can be untagged on only one VLAN, port A2 loses access to VLAN 33 for the duration of the 802.1X session on VLAN 22.

You can verify the temporary loss of access to VLAN 33 by entering the show vlan 33 command as shown in The active configuration for VLAN 33 temporarily drops port 22 for the 802.1X session .

The active configuration for VLAN 33 temporarily drops port 22 for the 802.1X session

When the 802.1X client’s session on port A2 ends, the port removes the temporary untagged VLAN membership. The static VLAN (VLAN 33) that is “permanently” configured as untagged on the port becomes available again. Therefore, when the RADIUS-authenticated 802.1X session on port A2 ends, VLAN 22 access on port A2 also ends, and the untagged VLAN 33 access on port A2 is restored as shown in The active configuration for VLAN 33 restores port A2 after the 802.1X session ends .

The active configuration for VLAN 33 restores port A2 after the 802.1X session ends

Enabling the use of GVRP-learned dynamic VLANs in authentication sessions

aaa port-access gvrp-vlans Enables the use of dynamic VLANs (learned through GVRP) in the temporary untagged VLAN assigned by a RADIUS server on an authenticated port in an 802.1X, MAC, or Web authentication session. Enter the no form of this command to disable the use of GVRP-learned VLANs in an authentication session. For information on how to enable a switch to dynamically create 802.1Q-compliant VLANs, see “GVRP” in the Advanced Traffic Management Guide . NOTE: If a port is assigned as a member of an untagged dynamic VLAN, the dynamic VLAN configuration must exist at the time of authentication and GVRP for port-access authentication must be enabled on the switch. If the dynamic VLAN does not exist or if you have not enabled the use of a dynamic VLAN for authentication sessions on the switch, the authentication fails. After you enable dynamic VLAN assignment in an authentication session, it is recommended that you use the interface unknown-vlans command on a per-port basis to prevent denial-of-service attacks. The interface unknown-vlans command allows you to: Disable the port from sending advertisements of existing GVRP-created VLANs on the switch. Drop all GVRP advertisements received on the port. See “GVRP” in the Advanced Traffic Management Guide . If you disable the use of dynamic VLANs in an authentication session using the no aaa port-access gvrp-vlans command, client sessions that were authenticated with a dynamic VLAN continue and are not deauthenticated. (This behavior differs from how static VLAN assignment is handled in an authentication session. If you remove the configuration of the static VLAN used to create a temporary client session, the 802.1X, MAC, or Web authenticated client is deauthenticated.) However, if a RADIUS-configured dynamic VLAN used for an authentication session is deleted from the switch through normal GVRP operation (for example, if no GVRP advertisements for the VLAN are received on any switch port), authenticated clients using this VLAN are deauthenticated.

Copyright © 2015 Hewlett-Packard Development Company, L.P.

Thank you for taking the time to respond. The NETGEAR documentation team uses your feedback to improve our knowledge base content.

Rating Submitted

Do you have a suggestion for improving this article?

Characters Left : 500

MyNETGEAR® Account

Welcome back

Access your NETGEAR

NETGEAR Support

How do I enable dynamic VLAN assignment on my access point using a RADIUS server?

Was this article helpful?    Yes      No

First you must enable dynamic vlan assignment on your switch and download and instal FreeRADIUS for windows.

• Open a web browser.

The default IP address is 192.168.0.239 and the default subnet mask is 255.255.255.0.

You are prompted to enter your password.

The default password is password . Passwords are case-sensitive.

After the system authenticates you, the System Information screen displays.

• Select  Switching > VLAN > Basic > VLAN Configuration .
• Enter 2 in the VLAN ID field.
• Enter VLAN2 in the VLAN Name field.
• Select Add .
• Select Security > Port Authentication > Advanced > Port Authentication .
• Check Port boxes 0/1 and 0/2.
• Set Control Mode to Force Authorized .
• Click Apply .

Last Updated:12/06/2022 | Article ID: 000061876

Was this article helpful?

This article applies to:, looking for more about your product.

Get information, documentation, videos and more for your specific product.

Can’t find what you’re looking for?

Quick and easy solutions are available for you in the NETGEAR community.

Need to Contact NETGEAR Support?

With NETGEAR’s round-the-clock premium support, help is just a phone call away.

Complimentary Support

NETGEAR provides complimentary technical support for NETGEAR products for 90 days from the original date of purchase.

NETGEAR Premium Support

Gearhead support for home users.

GearHead Support is a technical support service for NETGEAR devices and all other connected devices in your home. Advanced remote support tools are used to fix issues on any of your devices. The service includes support for the following:

• Desktop and Notebook PCs, Wired and Wireless Routers, Modems, Printers, Scanners, Fax Machines, USB devices and Sound Cards
• Windows Operating Systems (2000, XP or Vista), MS Word, Excel, PowerPoint, Outlook and Adobe Acrobat
• Anti-virus and Anti-Spyware: McAfee, Norton, AVG, eTrust and BitDefender

ProSUPPORT Services for Business Users

NETGEAR ProSUPPORT services are available to supplement your technical support and warranty entitlements. NETGEAR offers a variety of ProSUPPORT services that allow you to access NETGEAR's expertise in a way that best meets your needs:

• Product Installation
• Professional Wireless Site Survey
• Defective Drive Retention (DDR) Service

Where to Find Your Model Number

To find the model/version number, check the bottom or back panel of your NETGEAR device.

Select a product or category below for specific instructions.

Nighthawk Routers

Powerline and Wall Plug Extenders

Cable and DSL Modem Routers

ReadyNAS Network Storage

Wireless Access Points

Other Business Products

Mobile Broadband

• OPNsense Forum »
• English Forums »
• General Discussion »
• Dynamic VLANs without Radius possible?

Author Topic: Dynamic VLANs without Radius possible?  (Read 2614 times)

Patrick m. hausen.

• Hero Member

• Posts: 5067

Re: Dynamic VLANs without Radius possible?

Your switch needs to do that. OPNsense only understands static VLAN interfaces which you then connect to a switch.

I figured maybe with a firewall that powerful, there were other options.

Quote from: saveNAT on January 12, 2023, 06:09:19 pm I figured maybe with a firewall that powerful, there were other options.

• Posts: 1149
• IT Aficionado

For a home network I would take a step back and reconsider: why dynamic VLAN assignments at all? Many devices will be wirelesss so that is solved with multiple SSIDs mapped to VLANs. Then there's static VLAN assignments to switch ports. Do you really rewire your homw network devices every other day?

OpnSense has a FreeRadius server plugin (os-freeradius), so what is the problem? If you have a Radius-capable switch, you can define as many VLANs as you like and configure the switch ports to 802.1x based on your Radius settings. I do exactly that with Unifi switches.

• Posts: 6723

If someone (child, woman, guest) plugs a device into a network socket, it would be nice if the device was integrated into the corresponding VLAN. In this case, I could perhaps switch all the ports in the switch that are not required to the guest VLAN and switch only special ports to other VLANs if required. Would you see that as a viable alternative? ... I will also look at the Radius server in my test setup. The only question is whether the Radius server does not make the entire system extremly complex. Are you getting along well with your Radius server? Are there any breakdowns and how big is the maintenance effort?

So there are only 3 options for the network sockets in the house: 1. Switch all unused ports in the switch to the guest VLAN 2. Disable all unused ports in the switch 3. Use Radius servers

If you want a really secure solution, you need Radius anyway, and certificate-based Radius at that. So I do not get the rationale of avoiding Radius. What are you really trying to accomplish? What kind of in-between would solve that purpose? Maybe I just cannot see it.

• SMF 2.0.19 | SMF © 2021 , Simple Machines Privacy Policy | XHTML | RSS | WAP2

Meraki Community

• Community Platform Help
• Contact Community Team
• Meraki Documentation
• Meraki DevNet Developer Hub
• Meraki System Status
• Technical Forums

Dynamic VLAN Assignment on MR

• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Printer Friendly Page

• Mark as New
• Report Inappropriate Content
• All forum topics
• Previous Topic

• New May 13: Join us in some fun wordplay for National Limerick Day, hooray!
• May 7: Community Platform Update: Reducing space within content
• May 2: Recognizing the April 2024 Members of the Month
• Installation 207
• Interference 77
• RF Spectrum 96
• Community guidelines
• Cisco privacy
• Khoros privacy
• Terms of service