RADIUS

The RADIUS view presents the scaffolds associated with configuring the rXg integrated RADIUS server.

Understanding RADIUS in Network Authentication

Background and Context

RADIUS (Remote Authentication Dial-In User Service) has been the cornerstone of network authentication for decades. Originally developed for dial-up access, RADIUS has evolved to become the standard protocol for network access control in modern wired and wireless networks. In today's environments, RADIUS servers must handle authentication requests from diverse sources including:

• Wireless access points and controllers
• Ethernet switches with IEEE Std 802.1X port security
• VPN concentrators and remote access servers
• Network Access Servers (NAS) of various types
• IoT gateways and specialized network equipment

Each authentication request carries a wealth of information in the form of RADIUS attributes that describe:

• The connection attempt: Username, password, authentication method
• The requesting device: MAC address, IP address, device type
• The network infrastructure: Access point SSID, switch port, NAS identifier
• The connection context: Location, time, port type, protocol

The rXg integrated RADIUS server leverages this rich attribute data to make intelligent routing decisions, ensuring that each authentication request is handled by the appropriate backend system with the correct policies applied.

The Need for Intelligent Realm Selection

Traditional RADIUS deployments often rely on simple realm stripping (using the @ symbol in usernames like [email protected]) to route authentication requests. However, modern networks require more sophisticated approaches due to several factors:

Multi-Tenancy Requirements

Service providers and managed service organizations hosting multiple customers need to route each tenant's authentication to their respective authentication servers while maintaining complete isolation between tenants. Each organization may have different:

• Authentication backends (LDAP, Active Directory, cloud services)
• Security policies and access controls
• Network segments and VLAN assignments
• Bandwidth and usage limitations

Device-Based Routing

Different device types require different authentication paths and policies:

• Corporate laptops: Authenticate against Active Directory with certificate validation
• Employee smartphones: Use different credentials or authentication methods
• IoT devices: MAC-based authentication with specific network isolation
• Guest devices: Captive portal with self-registration
• Printers and servers: Special handling with static VLAN assignment

Location-Aware Authentication

Users in different physical locations or connecting through different network segments may require different authentication servers and policies:

• Executive floors: Higher security requirements with additional authentication factors
• Conference rooms: Temporary access with time-based restrictions
• Manufacturing floor: Device-specific authentication with restricted access
• Remote sites: Local authentication with failover to central servers

Protocol Flexibility

Supporting various authentication protocols simultaneously with different backend requirements:

• IEEE Std 802.1X: Full enterprise authentication with dynamic VLAN assignment
• MAC Authentication Bypass (MAB): For devices unable to perform IEEE Std 802.1X
• Captive Portal: Web-based authentication for guests
• VPN: Remote access with different policy sets
• API-based: Modern cloud authentication services

Dynamic Network Segmentation

Modern networks require dynamic assignment of network resources based on multiple factors:

• User role: Different VLANs for students, faculty, and staff
• Device type: Separate networks for corporate vs. personal devices
• Security posture: Quarantine networks for non-compliant devices
• Time of day: Different access levels during business hours vs. after hours
• Location: Resources available based on physical connection point

How rXg Addresses These Challenges

The rXg RADIUS Server Realms system addresses these challenges through a sophisticated multi-layered approach:

1. Flexible Attribute Matching: Use any RADIUS attribute with regular expressions for precise request identification
2. Policy-Based Control: Group users and devices with common requirements
3. Hierarchical Evaluation: Rank-based server selection ensures proper precedence
4. Dynamic Resource Assignment: Automatic VLAN and bandwidth allocation
5. Multi-Backend Support: Native integration with RADIUS, LDAP, and PMS servers
6. Validation and Conflict Prevention: Built-in rules prevent ambiguous configurations

This intelligent realm selection capability transforms RADIUS from a simple authentication protocol into a powerful policy engine that can adapt to the most complex network requirements while maintaining security, performance, and manageability.

Centralized Infrastructure Device AAA Server

The rXg identity database may be used as a credential store for rXg units or other third party devices via the RADIUS protocol. One common use of the rXg RADIUS server is to serve as a central credential database for administrative access to infrastructure equipment. For example, most VLAN "smart" switches and "enterprise" wireless access points may be configured to look to a RADIUS server for authenticating administrative access. Using the integrated rXg RADIUS server as a central credential store for infrastructure is a simple and effective way to reduce the complexity that is usually associated with networks that have a large number of devices.

Configuring rXg For Centralized Infrastructure Device AAA Server

Procedure:

1. Create an Account Group that will be tied to Administrator Account(s)
2. Create a policy for Administrator Account(s) Account Group
   • Check the AAA Account Group in the Account group section.
3. Create a WAN Target that contains the public IP the radius request will come from.
4. Edit Radius Server Options add WAN target previously created.
5. Create a RADIUS realm and attach the policy created from the Administrator Account(s).

6. Create a new Account that will contain the credentials.

   Attach account to the policy for Administrator Account(s)

7. Point remote device to the rXg RADIUS server.

8. Navigate to Identities-->Groups and create a new Account Group.

   

9. Navigate to Policies-->Captive Portal and create a new Policy. Enter a name for the new policy and check the Account Group created in the previous step.

   

10. Create a new WAN Target or edit existing WAN Target by navigating to Identities-->Definitions. Enter the IP(s) that should be allowed access to the Radius Server.

    

11. Edit the RADIUS Server Options by navigating to Services-->RADIUS and check the WAN Target. Click Update.

    

12. Create a new RADIUS Server Realm and select the policy that was created for the Administator account(s). Click Create.

    

13. Create a new Account by navigating to Identities-->Accounts, Enter the Login name and password. Under Provision set the Group to the Account Group created previously. A First and Last name will also need to be provided along with an email address.

    

14. Point the device to use the RADIUS server running on the rXg, set the primary IP address of the rXg as the AAA server, and adjust the ports if necessary. The key can be copied from the Radius Server Options on the rXg.

Subscriber Roaming

Another common use of the integrated rXg RADIUS server is to share a single centrally located end-user database amongst a set of geographically diverse RADIUS NAS capable devices. For example, "smart" access points, DSLAMs and even modem banks may be configured to use RADIUS to use an rXg with the RADIUS server enabled as a credential store. Using a single unified credential store across devices that controls access to multiple media helps control operational costs.

In many cases, the RADIUS NAS may also be configured for forced browser redirect of unauthenticated end-users to the rXg captive portal. This enables end-user self-provisioning and further reduces operational overhead. Since the rXg billing mechanisms are fully integrated into with the RADIUS server enabling operators to easily bill end-users for access to a diverse set of media.

The rXg integrated RADIUS server may also be used as a mechanism to loosely federate multiple rXg units. RG Nets recommends the deployment of the rXg clustering mechanism with an rXg cluster controller for unified and simplified clustering of multiple rXg units. However, for certain special cases, it may be more appropriate to use the RADIUS server of an rXg node or an rXg cluster controller along with the RADIUS NAS of multiple other rXgs to create a federation of rXg devices that share a single database.

One rXg unit is then dedicated to being the federation master. The captive portal web application server and end-user database are centrally stored on the federation master. The federation nodes are configured to authenticate using the RADIUS NAS clients and the rXg federation master is configured to be a RADIUS server.

Enterprise NAC

The rXg integrated RADIUS Server can be used to as a centralized AAA server for enterprise wired and wireless networks. Edge infrastructure devices are configured as access servers with port control enabled. Both username/password tuples and MAC address authentication credentials are supported. The rXg can proxy authentication to an external LDAP or RADIUS server (discussed later in this manual page) and/or check the local database.

If the local database is used then the operator may choose to create accounts for each employee and set a password. Alternatively, the administrator can use MAC address device authentication. To accomplish this, the operator will need to populate an account with desired MAC addresses. In either case, the account(s)should be associated with an account group. The account group also needs to be associated to a policy that is selected under a RADIUS Server Realm's matching options. By associating VLAN(s) to the RADIUS Server Realm , an operator can control what network(s) enterprise owned devices are assigned.

For example, in the packet exchange below, the Calling-Station-IDattribute contains the MAC Address of the requesting device. The highest-priority policy will be used to determine which RADIUS Server Realm the device matches. The Tunnel-Private-Group-IDattribute in the Access-Accept packet shows the VLAN assigned to this device.

