Using the features of dynamic VLAN and authentication on Zyxel switches
Following the recommendations of "best practice", network devices of various purposes, such as IoT, work computers, smartphones, guest devices, should always be located in different subnets, and ideally terminated through a common security gateway, however, in some cases, for example, when the gateway does not cope with the flow of traffic, distribution by subnets it can be assigned to a network switch to separate different devices by VLANs, thus separating access to different networks already at a reliable and fast L2 level. Here the question arises, how to cope with a large fleet of devices, so as not to prescribe rules for each individually, and to abandon insecure authorization by MAC address?
To solve such a non-trivial task, authentication via external services is used, in particular, the RADIUS server. Starting with the 1920 series, Zyxel switches support authentication via 802.1x, as well as MAC authentication, and starting with the 2220 series and XS1930/XMG1930 with the L3 Access license, both of these modes can be used separately or jointly (the so-called Compound Auth mode).
Setting up using RADIUS
The built–in RADIUS server is configured in the switch menu in the Advanced Application – AAA - RADIUS Server Setup tab. Here you just need to specify its IP address and the switch authentication token on the server. After that, go to the Port Autentification - 802.1x tab and select the ports for which authentication will be required. Here we select only those ports to which client devices that require authentication will connect, and in order for everything to work correctly, we do not need to select ports through which traffic goes to the network gateway, to the RADIUS server itself or to the Private Server.
After that, it remains to add the necessary settings to the RADIUS server configuration file, which is usually located at the path /etc/freeradius/clients.conf. Here is an example of a simple config:
client 192.168.1.8 {
secret = hwp-test-zyxel-1234
shortname = switch
nastype = other
}
The next step on the RADIUS server is to set up user profiles that will authenticate to our network.
user-A Cleartext-Password := «password12345»
Service-Type = Administrative-User
user-B Cleartext-Password := «password123»
Service-Type = Administrative-User
And we overload the RADIUS server to apply the changes.
Now it remains to set up user accounts on client machines. Under Windows, we need to run services.msc from the command line and tick Enable IEEE 802.1X Authentication in the properties of the Wired AutoConfig service, after which we specify the User Authentication identification mode in the additional properties. If certificates are not used on the RADIUS server, you will need to disable their verification in Windows in the additional authentication properties.
After connecting to the specified switch port from the client computer, we will be prompted to enter the user's username and password in accordance with the settings of the RADIUS server. At this point, we can say that the authentication process is complete, but now we need to send unauthorized users to the guest VLAN, and this is done as follows.
Setting up a guest VLAN for unauthorized users
In most cases, for users who have not authenticated, it is enough only to disable access to corporate resources at the L2 level, leaving the possibility of accessing the Internet.
In the switch, in the Port Authentication tab, go to the Guest VLAN tab. Select the ports for which authorization was configured above, and specify the VLAN for unauthorized (guest users).
Now you will need to make additional settings for the VLAN, specifying fixed untagged resource ports for the 100th ID that will be available to guests, for example, the port of the upstream gateway for Internet access. That is, VLANs of both authorized and guest users should come to the gateway, and the guest VLAN should be prohibited from ports to which corporate resource servers are connected.
After that, we add the following guest entry to the RADIUS server config:
client 192.168.1.8 {
secret = password123
shortname = switch
nastype = other
}
And in the /etc/freeradius/users file, we add a user entry:
user Cleartext-Password := «password54321»
Service-Type = Administrative-User
After that, we overload the RADIUS server. Similarly, we make tinctures on the Windows client side, but only now, when connecting to the port with authorization in the Windows pop-up window, we do not enter the login-password pair that we set for user-A and user-B, but enter Guest as the username and any random password. The client will connect to the guest network and get access only to Internet resources through the gateway.
Configuring authentication by MAC address
Authorization by MAC address is configured in a similar way. At the first stage, you need to enable MAC authentication for certain ports in the "security" section and set a common password. Please note that the ports to which the Internet gateway, RADIUS server, or corporate network resources connect should not be included in the authentication list.
Now, in the RADIUS server configuration file /etc/freeradius/users, specify the MAC addresses of users in this way:
Access01-00-0C-29-AA-AA-AA Cleartext-Password := «zyxel»
Access01-00-0C-29-BB-BB-BB Cleartext-Password := «zyxel»
After that, we overload the RADIUS server to apply the settings.
If your organization does not have the ability to install a Radius server, you can use what is available in the Zyxel Nebula service, although at the moment it only works for authentication via MAC addresses. You can add one or two addresses manually, and you can use file import to add users en masse.
Conclusions
As you can see, the process of configuring authentication by MAC address and via the RADIUS server on Zyxel switches boils down to a simple selection of parameters via the Web interface and does not require immersion in the command line syntax. This operation can also be performed by a novice network administrator with minimal knowledge of Linux and network hardware.
Michael Degtjarev (aka LIKE OFF)
01/05.2024
