Hi, I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends: Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215" The debug goes on: Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled The next request from the switch is: Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f and then the RADIUS server complains: Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here? Thanks for any hints. Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends:
Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215"
That's weird.
The debug goes on:
Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled
The next request from the switch is:
Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f
That's weirder. :(
and then the RADIUS server complains:
Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler
Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here?
The switch is *supposed* to be sane. See RFC 3579 Section 2.1: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. i.e. the switch is *not* supposed to change the User-Name in the middle of an EAP session. My $0.02 is to post the full debug output to check. But also to "name and shame" the switch vendor. Then, throw it in the garbage and buy one that works. Alan DeKok.
I've seen similiar behaviour on some ubiquiti switches, when port had "MAC authentication bypass" enabled and connected client was 802.1x aware (e.g. windows PC with eap/peap). What would sometimes happen is that when client for whatever reason didn't provide identity fast enough (depending on switch timeouts for 802.1x), and port had mac-auth-bypass enabled ,switch goes on with MAC-auth (as seen in the first acces-requeste), but then later connected client cathes on and sends it's reply to EAP-request-identity, so switch changes user-name. Maybe it's similar scenario? Check if MAC authentication bypass is enabled on Your switch's port or not (depending what You wish to achieve). Regards, Kacper W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends:
Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215" That's weird.
The debug goes on:
Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled
The next request from the switch is:
Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f That's weirder. :(
and then the RADIUS server complains:
Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler
Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here? The switch is *supposed* to be sane. See RFC 3579 Section 2.1:
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.
i.e. the switch is *not* supposed to change the User-Name in the middle of an EAP session.
My $0.02 is to post the full debug output to check. But also to "name and shame" the switch vendor. Then, throw it in the garbage and buy one that works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast. https://www.avast.com/antivirus
On 12.01.21 18:18, Kacper Wirski wrote:
I've seen similiar behaviour on some ubiquiti switches, when port had "MAC authentication bypass" enabled and connected client was 802.1x aware (e.g. windows PC with eap/peap).
What would sometimes happen is that when client for whatever reason didn't provide identity fast enough (depending on switch timeouts for 802.1x), and port had mac-auth-bypass enabled ,switch goes on with MAC-auth (as seen in the first acces-requeste), but then later connected client cathes on and sends it's reply to EAP-request-identity, so switch changes user-name.
Maybe it's similar scenario? Check if MAC authentication bypass is enabled on Your switch's port or not (depending what You wish to achieve).
Regards,
Kacper
Yes, exactly the same vendor and scenario. So it seems to be a bug in the switch software. Do you know if there is any chance to change the timing behaviour of the switch, perhaps to wait longer for the host to answer the 802.1x request?
W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends:
Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215" That's weird.
The debug goes on:
Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled
The next request from the switch is:
Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f That's weirder. :(
and then the RADIUS server complains:
Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler
Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here? The switch is *supposed* to be sane. See RFC 3579 Section 2.1:
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.
i.e. the switch is *not* supposed to change the User-Name in the middle of an EAP session.
My $0.02 is to post the full debug output to check. But also to "name and shame" the switch vendor. Then, throw it in the garbage and buy one that works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
I enable MAC-auth only on switch ports that are used by 802.1x-unaware devices. 802.1x makes most sense on ports that are facing clients and I can easily distinguish which ports will be used with mac-auth and which by 802.1x-aware, so I just skip the issue. If you for some reason need to have MAB enabled on every switch port and still connect 802.1x-aware device You can maybe try messing with guest-vlan timeout - you need to set a guest-vlan and guest-vlan-period, but not too high value, so that it gives enough time for the client to boot up and start sending EAP frames and authenticate, without switch "taking matters in own hands" and going directly with MAB. guest-vlan-period - The time, in seconds, for which the authenticator waits to see if any EAPOL packets are received on a port before authorizing the port and placing the port in the guest vlan (if configured). The guest vlan timer is only relevant when guest vlan has been configured on that specific port. on edgemax switches with CLI it's something like: configure interface 0/1 [or other] dot1x timeout guest-vlan-period 30 dot1x guest-vlan [some-vlan - it can be probably something bogus, just for the guest-vlan-period to work. But I'd rather recommend dedicating ports for MAB and just disable it on everything else. Also 802.1x in ubiquiti switches isn't perfect, but it's gotten way better in recent updates and I had some good interactions with ubiquiti support - even got some early alpha/beta patches to help with my specific issues. Regards, Kacper W dniu 12.01.2021 o 19:55, Michael Schwartzkopff pisze:
On 12.01.21 18:18, Kacper Wirski wrote:
I've seen similiar behaviour on some ubiquiti switches, when port had "MAC authentication bypass" enabled and connected client was 802.1x aware (e.g. windows PC with eap/peap).
What would sometimes happen is that when client for whatever reason didn't provide identity fast enough (depending on switch timeouts for 802.1x), and port had mac-auth-bypass enabled ,switch goes on with MAC-auth (as seen in the first acces-requeste), but then later connected client cathes on and sends it's reply to EAP-request-identity, so switch changes user-name.
Maybe it's similar scenario? Check if MAC authentication bypass is enabled on Your switch's port or not (depending what You wish to achieve).
Regards,
Kacper
Yes, exactly the same vendor and scenario. So it seems to be a bug in the switch software. Do you know if there is any chance to change the timing behaviour of the switch, perhaps to wait longer for the host to answer the 802.1x request?
W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends:
Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215" That's weird.
The debug goes on:
Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled
The next request from the switch is:
Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f That's weirder. :(
and then the RADIUS server complains:
Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler
Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here? The switch is *supposed* to be sane. See RFC 3579 Section 2.1:
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.
i.e. the switch is *not* supposed to change the User-Name in the middle of an EAP session.
My $0.02 is to post the full debug output to check. But also to "name and shame" the switch vendor. Then, throw it in the garbage and buy one that works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Mit freundlichen Grüßen,
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast. https://www.avast.com/antivirus
On Jan 12, 2021, at 1:55 PM, Michael Schwartzkopff <ms@sys4.de> wrote:
Yes, exactly the same vendor and scenario. So it seems to be a bug in the switch software. Do you know if there is any chance to change the timing behaviour of the switch, perhaps to wait longer for the host to answer the 802.1x request?
Ubiquiti is generally pretty good, and responsive. I've got a fair bit of their gear. But yes, it's a bug. Once EAP starts, the User-Name *must not* change. But it's OK to use a different User-Name for MAB and EAP. Alan DeKok.
participants (3)
-
Alan DeKok -
Kacper Wirski -
Michael Schwartzkopff