14:38:33.381021 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 206)
  10.103.254.4.56792 > 10.103.254.1.1812: [udp sum ok] RADIUS, length: 178
    Access-Request (1), id: 0xe5, Authenticator: 2b9a4726041df0639dcc5f8574c30f5a
      User-Name Attribute (1), length: 14, Value: 449160ece7fa
        0x0000: 3434 3931 3630 6563 6537 6661
      User-Password Attribute (2), length: 18, Value:
        0x0000: a0e8 7cc3 4eb8 c07f 2322 714c a2e7 416e**Calling-Station-Id Attribute (31), length: 19, Value: 44-91-60-EC-E7-FA** 0x0000: 3434 2d39 312d 3630 2d45 432d 4537 2d46
        0x0010: 41
      NAS-IP-Address Attribute (4), length: 6, Value: 10.103.254.4
        0x0000: 0a67 fe04
      Called-Station-Id Attribute (30), length: 32, Value: D4-68-4D-2A-39-F0:SomeSSID
        0x0000: 4434 2d36 382d 3444 2d32 412d 3339 2d46
        0x0010: 303a 4b61 7272 6963 6b48 6f75 7365
      Service-Type Attribute (6), length: 6, Value: Framed
        0x0000: 0000 0002
      NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
        0x0000: 0000 0013
      NAS-Identifier Attribute (32), length: 19, Value: D4-68-4D-2A-39-F8
        0x0000: 4434 2d36 382d 3444 2d32 412d 3339 2d46
        0x0010: 38
      Vendor-Specific Attribute (26), length: 20, Value: Vendor: Unknown (25053)
        Vendor Attribute: 3, Length: 12, Value: KarrickHouse
        0x0000: 0000 61dd 030e 4b61 7272 6963 6b48 6f75
        0x0010: 7365
      Message-Authenticator Attribute (80), length: 18, Value: .,H..-..S@.)..X.
        0x0000: 842c 481d 8a2d 8c03 5340 0c29 deeb 5881
14:38:33.414314 IP (tos 0x0, ttl 64, id 6773, offset 0, flags [none], proto UDP (17), length 74)
    10.103.254.1.1812 > 10.103.254.4.56792: [bad udp cksum 0x111c -> 0x598a!] RADIUS, length: 46
    Access-Accept (2), id: 0xe5, Authenticator: d6f41b864e670829842982228b59649e
      Class Attribute (25), length: 8, Value: Family
        0x0000: 4661 6d69 6c79
      Tunnel-Medium-Type Attribute (65), length: 6, Value: Tag[Unused] 802
        0x0000: 0000 0006**Tunnel-Private-Group-ID Attribute (81), length: 6, Value: 2002**0x0000: 3230 3032
      Tunnel-Type Attribute (64), length: 6, Value: Tag[Unused] VLAN
        0x0000: 0000 000d

The enterprise NAC functionality can be used to augment other functions of the rXg. For instance, some WLAN controllers proxy RADIUS access-requests through the controller for client authentication, while others send the requests directly from each AP. Because the rXg utilizes ACLs to limit access to the RADIUS server function, the operator should utilize RADIUS MAC authentication on switchports to automate servicing access-requests from many APs.

Procedure:

1. Create AP managment VLANs
2. Create an IP group for AP Managment VLANs
3. Create a policy for AP Management IP group
   • Add AP Management policy to RADIUS Server Options scaffold
4. Create a MAC group containing a wildcard of the OUIs of Access Points
5. Attach MAC group to a policy
6. Create a RADIUS realm for the AP MAC group policy
   • Attach AP Management VLANs
7. Enable RADIUS MAC authentication bypass on switch ports

RADIUS Password Authentication

When using password-based RADIUS authentication methods (such as PAP, CHAP, EAP-PEAP, EAP-TTLS, or MS-CHAPv2), it is important to understand the distinction between the two types of credentials stored for each account.

Account Credentials

Each account in the rXg has two separate password fields:

• Login Password - The password used for web portal authentication and password-based RADIUS authentication. When authenticating via RADIUS, users must enter this password.
• Pre-Shared Key (PSK) - The key used exclusively for wireless encryption in Dynamic PSK (DPSK) deployments. This key is used by the wireless infrastructure to encrypt the connection between the client device and the access point. It is not used for RADIUS authentication.

MS-CHAP Authentication

MS-CHAP and MSCHAPv2 are commonly used as inner authentication methods within EAP-PEAP or EAP-TTLS. These protocols require the server to store an NT hash of the password. To enable MS-CHAP support:

1. Navigate to Services :: RADIUS and edit the RADIUS Server Options
2. Enable the MS-CHAP checkbox
3. Click Update

Important: The MS-CHAP option must be enabled before account passwords are set. The NT hash is computed when the password is initially saved. If MS-CHAP is enabled after accounts already exist, the operator must reset each account's password to generate the NT hash. Disabling MS-CHAP will remove all stored NT hashes.

IEEE Std 802.1X EAP-PEAP/TTLS Authentication

The rXg integrated RADIUS server supports IEEE Std 802.1X authentication using EAP-PEAP and EAP-TTLS with inner authentication methods such as MSCHAPv2, PAP, and CHAP. This enables enterprise-grade wireless and wired network access control using username/password credentials stored in rXg Accounts.

How It Works

When a client device connects to an IEEE Std 802.1X-enabled network:

1. The client initiates EAP authentication with the access point or switch
2. The infrastructure device forwards the RADIUS Access-Request to the rXg
3. The rXg establishes a TLS tunnel (PEAP or TTLS) with the client
4. Inside the tunnel, the client sends credentials (username/password)
5. The rXg retrieves the NT-Password hash from the matching Account record
6. The inner authentication method (e.g., MSCHAPv2) validates the credentials
7. On success, the rXg returns Access-Accept with optional VLAN assignment

Critical Configuration Settings

The following RADIUS Server Realm settings are essential for IEEE Std 802.1X EAP-PEAP/TTLS authentication:

Setting	Required Value	Reason
Assume MAC auth	Unchecked	When checked, the rXg treats requests as MAC authentication and does NOT retrieve the NT-Password from the Account. This causes MSCHAPv2 to fail with "No NT-Password" errors.
Always perform Account lookup	Checked	Ensures the Account record is retrieved to obtain the NT-Password hash, even when matching by attribute pattern rather than account group membership.

When to Use Each Setting

Use Case	Assume MAC auth	Always perform Account lookup
IEEE Std 802.1X EAP-PEAP/MSCHAPv2 (username/password)	Unchecked	Checked
IEEE Std 802.1X EAP-TTLS/PAP (username/password)	Unchecked	Checked
IEEE Std 802.1X EAP-TLS (certificate-based)	Unchecked	Unchecked
MAC Authentication Bypass (MAB) only	Checked	Optional
Mixed IEEE Std 802.1X + MAB fallback	Unchecked	Checked

Configuration Procedure

Prerequisites: - MS-CHAP enabled in RADIUS Server Options (see above) - A valid TLS certificate configured for the RADIUS server - User Accounts created with passwords (NT-Password hash is generated automatically when MS-CHAP is enabled) - Infrastructure devices (APs, switches) configured as RADIUS clients

Procedure:

1. Navigate to Services :: RADIUS
2. Configure RADIUS Server Options:
   • Enable the MS-CHAP checkbox
   • Set a secret (shared with infrastructure devices)
   • Select WAN targets or policies to allow RADIUS client access
   • Optionally select a certificate for EAP-TLS tunnels
3. Create a RADIUS Server Realm for IEEE Std 802.1X authentication:
   • Enter a descriptive name (e.g., "Enterprise IEEE Std 802.1X")
   • Select policies containing the Account Groups for authorized users
   • Uncheck "Assume MAC auth"
   • Check "Always perform Account lookup"
   • Optionally configure Dynamic VLANs for VLAN assignment
   • Optionally add RADIUS Server Attributes for vendor-specific responses
4. Create user Accounts under Identities :: Accounts:
   • Set Login (username) and Password
   • Assign to an Account Group linked to a Policy selected in step 3
5. Configure infrastructure devices to use the rXg as their RADIUS server

Troubleshooting

If RADIUS authentication fails, verify that:

• The user is entering their account login password (not their PSK)
• For MS-CHAP: the MS-CHAP option is enabled and the account password was set after enabling it

Error: "No NT-Password. Cannot perform authentication"

This error indicates MSCHAPv2 cannot find the password hash. Common causes:

Cause	Solution
MS-CHAP not enabled	Enable MS-CHAP in RADIUS Server Options
Password set before MS-CHAP enabled	Reset the account password to regenerate the NT hash
"Assume MAC auth" is checked	Uncheck this setting on the RADIUS Server Realm
Account lookup not performed	Check "Always perform Account lookup" on the realm
No matching Account found	Verify the username exists as an Account login
Account not in correct group	Ensure the Account is in an Account Group linked to a Policy selected on the realm

Verification Steps:

1. Enable debug on the RADIUS Server Options to log packet contents
2. Check /var/log/radius/radius.log for authentication flow
3. Successful authentication shows: perl: &control:NT-Password = $RAD_CHECK{'NT-Password'} -> '0x...' mschap: Found NT-Password
4. Failed authentication shows: WARNING: mschap: No Cleartext-Password configured. Cannot create NT-Password ERROR: mschap: FAILED: No NT-Password. Cannot perform authentication

Account Requirements

For MSCHAPv2 authentication, each Account must have:

• Login: The username the client will enter
• Password: Set via the admin UI (the NT-Password hash is computed automatically when MS-CHAP is enabled)
• Account Group membership: The Account must belong to an Account Group that is linked to a Policy selected on the RADIUS Server Realm

