Description Finn David 2024-01-05 16:03:30 CET

Dynamic VLAN assignment was enabled, assigning specific VLANs to particular groups, with VLAN 96 configured as the default VLAN. Manual WLAN logins work flawlessly, but during automatic Windows client logins, VLAN 1 (the native VLAN on the switch) gets assigned. Unifi is utilized for the WLAN infrastructure, also configured with VLAN 96 as the default VLAN. A GPO was tested with various configurations (GPO is attached to the ticket). Disabling the GPO and connecting manually correctly assigned the VLAN.

Following unsuccessful dynamic VLAN assignment via GPO for user authentication, computer authentication using EAP-TTLS was attempted, but the correct VLAN was still not transmitted. A test conducted with an access point from another manufacturer (MikroTik) succeeded, yet within the production environment using Unifi access points, it failed. Internet research revealed indications that when FreeRADIUS is employed with Unifi access points, a "tunneled reply" might be necessary to replicate information between the "inner" and "outer" tunnels.

The recommendations from the research advised using the configuration "use_tunneled_reply = yes" (or its successor in Freeradius versions above 3.0). Consequently, the corresponding blocks were uncommented in the files `/etc/freeradius/3.0/sites-available/inner-tunnel` and `/etc/univention/templates/files/etc/freeradius/3.0/sites-available/inner-tunnel`:


       #  Instead of "use_tunneled_reply", uncomment the
       #  next two "update" blocks.
       #
       update {
               &outer.session-state: += &reply:
       }

       #
       #  These attributes are for the inner session only.
       #  They MUST NOT be sent in the outer reply.
       #
       #  If you uncomment the previous block and leave
       #  this one commented out, WiFi WILL NOT WORK,
       #  because the client will get two MS-MPPE-keys
       #
       update outer.session-state {
               MS-MPPE-Encryption-Policy !* ANY
               MS-MPPE-Encryption-Types !* ANY
               MS-MPPE-Send-Key !* ANY
               MS-MPPE-Recv-Key !* ANY
               Message-Authenticator !* ANY
               EAP-Message !* ANY
               Proxy-State !* ANY
       }


Following this, the Freeradius service was restarted using "systemctl restart freeradius".

The modified sections included updates for the inner session to prevent conflicts and ensure proper WLAN connectivity. Despite these modifications, there was no impact on VLAN assignment.

Both the deprecated "use_tunneled_reply" and the current "outer_session" configuration have been tested.

Recent observations indicate that upon startup, the device initially receives the correct VLAN and subnet assignment. However, after a user logs in, the VLAN and subnet change (reverting to the native VLAN). Automatic VLAN assignment for users has also been enabled. This process functions properly when authenticating regularly on an endpoint device using access credentials.