firmware bug: radius request retransmission misses eap-state, freeradius responses with reject
Hello,
I found a firmware bug that causes 802.1x authentication failure for wired clients. Affected are all switch devices. The EAP device does not have this bug.
Affected are all my switches I do have:
Please see the following thread
https://community.tp-link.com/en/business/forum/topic/816396?replyId=1550434
for answer to these questions:
1. A screenshot of the Device page of your controller so we would know the models, versions of the Omada devices you are using;
2. the screenshots of the config page mentioned in the FAQ;
3. What IP address will the wireless clients get?
4. Are you using an external Radius server?
5. the topology of the network.
Information to reproduce the issue:
When there is load on the radius server, so that the switch experiences a timeout and does a retransmission then the 802.1x authentication fails.
When the timeout does not happen on the switch, then there is no retransmission and the 802.1x authentication is successful.
I show the tcpdump with the retransmission and then the freeradius debug output how it acts that leads to the authentication failure.
The tcpdump without the retransmission is identical except that the two retransmission packets are not there.
Here is the tcpdump output (10.0.0.3 is the switch, 10.1.2.1 is the freeradius server):
10:03:18.097139 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x01 length: 148
10:03:18.098793 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x01 length: 64
10:03:18.104598 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x02 length: 305
10:03:18.118119 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x02 length: 1064
10:03:18.121420 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x03 length: 150
10:03:18.123021 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x03 length: 1064
10:03:18.126122 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x04 length: 150
10:03:18.127202 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x04 length: 1064
10:03:18.130256 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x05 length: 150
10:03:18.131490 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x05 length: 1064
10:03:18.134736 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x06 length: 150
10:03:18.135895 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x06 length: 128
10:03:18.148085 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x07 length: 280
10:03:18.150682 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Challenge (11), id: 0x07 length: 119
10:03:18.153543 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x08 length: 227 <-- first request id 8
10:03:27.152999 IP 10.0.0.3.44864 > 10.1.2.1.radius: RADIUS, Access-Request (1), id: 0x09 length: 209 <-- retransmission id 9
10:03:28.154936 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Reject (3), id: 0x09 length: 38 <-- retransmission id 9 reject
10:03:30.354898 IP 10.1.2.1.radius > 10.0.0.3.44864: RADIUS, Access-Accept (2), id: 0x08 length: 61 <-- first request id 8 is accepted
The freeradius debug output with the packet ids 8 and 9.
This is the first request with id 8:
authentik-freeradius-1 | (7) Received Access-Request Id 8 from 10.0.0.3:47557 to 10.1.2.1:1812 length 227
authentik-freeradius-1 | (7) User-Name = "apple_lan_thatsme"
authentik-freeradius-1 | (7) EAP-Message = 0x020900531580000000491703030044fc65f797940844200121d6c214b4a943f011737e57d2eeeae303c0666a780b06e91ec17969d06d766156de5ab0dc4ee3d6ba2ed668e67021d2a2ce6bc9799c8a5759eb1f
authentik-freeradius-1 | (7) NAS-IP-Address = 10.0.0.3
authentik-freeradius-1 | (7) NAS-Port = 2
authentik-freeradius-1 | (7) NAS-Identifier = "DC6279CF8CB4"
authentik-freeradius-1 | (7) Service-Type = Framed-User
authentik-freeradius-1 | (7) Calling-Station-Id = "00-E0-4C-68-20-7E"
authentik-freeradius-1 | (7) NAS-Port-Type = Ethernet
Here comes the retransmission id 9
authentik-freeradius-1 | (8) Received Access-Request Id 9 from 10.0.0.3:47557 to 10.1.2.1:1812 length 209
authentik-freeradius-1 | (8) User-Name = "apple_lan_thatsme"
authentik-freeradius-1 | (8) EAP-Message = 0x020900531580000000491703030044fc65f797940844200121d6c214b4a943f011737e57d2eeeae303c0666a780b06e91ec17969d06d766156de5ab0dc4ee3d6ba2ed668e67021d2a2ce6bc9799c8a5759eb1f
authentik-freeradius-1 | (8) } # policy filter_username = notfound
authentik-freeradius-1 | (8) [preprocess] = ok
authentik-freeradius-1 | (8) [chap] = noop
authentik-freeradius-1 | (8) suffix: Checking for suffix after "@"
authentik-freeradius-1 | (8) suffix: No '@' in User-Name = "apple_lan_thatsme", looking up realm NULL
authentik-freeradius-1 | (8) suffix: No such realm "NULL"
authentik-freeradius-1 | (8) [suffix] = noop
authentik-freeradius-1 | (8) if (User-Name && !User-Password) {
authentik-freeradius-1 | (8) } # authorize = ok
authentik-freeradius-1 | (8) Found Auth-Type = eap
authentik-freeradius-1 | (8) # Executing group from file /opt/etc/raddb/sites-enabled/default
authentik-freeradius-1 | (8) authenticate {
authentik-freeradius-1 | (8) eap: ERROR: EAP requires the State attribute to work, but no State exists in the Access-Request packet.
!!This is the firmware bug in the retransmission packet as told by freeradius!!
authentik-freeradius-1 | (8) eap: ERROR: The RADIUS client is broken. No amount of changing FreeRADIUS will fix the RADIUS client.
authentik-freeradius-1 | (8) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request
authentik-freeradius-1 | (8) eap: Failed in handler
authentik-freeradius-1 | (8) [eap] = invalid
authentik-freeradius-1 | (8) } # authenticate = invalid
authentik-freeradius-1 | (8) Failed to authenticate the user
Freeradius gives up and denies the user as consequence.
authentik-freeradius-1 | (8) Using Post-Auth-Type Reject
authentik-freeradius-1 | (8) # Executing group from file /opt/etc/raddb/sites-enabled/default
authentik-freeradius-1 | (8) Post-Auth-Type REJECT {
authentik-freeradius-1 | (8) attr_filter.access_reject: EXPAND %{User-Name}
authentik-freeradius-1 | (8) attr_filter.access_reject: --> apple_lan_thatsme
authentik-freeradius-1 | (8) attr_filter.access_reject: Matched entry DEFAULT at line 11
authentik-freeradius-1 | (8) [attr_filter.access_reject] = updated
authentik-freeradius-1 | (8) eap: ERROR: EAP requires the State attribute to work, but no State exists in the Access-Request packet.
authentik-freeradius-1 | (8) eap: ERROR: The RADIUS client is broken. No amount of changing FreeRADIUS will fix the RADIUS client.
authentik-freeradius-1 | (8) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request
authentik-freeradius-1 | (8) eap: Failed to get handler, probably already removed, not inserting EAP-Failure
authentik-freeradius-1 | (8) [eap] = noop
authentik-freeradius-1 | (8) policy remove_reply_message_if_eap {
authentik-freeradius-1 | (8) if (&reply:EAP-Message && &reply:Reply-Message) {
authentik-freeradius-1 | (8) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
authentik-freeradius-1 | (8) else {
authentik-freeradius-1 | (8) [noop] = noop
authentik-freeradius-1 | (8) } # else = noop
authentik-freeradius-1 | (8) } # policy remove_reply_message_if_eap = noop
authentik-freeradius-1 | (8) Delaying response for 1.000000 seconds
authentik-freeradius-1 | Waking up in 0.3 seconds.
authentik-freeradius-1 | Waking up in 0.6 seconds.
authentik-freeradius-1 | (8) Sending delayed response
authentik-freeradius-1 | (8) Sent Access-Reject Id 9 from 10.1.2.1:1812 to 10.0.0.3:47557 length 38
Here the switch receives the reject that leads to the 802.1x authentication failure.
When the retransmission does not happen then the switch does not get the reject.
Here is the Accept response to the first request with id 8:
authentik-freeradius-1 | (7) Sent Access-Accept Id 8 from 10.1.2.1:1812 to 10.0.0.3:47557 length 61
authentik-freeradius-1 | (7) Framed-MTU += 994
authentik-freeradius-1 | (7) Tunnel-Type = VLAN
authentik-freeradius-1 | (7) Tunnel-Medium-Type = IEEE-802
authentik-freeradius-1 | (7) Tunnel-Private-Group-Id = "110"
But the switch already received the reject and the authentication failed.
When the retransmission does not happen then the switch accepts the client and the 802.1x authentication is sucessful.