The NT-Password (NTLM hash) is automatically generated when: - Creating or updating an Account with a password in the rXg admin UI (with MS-CHAP enabled) - Importing accounts via CSV with plaintext passwords - Syncing from LDAP/Active Directory (if NT hash is available)

IEEE Std 802.1X EAP-TLS Authentication (Certificate-Based)

EAP-TLS provides the highest level of security for IEEE Std 802.1X authentication by using client certificates instead of passwords. Both the server and client authenticate each other using X.509 certificates, eliminating the risks associated with password-based authentication.

How EAP-TLS Works

When a client device connects to an EAP-TLS enabled network:

1. The client initiates EAP authentication with the access point or switch
2. The infrastructure device forwards the RADIUS Access-Request to the rXg
3. The rXg presents its server certificate to the client
4. The client validates the server certificate against its trusted CA list
5. The client presents its client certificate to the rXg
6. The rXg validates the client certificate against the configured CA and optionally checks CRL
7. On successful mutual authentication, the rXg returns Access-Accept with optional VLAN assignment

Prerequisites

• A Certificate Authority (CA) infrastructure for issuing client certificates
• Server certificate for the RADIUS server (non-wildcard recommended)
• Client certificates issued to each authenticating device or user
• CA certificate chain imported into the rXg

Configuration Procedure

1. Import or create certificates under System :: Certificates:

   • Import or create the CA certificate that will sign client certificates
   • Import or create a server certificate for the RADIUS server
   • Ensure the server certificate is signed by a CA trusted by your clients

2. Configure RADIUS Server Options under Services :: RADIUS:

   • Enable the active checkbox
   • Set the secret (shared with infrastructure devices)
   • Enable the enable EAP checkbox
   • Select the server certificate (the TLS certificate for EAP)
   • Optionally enable check CRL if using Certificate Revocation Lists
   • Select WAN targets or policies to allow RADIUS client access

3. Create a RADIUS Server Realm for EAP-TLS authentication:

   • Enter a descriptive name (e.g., "Certificate Auth")
   • Configure policies if restricting by identity group
   • Optionally configure attribute patterns for SSID-based matching
   • Uncheck "Assume MAC auth"
   • "Always perform Account lookup" can be left unchecked for pure certificate authentication
   • Optionally configure Dynamic VLANs for VLAN assignment

4. Configure client devices:

   • Install the CA certificate as a trusted root CA
   • Install the client certificate and private key
   • Configure the IEEE Std 802.1X supplicant to use EAP-TLS
   • Set the identity to match the certificate Common Name (CN) or Subject Alternative Name (SAN)

5. Configure infrastructure devices (APs, switches) to use the rXg as their RADIUS server

Certificate Requirements

Server Certificate: - Must not be a wildcard certificate (Windows clients reject these by default) - Should be signed by a CA trusted by client devices - Must include the RADIUS server's FQDN in the CN or SAN

Client Certificates: - Must be signed by a CA whose certificate is imported into the rXg - Should include user or device identification in the CN or SAN - Must not be expired or revoked (if CRL checking is enabled)

CRL Checking

To enable Certificate Revocation List checking:

1. Ensure your CA publishes CRLs at the URLs specified in the CA certificate's CRL Distribution Points extension
2. Enable check CRL in the RADIUS Server Options
3. The rXg will periodically fetch and cache CRLs from the distribution points
4. Client certificates listed in the CRL will be rejected

Troubleshooting EAP-TLS

Client fails to connect - certificate validation error: - Verify the server certificate is not expired - Ensure the server certificate is signed by a CA trusted by the client - Check that the server certificate is not a wildcard (or enable "allow wildcard EAP certificate")

Server rejects client certificate: - Verify the client certificate is signed by a CA imported into the rXg - Check that the client certificate is not expired - If CRL checking is enabled, verify the certificate is not revoked - Check /var/log/radius/radius.log for specific certificate validation errors

Authentication succeeds but no VLAN assigned: - Verify the RADIUS Server Realm has VLANs configured - Check that the matching policy or attribute pattern is correct - Review RADIUS Server Attributes for proper Tunnel-* attributes

DVLAN for Large Public Venues

The rXg incorporates intelligent VLAN assignment in the RADIUS Server. A RADIUS Server Realm with the per-device setting is used for guest, quarantine and onboarding networks where true device isolation is desired. This mechanism is often used a large public venues so that event attendees can be split across operator chosen VLANs. Optionally each device can be assigned a /30 network. To accomplish this, the operator will need to create a RADIUS Server Realm matching a policy, or attribute pattern, and select per-account or per-device in the Dynamic VLANs sharing menu. To enable microsegmented L3s or L2s for attendees, VLANs with proper auto-increment, and ratio settings should be implemented. VLAN re-use can be used in LPVs, where capacity exceeds available VLANs. This allows for high-density deployments, with minimal broadcast domains.

For example, in the packet exchange below, theCalled-Station-ID attribute contains the AP Radio MAC Address, and SSID the client device requested. By using a attribute pattern match, the operator can have all devices requesting this WLAN match this RADIUS Realm. The rXg has a variety of built in attributes, and allows the operator to define custom attributes to match

14:38:33.381021 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 206)
  10.103.254.4.56792 > 10.103.254.1.1812: [udp sum ok] RADIUS, length: 178
    Access-Request (1), id: 0xe5, Authenticator: 2b9a4726041df0639dcc5f8574c30f5a
      User-Name Attribute (1), length: 14, Value: 449160ece7fa
        0x0000: 3434 3931 3630 6563 6537 6661
      User-Password Attribute (2), length: 18, Value:
        0x0000: a0e8 7cc3 4eb8 c07f 2322 714c a2e7 416e
      Calling-Station-Id Attribute (31), length: 19, Value: 44-91-60-EC-E7-FA
        0x0000: 3434 2d39 312d 3630 2d45 432d 4537 2d46
        0x0010: 41
      NAS-IP-Address Attribute (4), length: 6, Value: 10.103.254.4
        0x0000: 0a67 fe04**Called-Station-Id Attribute (30), length: 32, Value: D4-68-4D-2A-39-F0:EventSSID**0x0000: 4434 2d36 382d 3444 2d32 412d 3339 2d46
        0x0010: 303a 4b61 7272 6963 6b48 6f75 7365
      Service-Type Attribute (6), length: 6, Value: Framed
        0x0000: 0000 0002
      NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
        0x0000: 0000 0013
      NAS-Identifier Attribute (32), length: 19, Value: D4-68-4D-2A-39-F8
        0x0000: 4434 2d36 382d 3444 2d32 412d 3339 2d46
        0x0010: 38
      Vendor-Specific Attribute (26), length: 20, Value: Vendor: Unknown (25053)
        Vendor Attribute: 3, Length: 12, Value: KarrickHouse
        0x0000: 0000 61dd 030e 4b61 7272 6963 6b48 6f75
        0x0010: 7365
      Message-Authenticator Attribute (80), length: 18, Value: .,H..-..S@.)..X.
        0x0000: 842c 481d 8a2d 8c03 5340 0c29 deeb 5881
14:38:33.414314 IP (tos 0x0, ttl 64, id 6773, offset 0, flags [none], proto UDP (17), length 74)
    10.103.254.1.1812 > 10.103.254.4.56792: [bad udp cksum 0x111c -> 0x598a!] RADIUS, length: 46
    Access-Accept (2), id: 0xe5, Authenticator: d6f41b864e670829842982228b59649e
      Class Attribute (25), length: 8, Value: Family
        0x0000: 4661 6d69 6c79
      Tunnel-Medium-Type Attribute (65), length: 6, Value: Tag[Unused] 802
        0x0000: 0000 0006
      Tunnel-Private-Group-ID Attribute (81), length: 6, Value: 2002
        0x0000: 3230 3032
      Tunnel-Type Attribute (64), length: 6, Value: Tag[Unused] VLAN
        0x0000: 0000 000d

DVLAN Microsegmentation for Multi-Tenant and Hospitality

By configuring a RADIUS Server Realm in the rXg to use per-room, or per-guest VLANs, users can be dynamically assigned a microsegmented network. This enables users to have private LANs on a shared infrastructure, enabling property wide coverage of their personal network. Unique features such as screencasting, printing, etc., can happen via standard L2 protocols. To accomplish this, the operator will need to create a RADIUS Server Realm matching a policy associated to the desired account group , and select per-room in the Dynamic VLANs sharing menu.

For example, a hotel client would integrate the rXg with their existing PMS, and assign per-room VLANs to segment guests. This enables the guests to use services like screencasting in their rooms without the need to download an app. A shared office space environment would implement per-guest VLANs, and segment traffic from other guests, while making tasks like printing and file-sharing seamless.

An operator can associate a Bi-NAT pool to a policy, and utilize the per-room DVLAN mechanism to provide a "virtual Residential Gateway" or vRG. This enables end-users to manage their own port forwards for web-hosting, and gaming. In MDU or Dorm environments, this enables zero-operator intervention, and instant provisioning of typically complex configurations.

RADIUS Proxying

RADIUS Proxy Servers can be used in a variety of ways. By defining a RADIUS Proxy Server an operator can choose to proxy authentication, accounting, or all RADIUS packets to a remote RADIUS Server, LDAP Server, or PMS Server. By proxying authentication requests to a remote server, an operator can enable centralized credential management in distributed rXg deployments.

For example, the rXg can proxy ONLY RADIUS Accounting packets to an upstream device. This is useful in routed scenarios, where the rXg is not the head-end. This enables the operator to send user-name and IP/session information to upstream devices such as content filters, or firewalls.

An operator may also choose to proxy authentication requests against a configured LDAP Server. This enables IEEE Std 802.1X authentication directly against an LDAP server such as Microsoft Active Directory, without the use of Microsoft Network Policy Server (NPS).

RADIUS Proxy with RadSec

RadSec is a a protocol for transporting RADIUS datagrams over TCP and TLS. Standard RADIUS communications depend upon the unreliable transport protocol UDP, and lack security for large parts of the packet payload. RadSec provides a means to secure the communication between a RADIUS NAS and Server by utilizing Transport Layer Security (TLS). By utilizing RadSec, an operator can proxy incoming RADIUS requests securely to a centralized credential store.

To learn more about RADIUS, there are numerous web pages that provide background information on the RADIUS protocol. In addition, the O'Relly RADIUS (ISBN 0596003226) book provides a basic overview of the protocol. A good reference for how to use RADIUS in more complex environments is AAA and Network Security for Mobile Access: Radius, Diameter, EAP, PKI and IP Mobility (ISBN 0470011947).

Multiple PSK with Adtran vWLAN

AdTran supports multiple sets of tagged Tunnel-* RADIUS attributes where each set represents a 'guess' of what the end user may have entered into her device as the PSK. When a set of Tunnel-* attributes tagged with :1 are configured in the rXg, the rXg will automatically create additional sets of Tunnel-* attributes that represent additional possible Accounts the device may belong to. The rXg will create up to 24 total attribute sets. The AP will determine which set contains the correct PSK, and if it finds one, will allow the device to connect and start tagging the device traffic with the VLAN from the set that contained the correct PSK. Assuming 'Automatic Provisioning' is enabled in the account, the rXg will then automatically add the new device to the Account that corresponds to the VLAN from the attribute set.

Prerequisites

• Have Onboarding VLANs, associated to policy with a splash portal
• Have usage plan available for selection on splash portal
  • Make sure the "Automatic Provision" checkbox is selected
• Have VLAN(s) available for registered accounts
• Have account group(s) for registered accounts associated to a policy with a landing portal

Configuration

1. 1. Deploy vWLAN OVA
   • vWLAN Appliance gets DHCP by default
2. Login to vWLAN and add AP Licensing
3. Either set Static IP on vWLAN, or add fixed-host address in DHCP
4. Create "domain-name" DHCP Option , and attach to Global DHCP Option Group (Ex. Domain-Name = local)
5. Create DNS Entry for apdiscovery.local to point to vWLAN controller (replace local with your domain name)
6. Add vWLAN Controller to rXg wireless Infrastructure Devices
7. Create an "Onboarding" RADIUS Realm and use an Attribute Pattern match since these devices would be unknown.
   • Select your Onboarding VLANs, to ensure that users are presented the splash portal
8. Create a Radius Realm for the policy of registered accounts
   • - Select your Account VLANs
9. Enable config sync on the vWLAN infrastructure device on the rXg
10. Create a new WLAN choosing the following options
    • Encryption: WPA2
    • Authentication: Multiple PSK
    • VLANs (Any associated with both realms)
11. New RADIUS Server Attributes will be automatically created
12. Create new RADIUS Server Attribute for onboarding
    • Name: Tunnel-Password:1
    • Value: onboarding (or whatever you want the onboarding PSK to be)
13. Edit your Onboarding RADIUS Realm to respond with these attributes (notice the :1)
    • Tunnel-Private-Group-Id:1 : %vlan_tag_assignment.tag%
    • Tunnel-Type:1 : VLAN
    • Tunnel-Medium-Type:1 : IEEE-802
    • Tunnel-Password:1 : onboarding
14. Edit your registered account RADIUS Realm to respond with these attributes (notice NO :1)
    • Tunnel-Private-Group-Id : %vlan_tag_assignment.tag%
    • Tunnel-Type : VLAN
    • Tunnel-Medium-Type : IEEE-802
    • Tunnel-Password : %account.pre_shared_key%

Dynamic PSK with RUCKUS virtual SmartZone (vSZ)

RUCKUS eDPSK enables an external AAA server to manage multiple PSKs associated with a single SSID. the rXg leverages eDPSK in conjunction with internal and external account management to deleiver person area networks (PANs) and virtual residential gateway (vRG) for MDUs.

Prerequisites

• Have Onboarding VLANs, associated to policy with a splash portal
• Have usage plan available for selection on splash portal
  • Make sure the "Automatic Provision" checkbox is selected
• Have VLAN(s) available for registered accounts
• Have account group(s) for registered accounts associated to a policy with a landing portal

Configuration

1. Deploy vSZ OVA, configure the following in the VM console:
   • Configure vSZ in Essentials mode
   • Set Static IP Address, or set DHCP Reservation
2. Continue the vSZ deployment at web GUI - https://{vSZ IP}:8443
3. Add vSZ to rXg wireless Infrastructure Devices
4. Create an "Onboarding" RADIUS Realm and use an Attribute Pattern match since these devices would be unknown.
   • Select your Onboarding VLANs, to ensure that users are presented the splash portal
5. Create a Radius Realm for the policy of registered accounts
   • - Select your Account VLANs
6. Enable config sync on the vWLAN infrastructure device on the rXg
7. Create a new WLAN choosing the following options
   • Encryption: WPA2
   • Authentication: Multiple PSK
   • VLANs (Any associated with both realms)
8. Create new RADIUS Server Attribute for onboarding
   • Name: Ruckus-DPSK
   • Value: onboarding (or whatever you want the onboarding PSK to be)
9. Edit your Onboarding RADIUS Realm to respond with these attributes
   • Tunnel-Private-Group-Id : %vlan_tag_assignment.tag%
   • Tunnel-Type : VLAN
   • Tunnel-Medium-Type : IEEE-802
   • Ruckus-DPSK : onboarding
10. Edit your registered account RADIUS Realm to respond with these attributes
    • Tunnel-Private-Group-Id : %vlan_tag_assignment.tag%
    • Tunnel-Type : VLAN
    • Tunnel-Medium-Type : IEEE-802
    • Tunnel-Password : %account.pre_shared_key%

---

RADIUS Server Realms

An entry in the radius server realms scaffold creates a response realm that enables the rXg to respond to RADIUS requests. The RADIUS Server Realms system provides an advanced, multi-layered authentication routing mechanism that intelligently directs RADIUS authentication requests to appropriate backend servers based on configurable criteria.

One or more radius server realms are required in order to link RADIUS requests with attributes. Only one radius server realm is required if the network design requires that the same set of RADIUS attributes to be transmitted to all RADIUS requests.

Multiple radius server realms may be created in order to allow the rXg integrated RADIUS Server to respond with different RADIUS attributes depending upon the request. The most common usage scenario that requires the creation of two or more radius server realms is a network design that requires different VLANs or sets of VLANs to be assigned based on information present in the incoming RADIUS request. A RADIUS Access-Request will match at most a single RADIUS Server Realm.

Authentication Flow and Realm Selection

The system employs a dual-evaluation approach: policy-based admission control combined with attribute pattern matching. When a RADIUS authentication request arrives, the following sequence occurs:

1. Request Reception: RADIUS request received and attributes extracted (User-Name, NAS-IP, Called-Station-Id, etc.)
2. Server Ranking: All configured RADIUS servers are sorted by rank (highest to lowest: 9 to 0)
3. Sequential Evaluation: For each server in ranked order:
   • Evaluate attribute patterns by priority
   • Check if request matches configured policies
   • Apply realm admission logic (OR/AND)
   • If admitted, select this server and proceed
   • If not admitted, continue to next server
4. Backend Authentication: Proxy request to selected backend (RADIUS, LDAP, or PMS)
5. Session Establishment: Create session with VLAN assignment and send accounting start

RADIUS Server Realm Configuration Guide

This section provides comprehensive step-by-step procedures for configuring RADIUS Server Realms for common deployment scenarios.

Prerequisites

Before configuring a RADIUS Server Realm, ensure the following are in place:

1. RADIUS Server Options configured and active under Services :: RADIUS
2. Policies created for identity-based access control under Policies :: Captive Portal
3. Account Groups and/or MAC Groups created under Identities :: Groups
4. VLANs configured if dynamic VLAN assignment is required under Network :: VLANs
5. Infrastructure Devices configured if switch/AP integration is needed under Network :: Infrastructure Devices

Procedure: Basic RADIUS Server Realm

This procedure creates a basic realm for authenticating users against the local rXg account database.

1. Navigate to Services :: RADIUS
2. Click Create New in the RADIUS Server Realms scaffold
3. Configure basic settings:
   • Name: Enter a descriptive name (e.g., "Employee WiFi")
   • Rank: Set to 0 for default priority, or higher (1-9) for override scenarios
   • Realm Admission Logic: Select "Policy OR Attribute Pattern logic must succeed" for typical deployments
4. Configure request matching:
   • Policies: Select one or more policies containing the Account Groups or MAC Groups that should be authenticated by this realm
   • Optionally add Attribute Patterns to restrict by SSID, NAS-IP, or other RADIUS attributes
5. Click Create

Procedure: RADIUS Server Realm with Dynamic VLANs

This procedure creates a realm that assigns VLANs dynamically based on authentication.

1. Navigate to Services :: RADIUS
2. Click Create New in the RADIUS Server Realms scaffold
3. Configure basic settings:
   • Name: Enter a descriptive name (e.g., "Guest DVLAN")
   • Rank: Set appropriate priority (0-9)
   • Realm Admission Logic: Select based on requirements
4. Configure request matching:
   • Policies: Select applicable policies
   • Add Attribute Patterns if needed (e.g., match specific SSID)
5. Configure Dynamic VLANs:
   • VLAN Sharing: Select the sharing mode:
     • per-Device: Maximum isolation, each device gets unique VLAN
     • per-Account: All devices for same user share VLAN
     • per-Room: Hospitality mode, all devices in room share VLAN
     • per-Guest: Hospitality mode, each guest gets unique VLAN
   • VLANs: Select one or more VLAN pools
   • Reuse VLANs: Enable for high-turnover environments
   • Inherit static VTA: Enable to preserve existing VLAN assignments
   • VTA timeout: Set timeout for VLAN tag assignments
   • Expire VTAs at logout: Enable to release VLANs when sessions end
   • Max VLANs per Called-Station-Id/MAC: Set limit or check "Unlimited"
   • Infrastructure Devices: Select devices that need VLAN change notifications
6. Configure RADIUS Server Attributes:
   • Add Tunnel-Type: VLAN
   • Add Tunnel-Medium-Type: 802
   • Add Tunnel-Private-Group-ID: %vlan_tag_assignment.tag%
7. Click Create

Procedure: RADIUS Server Realm with SSID-Based Routing

This procedure creates a realm that matches requests based on the SSID clients connect to.

1. Navigate to Services :: RADIUS
2. Click Create New in the RADIUS Server Realms scaffold
3. Configure basic settings:
   • Name: Enter a descriptive name (e.g., "Corporate SSID")
   • Rank: Set priority (higher rank = evaluated first)
   • Realm Admission Logic: Select based on requirements
4. Configure request matching:
   • Policies: Select applicable policies (or leave empty for pattern-only matching)
5. Add Attribute Patterns:
   • Click Add in the Attribute Patterns subsection
   • RADIUS Attribute: Select "Called-Station-Id (BSSID/SSID)"
   • Pattern: Enter regex pattern (e.g., .*:CorpWiFi$ to match SSID ending with "CorpWiFi")
   • Priority: Set pattern priority (0-9)
   • Logic: Select OR (any pattern matches) or AND (all patterns must match)
6. Add additional patterns as needed for multiple SSIDs or other criteria
7. Configure Dynamic VLANs and Attributes as needed
8. Click Create

Procedure: RADIUS Server Realm with Proxy Authentication

This procedure creates a realm that proxies authentication to an external RADIUS server.

1. Create a RADIUS Proxy Server first:

   • Navigate to Services :: RADIUS
   • Click Create New in the RADIUS Proxy Servers scaffold
   • Configure the remote server connection details
   • Click Create

2. Create the RADIUS Server Realm:

   • Click Create New in the RADIUS Server Realms scaffold
   • Name: Enter a descriptive name (e.g., "External Auth")
   • Rank: Set appropriate priority
   • Realm Admission Logic: Configure as needed

3. Configure Proxy Settings:

   • RADIUS Proxy Servers: Select the proxy server created in step 1
   • Proxy Authentication: Enable to forward Access-Request packets
   • Proxy Accounting: Enable to forward Accounting packets
   • Proxy MAC Auth: Enable if MAC authentication should also be proxied
   • Replace username with Account: Enable to substitute local account login
   • Create Account: Enable to create local accounts for proxied users
   • Usage Plans: Select plan to apply to auto-created accounts

4. Click Create

Procedure: RADIUS Server Realm with LDAP/Active Directory Authentication

This procedure creates a realm that authenticates users against Active Directory.

1. Configure LDAP Domain first under System :: LDAP Servers:

   • Create an LDAP Domain record with Active Directory binding enabled
   • Ensure "Join Domain" is enabled for the domain

2. Create the RADIUS Server Realm:

   • Navigate to Services :: RADIUS
   • Click Create New in the RADIUS Server Realms scaffold
   • Name: Enter a descriptive name (e.g., "AD Authentication")
   • Rank: Set appropriate priority

3. Configure LDAP Proxy:

   • LDAP Domains: Select the configured Active Directory domain
   • Proxy Authentication: Enable
   • Configure other proxy options as needed

4. Click Create

Procedure: Multi-Realm Configuration with Priorities

This procedure demonstrates configuring multiple realms with priority-based selection.

Scenario: Corporate network with three authentication tiers: - Executives on "Executive-WiFi" SSID VLAN 100 (highest priority) - Employees on "Corp-WiFi" SSID VLAN 200 - Guests on any SSID VLAN 300 (fallback)

1. Create Executive Realm (Rank 9 - Highest Priority):

   • Name: "Executive Access"
   • Rank: 9
   • Realm Admission Logic: AND (require both policy AND pattern match)
   • Policies: Select policy containing Executive Account Group
   • Attribute Pattern: Called-Station-Id matches .*:Executive-WiFi$
   • VLANs: Select VLAN 100 pool
   • Click Create

2. Create Employee Realm (Rank 5 - Medium Priority):

   • Name: "Employee Access"
   • Rank: 5
   • Realm Admission Logic: AND
   • Policies: Select policy containing Employee Account Group
   • Attribute Pattern: Called-Station-Id matches .*:Corp-WiFi$
   • VLANs: Select VLAN 200 pool
   • Click Create

3. Create Guest Realm (Rank 0 - Lowest Priority/Fallback):

   • Name: "Guest Access"
   • Rank: 0
   • Realm Admission Logic: OR (accept any matching policy OR pattern)
   • Policies: Select policy containing Guest MAC Group
   • VLANs: Select VLAN 300 pool
   • Click Create

Result: Authentication requests are evaluated in order: Executive (9) Employee (5) Guest (0). The first matching realm handles the request.

Field Reference

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The rank of a RADIUS server realm (0-9 scale), allows the operator to designate multiple RADIUS realms with the same policy selection. If a RADIUS request matches multiple RADIUS realms, the highest ranking realm is used. This is typically used to override RADIUS realms when specific criteria is met, such as a user of a given policy connecting to a special SSID.

The policies field enables the operator to restrict this response realm to one or more sets of Identities. RADIUS Access-Request messages usually contain the MAC address of the end-user device. Thus a radius server realm may be restricted to answer RADIUS Access-Requests originating from end-user devices whose MAC addresses are present within MAC Groups and Account Groups. If no policies are enabled then the rXg will not restrict this response realm based on Identities but may still be restricted by other parameters such as attribute patterns.

The attribute patterns subsection enables the operator to restrict this response realm to RADIUS Access-Requests that contain the specified RADIUS attributes. One common use for this is mechanism is to restrict a response realm to only respond to RADIUS Access-Requests originating from end-user devices that are attaching to a specific SSID. This capability enables the operator associate respond with different RADIUS attributes depending upon the data in RADIUS Access-Request.

Attribute Pattern Matching System

The attribute pattern matching system uses regular expression patterns to match RADIUS attributes. The system uses Perl-compatible regular expressions (PCRE). Understanding how to construct effective patterns is crucial for implementing robust authentication routing.

Supported RADIUS Attributes:

• Called-Station-Id: Access point BSSID and/or SSID (e.g., .*:CorpWiFi$ matches SSID ending with "CorpWiFi")
• Calling-Station-Id: Client device MAC address (e.g., ^AA:BB:CC.* matches specific OUI)
• User-Name: Username or email format (e.g., ^[^@]+@company\.com$ matches company domain)
• NAS-IP-Address: Network Access Server IP (e.g., ^10\.1\..* matches subnet)
• NAS-Port: Physical or logical port number
• NAS-Port-Id: Text description of the port
• NAS-Port-Type: Connection type (Ethernet, Wireless, etc.)
• NAS-Identifier: Network Access Server identifier
• Custom Attributes: Any valid RADIUS attribute name

Pattern Priority System:

• Patterns are assigned priorities from 0 to 9
• With OR logic: Evaluation stops at first match
• With AND logic: All patterns must match
• Patterns with same priority are evaluated together

Patterns use Perl-compatible regular expressions (PCRE). For regex syntax reference, see Regular-Expressions.info or Regex101.

Realm Admission Logic

The realm admission logic field determines how policies and attribute patterns are combined:

OR Logic - Inclusive Routing:

• Server accepts requests matching EITHER a configured policy OR attribute pattern
• Useful for broad access scenarios, fallback mechanisms, or migration scenarios
• Example: Accept any employee (by policy) OR any device on CorpWiFi SSID

AND Logic - Restrictive Routing:

• Server only accepts requests matching BOTH a configured policy AND attribute pattern
• Essential for high-security environments and disambiguation
• Example: User must be in "Executives" policy AND connecting from "Executive-Floor" SSID

Pattern Evaluation with Uneven Priorities:

When patterns have non-sequential priorities (e.g., 0, 3, 3, 7, 9):

• Patterns are grouped by priority value
• All patterns with same priority are evaluated together
• Groups are processed in ascending order

Example evaluation:

Patterns: Priority 0 (NAS-IP), Priority 3 (two SSID patterns), Priority 7 (Username)

OR Logic:
  1. Check priority 0  If match, STOP (patterns match)
  2. Check both priority 3  If either matches, STOP
  3. Check priority 7  Return result

AND Logic:
  1. Check priority 0  If no match, STOP (patterns don't match)
  2. Check both priority 3  If both don't match, STOP
  3. Check priority 7  Return final result

Configuration Validation

The system enforces validation rules to prevent ambiguous configurations:

Policy Overlap Prevention:

• Same policy cannot be associated with multiple servers using OR logic
• Requires disambiguation through attribute patterns or AND logic

Pattern Uniqueness:

• Identical pattern sets cannot be used by multiple servers with AND logic
• Ensures deterministic realm selection

Logical Consistency:

• AND logic requires at least one attribute pattern
• Patterns must be achievable for successful matching

The dynamic VLANs section determines which VLANs will be passed from the rXg to the RADIUS NAS when a RADIUS Access-Accept message is sent. VLAN assignments are typically passed through RADIUS Attributes.

VLAN Assignment Strategies

VLAN Sharing Modes:

per-Device: Each unique device (by MAC address) receives its own VLAN

• Provides maximum isolation between devices
• Consumes the most VLANs from the pool
• Ideal for guest networks and quarantine scenarios
• Example: Device AA:BB:CC:01 VLAN 100, Device AA:BB:CC:02 VLAN 101

per-Account: All devices authenticated with the same account share a VLAN

• Balances security and resource usage
• Allows device roaming within same account
• Suitable for corporate BYOD environments
• Example: All devices for user "john" VLAN 100

per-Room (Hospitality): All devices in the same room/location share a VLAN

• Enables in-room device communication
• Supports services like screencasting and printing
• Integrates with Property Management Systems
• Example: All devices in Room 101 VLAN 100

per-Guest (Hospitality): Each guest receives a unique VLAN regardless of devices

• Isolates guests from each other
• Allows multiple devices per guest
• Supports VIP and loyalty tier differentiation
• Example: Guest "Smith" all devices VLAN 100

One or more VLAN records must be configured and selected in order for the dynamic VLAN mechanism to be enabled. In most cases each RADIUS Server Realm will be associated with only a single VLAN record.

VLAN Pool Management:

VLANs will be assigned to devices / accounts / PMS-Rooms per the above described selection until all available VLANs in the selected record are exhausted.

Reuse VLANs Option:

• Enabled: VLANs are returned to pool when sessions end and can be immediately reassigned
  • Suitable for high-turnover environments
  • Reduces VLAN exhaustion issues
• Disabled: VLANs remain assigned until manually cleared
  • Provides consistent network identity
  • Useful for static device deployments
  • Requires unlimited VLANs per Called-Station-Id/MAC setting

VLAN Limits:

• Max VLANs per Called-Station-Id/MAC: Configurable limit (1-4094) or unlimited
• Prevents VLAN exhaustion from single access point
• Critical for large public venue deployments

The infrastructure devices setting enables the operator to tie this RADIUS Server Realm with an infrastruture device for the purpose of sending vendor specific instructions when VLANs change. This configuration is an absolute requirement when the dynamic VLAN capability is used with most wireless LAN controllers and wired switches.

The Proxy Servers field enables the operator to proxy incoming RADIUS packets to configured RADIUS Proxy Servers , LDAP Domains , or PMS Servers.

The Proxy Options enable an operator to choose what type of RADIUS packets to proxy, Accounting, Authentication, or both. By default, the rXg integrated RADIUS Server will only proxy IEEE Std 802.1X authentications. The Proxy MAC Auth selection enables the operator to also proxy MAC based authentications. The Replace username selection will override the "User-Name" attribute with the associated accounts login. If the Proxy Server is being used for authentication, the Create Account selection will create a local account on the rXg, and optionally apply a Usage Plan.

The attributes field defines one or more RADIUS attributes that will be appended to all RADIUS responses. Use this mechanism to send vendor specific attributes to the devices making RADIUS requests.

The Assume MAC auth option specifies that when an Account is located during RADIUS lookup and the request looks like a MAC auth request (i.e., the username looks like a MAC address) that we should treat the request as a MAC auth request and use the MAC address as the cleartext password instead of setting the NT-Password.

The Always perform Account lookup option ensures that an Account lookup occurs for the request while checking this realm, assuming it has not been performed already by a higher ranked realm. This is in contrast to the normal behavior where Account lookup is skipped unless there are Account Group-based Policies attached to the realm (or a higher ranked realm). This is necessary if performing MSCHAP authentication and the realm is being selected based on a RADIUS Attribute match pattern, rather than group membership. In this case the lookup is still necessary in order to set the NT-Password for the MSCHAP module.

RADIUS Proxy Servers

An entry in the RADIUS proxy servers scaffold defines a server that may be used to proxy requests to other remote RADIUS servers.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The RADIUS server realms field determines which logical partitions of the RADIUS Server will proxy requests to THIS server.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The priority field is used when multiple RADIUS proxy servers are associated with a RADIUS realm. The RADIUS proxy server with the highest priority is queried first. If the RADIUS proxy server with the highest priority does not respond within the window defined by the tries and timeout fields, the next highest priority server is queried. If no RADIUS proxy servers respond, the end-user is denied access.

The IP field specifies the IP address of the RADIUS server to be queried for credential validation.

The port field specifies the UDP port to use when sending the RADIUS request for credential validation. Similarly the accounting port field specifies the UDP port to use when sending the RADIUS accounting start, stop and intermediate updates. Leave these fields blank to use the defaults.

The secret field is the RADIUS shared secret. It is used to encode and decode messages being sent to and from the RADIUS server. This setting must match that of the RADIUS server in order for credential validation to operate.

If a server does not respond to a request within the timeout time, the server marks the request as timed out. After the configured number of tries , the server is marked as being "zombie", and the zombie period starts. The default timeout window is large because responses may be slow, especially when proxying across the Internet.

A server that is marked "zombie" will be used for proxying as a low priority. If there are live servers, they will always be preferred to a zombie. Requests will be proxied to a zombie server ONLY when there are no live servers. Any request that is proxied to a server will continue to be sent to that server until the server is marked dead. At that point, it will fail over to another server, if a live server is available. If the server does not respond to ANY packets during the zombie period , it will considered to be dead.

If status check is something other than "none", then the server will start sending status checks at the start of the zombie period. It will continue sending status checks until the server is marked "alive". These status packets are sent ONLY if the server is believed to be dead. They are NOT sent if the server is believed to be alive. They are NOT sent if this server is not proxying packets. If the server responds to the status check packet, then it is marked alive again, and is returned to use.

The check interval field configures the number of status checks in a row that the server needs to respond to before it is marked alive. If you want to mark a server as alive after a short time period of being responsive, it is best to use a small check interval , and a large value for answers to alive. Using a long check interval and a small number for answers to alive increases the probability of spurious fail-over and fallback attempts.

RADIUS layer "status checks" are used to see if a server is alive when status check is set to "Status-Server".

Some servers do not support status checks via the Status-Server packet. Others may not have a "test" user configured that can be used to query the server, to see if it is alive. For those servers, there is NO WAY of knowing when it becomes alive again. In this case, after the server has been marked dead, the revival interval must elapse before it is marked alive again, in the hope that it has come back to life. If it has NOT come back to life, the zombie period must elapse before marking it dead again. During the zombie period , all authentications will fail, because the server is still dead. There is nothing that can be done about this, other than to enable the status checks. e.g. if zombie period is 40 seconds, and revive interval is 300 seconds, then for 40 seconds out of every 340, or about 10% of the time, all authentications will fail. If the zombie period and revive interval configurations are set smaller, then it is possible for up to 50% of authentications to fail. We recommend enabling status check , and we do NOT recommend relying on revive interval. The revive interval is used ONLY if status check is set to "none".

If the server does not support Status-Server packets, then the proxying server can still send Access-Request or Accounting-Request packets with a pre-defined username. This behavior is enabled by setting status check to "Access-Request". This practice is NOT recommended, as it may potentially let users gain network access by using these "test" accounts. If it is used, we recommend that the server ALWAYS respond to these Access-Request status checks with Access-Reject. The status check just needs an answer, it does not need an Access-Accept. For Accounting-Request status checks, only the username needs to be set. The rest of the accounting attribute are set to default values. The server that receives these accounting packets SHOULD NOT treat them like normal user accounting packets.

RADIUS Server

The rXg internal credential database of users and tokens may be remotely accessed via the RADIUS protocol. Records in the RADIUS Server scaffold configure the behavior of the rXg RADIUS server.

The active field enables an option set. Exactly one option set may be active at any time. Enabling a particular option set will automatically disable another existing active option set.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The secret field defines the RADIUS shared secret. This shared credential must be identical to one configured on the RADIUS NAS devices that will access this RADIUS server.

The auth port and acct port fields configure the ports that the RADIUS server will listen for requests on. In most cases, the RFC defined ports of 1812 and 1813 should be used as many RADIUS NAS devices are only able to connect to those ports.

The debug field configures the RADIUS server to log the contents of all request and response packets to the log file.

The certificate field specifies an alternate certificate chain to configure the RADIUS server with.

The WAN targets and policies fields determine the set of devices that are allowed to have access to the rXg integrated RADIUS server. By default the rXg has packet filtering rules in place that prevent access to the integrated RADIUS server. This ensures that no devices of any kind may access the RADIUS server unless the operator takes specific action to enable access.

Access to the rXg integrated RADIUS server for RADIUS NAS devices that are on the WAN is enabled by creating one or more WAN targets for the RADIUS NAS devices and then enabling the appropriate check boxes. RADIUS NAS devices on the LAN may be granted access by placing the IPs of the RADIUS NAS devices into an IP Group and then linking the IP Group into a Policy which may be selected here.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

IEEE Std 802.1X (EAP-TLS/TTLS/PEAP) Settings

The rXg RADIUS server supports IEEE Std 802.1X authentication using EAP methods. The following settings control EAP behavior:

The enable EAP checkbox activates EAP authentication support. When enabled, the RADIUS server can process EAP-TLS, EAP-TTLS, and EAP-PEAP authentication requests. This must be enabled for any IEEE Std 802.1X deployment.

The certificate field specifies the TLS certificate chain used for EAP authentication. This certificate is presented to clients during the TLS handshake in EAP-TLS, EAP-TTLS, and EAP-PEAP sessions. The certificate must be a valid, non-expired certificate. Wildcard certificates are rejected by Windows IEEE Std 802.1X clients by default.

The check CRL checkbox enables Certificate Revocation List checking. When enabled, the RADIUS server verifies that client certificates (in EAP-TLS) have not been revoked. The associated certificate chain must have CRL distribution points configured.

The allow wildcard EAP certificate checkbox overrides the default restriction against wildcard certificates. Enable this only if your client devices support wildcard certificates for IEEE Std 802.1X authentication. Windows 8.x and later clients typically reject wildcard certificates.

The store NT password checkbox (also referred to as MS-CHAP) enables storage of NT password hashes for accounts. This is required for MSCHAPv2 authentication, which is commonly used as the inner authentication method in EAP-PEAP and EAP-TTLS. When enabled, NT hashes are computed when account passwords are set. If disabled, all stored NT hashes are removed and MSCHAPv2 authentication will fail.

RADIUS/TLS (RadSec) Settings

RadSec (RADIUS over TLS) provides secure transport for RADIUS packets using TCP and TLS instead of UDP. This eliminates the security limitations of traditional RADIUS shared secrets and enables secure RADIUS communication over untrusted networks.

The RadSec enabled checkbox activates the RadSec listener. When enabled, the RADIUS server accepts TLS-encrypted RADIUS connections on the configured RadSec port.

The RadSec port field specifies the TCP port for RadSec connections. The default port is 2083 as defined in RFC 6614.

The RadSec certificate field specifies the TLS certificate chain used for RadSec connections. This certificate is presented to RadSec clients during the TLS handshake and must be trusted by connecting clients.

The require client certificate checkbox enforces mutual TLS authentication. When enabled, RadSec clients must present a valid client certificate during the TLS handshake. This provides strong authentication of RADIUS clients and is recommended for production deployments.

The minimum TLS version and maximum TLS version fields constrain the TLS protocol versions accepted for RadSec connections. Available options are:

Version	Notes
TLS 1.0	Insecure - not recommended
TLS 1.1	Insecure - not recommended
TLS 1.2	Recommended minimum
TLS 1.3	Most secure, but may have compatibility issues with older clients

The default configuration uses TLS 1.2 for both minimum and maximum, providing a balance of security and compatibility.

Global Behavior Settings

The debug level field controls the verbosity of RADIUS server logging. Available levels are:

Level	Description
Normal	Standard logging of authentication events
Debug	Includes packet contents and processing details
Debug-2	More verbose debugging output
Debug-3	Very verbose debugging output
Debug-4	Maximum verbosity for troubleshooting

The always find account by MAC checkbox forces the RADIUS server to perform an account lookup using the client MAC address for all requests, regardless of the username provided.

The ignore account usage checkbox disables usage tracking and quota enforcement for RADIUS-authenticated sessions.

The authenticate port ownership checkbox enables verification that the requesting device is connected to an expected switch port.

The require message authenticator field controls Message-Authenticator attribute validation:

Setting	Behavior
auto	Require Message-Authenticator if present in request
yes	Always require Message-Authenticator attribute
no	Do not require Message-Authenticator attribute

The max servers field limits the number of FreeRADIUS worker processes. Leave blank for automatic configuration based on system resources.

RADIUS Server Attributes

The rXg integrated RADIUS server responds to RADIUS requests with RFC defined attributes. The operator may define additional attributes to be present in RADIUS responses by creating RADIUS Server Attribute records. Each record defines one additional attribute that will be presnet

The name configures the name of the RADIUS attribute that will be sent to the RADIUS NAS. The name must be agreed upon and configured identically on both the RADIUS server and the RADIUS NAS.

The value configures the value of the payload of the RADIUS attribute that will be sent to the RADIUS NAS in RADIUS server response. The value may be static (e.g., 'IEEE-802' for the 'Tunnel-Medium-Type' when configuring dynamic VLANs). Alternatively the value may be a dynamic value configured through substitution variables.

The RADIUS Server Realms field determines which RADIUS requests will contain the RADIUS Server Attribute defined by this record. More than one RADIUS Server Realm may be selected and thus the RADIUS Server Attribute defined by this record will be present in the responses to each of the defined realms.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Most dynamic VLAN configurations require the following three attributes to be configured:

Attribute	Value
Tunnel-Medium-Type	802
Tunnel-Private-Group-ID	%vlan_tag_assignment.tag%
Tunnel-Type	VLAN

Dynamic PSK Support

The system automatically detects and supports Dynamic PSK implementations from various vendors, allowing each device to use a unique pre-shared key while connecting to the same SSID:

Supported Dynamic PSK Attributes:

• Ruckus-DPSK: Ruckus Dynamic PSK
• Aruba-MPSK-Passphrase: Aruba Multiple PSK
• Cisco-AVPair: Cisco Identity PSK (format: psk-mode=ascii psk=passphrase)
• Tunnel-Password: Generic PSK delivery
• MS-MPPE-Recv-Key: Microsoft encryption key
• CAMBIUM-ePSK-PMK: Cambium enhanced PSK
• TPLink-EAPOL-Found-PMK: TP-Link PSK
• OpenWifi-DPSK variants: OpenWifi Dynamic PSK

When Dynamic PSK attributes are detected, the system enables portal-based PSK management allowing users to view and modify their unique PSK through the self-service portal.

Substitution

Payload fields may contain special keywords surrounded by % signs that will be substituted with relevant values. This enables the operator to deliver values stored in the database as part of the payload.

List of objects available:

Account Create	Usage Plan Purchase	Transaction: success/failure
cluster_node	cluster_node	cluster_node
custom_email	custom_email	custom_email
device_option	device_option	device_option
ip_group	login_session	login_session
login_session	usage_plan	merchant
usage_plan	account	payment_method
account		merchant_transaction
		usage_plan
		account

Credit Card Expiring	Coupon Redemption	Account Charge: success/failure/no response
cluster_node	cluster_node	cluster_node
custom_email	custom_email	custom_email
device_option	device_option	device_option
login_session	coupon	login_session
payment_method	login_session	payment_method
usage_plan	usage_plan	response
account	account	usage_plan
		account

Trigger: Connections	Trigger: Quota	Trigger: DPI
cluster_node	cluster_node	cluster_node
custom_email	custom_email	custom_email
device_option	device_option	device_option
login_session	login_session	login_session
max_connections_trigger	quota_trigger	snort_trigger
transient_group_membership	transient_group_membership	transient_group_membership
account	account	account

Trigger: Time	Trigger: Log Hits	Health Notice: create
cluster_node	cluster_node	cluster_node
custom_email	custom_email	custom_email
device_option	device_option	device_option
login_session	login_session	health_notice
time_trigger	log_hits_trigger
transient_group_membership	transient_group_membership
account	account

Health Notice: cured
cluster_node
custom_email
device_option
health_notice

List of objects available for all associated record types:

Aged AR Penalty
cluster_node
custom_email
device_option
aged_ar_penalty
login_session
payment_method
usage_plan
account

List of attributes available for each object:

account	usage_plan	merchant
id	id	id
type	account_group_id	name
login	name	gateway
crypted_password	description	login
salt	currency	password
state	recurring_method	test
first_name	recurring_day	note
last_name	variable_recurring_day	created_at
email	automatic_login	updated_at
usage_plan_id	note	created_by
usage_minutes	created_at	updated_by
unlimited_usage_minutes	updated_at	signature
usage_expiration	created_by	partner
no_usage_expiration	updated_by	invoice_prefix
automatic_login	time_plan_id	integration
note	quota_plan_id	store_payment_methods
logged_in_at	usage_lifetime_time	live_url
created_at	absolute_usage_lifetime	pem
updated_at	unlimited_usage_lifetime	scratch
created_by	no_usage_lifetime	dup_timeout_seconds
updated_by	recurring_retry_grace_minutes
mb_up	recurring_fail_limit
mb_down	prorate_credit
pkts_up	permit_unpaid_ar
pkts_down	pms_server_id
usage_mb_up	lock_devices
usage_mb_down	scratch
unlimited_usage_mb_up	max_sessions
unlimited_usage_mb_down	max_devices
company	unlimited_devices
address1	unlimited_sessions
address2	usage_lifetime_time_unit
city	max_dedicated_ips
region	pms_guest_match_operator
zip	recurring_lifetime_time
country	recurring_lifetime_time_unit
phone	unlimited_recurring_lifetime
bill_at	sms_gateway_id
lock_version	validation_method
charge_attempted_at	validation_grace_minutes
lock_devices	max_party_devices
relative_usage_lifetime	unlimited_party_devices
scratch	upnp_enabled
portal_message	automatic_provision
max_devices	conference_id
unlimited_devices	ips_are_static
max_sessions	base_price
unlimited_sessions	vtas_are_static
max_dedicated_ips	manual_ar
account_group_id
email2
pre_shared_key
phone_validation_code
email_validation_code
phone_validated
email_validated
phone_validation_code_expires_at
email_validation_code_expires_at
max_party_devices
unlimited_party_devices
nt_password
upnp_enabled
automatic_provision
ips_are_static
guid
vtas_are_static
account_id
max_sub_accounts
unlimited_sub_accounts
approved_by
approved_at
pending_admin_approval
wispr_data
hide_from_operator

payment_method	merchant_transaction	coupon
id	id	id
account_id	account_id	usage_plan_id
active	payment_method_id	code
company	merchant_id	credit
address1	usage_plan_id	expires_at
address2	amount	note
city	currency	created_by
state	test	updated_by
zip	ip	created_at
country	mac	updated_at
phone	customer	batch
note	email	scratch
created_at	merchant_string	max_redemptions
updated_at	description	unlimited_redemptions
created_by	success
updated_by	response_yaml
scratch	created_at
customer_id	updated_at
card_id	created_by
nickname	updated_by
encrypted_cc_number	message
encrypted_cc_number_iv	authorization
encrypted_cc_expiration_month	hostname
encrypted_cc_expiration_month_iv	http_user_agent_id
encrypted_cc_expiration_year	account_group_id
encrypted_cc_expiration_year_iv	subscription_id
encrypted_first_name
encrypted_first_name_iv
encrypted_middle_name
encrypted_middle_name_iv
encrypted_last_name
encrypted_last_name_iv
email
cc_number
cc_expiration_month
cc_expiration_year
first_name
middle_name
last_name

login_session	ip_group	device_option
id	id	id
account_id	policy_id	name
radius_realm_id	name	active
login	priority	device_location
ip	note	domain_name
mac	created_at	ntp_server
expires_at	updated_at	time_zone
online	created_by	smtp_address
radius_acct_session_id	updated_by	rails_env
radius_response	scratch	note
radius_class_attribute		created_at
created_at		updated_at
updated_at		created_by
created_by		updated_by
updated_by		smtp_port
bytes_up		smtp_domain
bytes_down		smtp_username
pkts_up		smtp_password
pkts_down		cluster_node_id
usage_bytes_up		scratch
usage_bytes_down		log_rotate_hour
ldap_domain_id		log_rotate_count
radius_realm_server_id		ssh_port
ldap_domain_server_id		country_code
cluster_node_id		disable_hyperthreading
shared_credential_group_id		developer_mode
ip_group_id		sync_builtin_admins
account_group_id		delayed_job_workers
usage_plan_id		log_level
lock_version		max_forked_processes
hostname		soap_port
total_bytes_up		reboot_timestamp
total_bytes_down		reboot_time_zone
total_pkts_up		limit_sshd_start
total_pkts_down		limit_sshd_rate
radius_server_id		limit_sshd_full
radius_request		use_puma_threads
backend_login_at
http_user_agent_id
backend_login_seconds
portal_login_at
omniauth_profile_id
encrypted_password
encrypted_password_iv
conference_id
password

custom_email	transient_group_membership	time_trigger
id	id	id
name	ip_group_id	account_group_id
from	mac_group_id	name
subject	account_group_id	mon
body	account_id	tues
event	ip	wed
note	mac	thurs
created_by	reason	fri
updated_by	expires_at	sat
created_at	created_by	sun
updated_at	updated_by	start
send_to_account	created_at	end
scratch	updated_at	note
email_recipient	cluster_node_id	created_by
include_custom_reports_in_body	max_connections_trigger_id	updated_by
attachment_format	quota_trigger_id	created_at
custom_event	time_trigger_id	updated_at
delivery_method	snort_trigger_id	ip_group_id
sms_gateway_id	hostname	mac_group_id
reply_to	radius_group_id	scratch
	ldap_group_id	flush_states
	login_session_id	flush_dhcp
	log_hits_trigger_id	flush_arp
	flush_states	flush_vtas
	flush_dhcp	infrastructure_area_id
	flush_arp	previous_infrastructure_area_id
	flush_vtas	duration
	vulner_assess_trigger_id	current_dwell
		previous_dwell

log_hits_trigger	snort_trigger	max_connections_trigger
id	id	id
ip_group_id	ip_group_id	ip_group_id
mac_group_id	name	name
name	duration	max_connections
note	note	duration
log_file	created_by	note
duration	updated_by	created_by
max_hits	created_at	updated_by
window	updated_at	created_at
scratch	scratch	updated_at
created_by	mac_group_id	scratch
updated_by	flush_states	mac_group_id
created_at	flush_dhcp	flush_states
updated_at	flush_arp	flush_dhcp
flush_states	flush_vtas	flush_arp
flush_dhcp		flush_vtas
flush_arp		max_duration
flush_vtas		max_mb
		period
		active_or_expired
		max_duration_logic
		max_mb_logic

quota_trigger	health_notice	cluster_node
id	id	id
account_group_id	cluster_node_id	name
name	name	iui
usage_mb_down	short_message	database_password
usage_mb_down_unit	long_message	note
usage_mb_up	cured_short_message	created_by
usage_mb_up_unit	cured_long_message	updated_by
up_down_logic_operator	severity	created_at
note	cured_at	updated_at
created_by	created_at	ip
updated_by	updated_at	ssh_public_key
created_at	created_by	scratch
updated_at	updated_by	heartbeat_at
radius_group_id	fleet_node_id	data_plane_ha_timeout_seconds
ldap_group_id		node_mode
period		cluster_node_team_id
unlimited_period		wal_receiver_pid
duration		wal_receiver_status
unlimited_duration		wal_receiver_receive_start_lsn
scratch		wal_receiver_receive_start_tli
ip_group_id		wal_receiver_received_lsn
mac_group_id		wal_receiver_received_tli
flush_states		wal_receiver_latest_end_lsn
flush_dhcp		wal_receiver_slot_name
flush_arp		wal_receiver_sender_host
flush_vtas		wal_receiver_sender_port
		wal_receiver_last_msg_send_time
		wal_receiver_last_msg_receipt_time
		wal_receiver_latest_end_time
		op_cluster_node_id
		priority
		auto_registration
		permit_new_nodes
		auto_approve_new_nodes
		pending_auto_registration
		pending_approval
		control_plane_ha_backoff_seconds
		data_plane_ha_enabled
		upgrading
		enable_radius_proxy

aged_ar_penalty
id
name
amount
days
suspend_account
note
created_at
updated_at
created_by
updated_by
custom_email_id
scratch
record_type
days_type