How to force EAP-Identity Request sending after EAP START
Hi experts, I would appreciate your help, I am not that familiar with freeradius. I am using FreeRADIUS Version 3.0.20. I do not success Radius server to initiate EAP-Identity Request after START as stated in https://wiki.freeradius.org/modules/Rlm_eap#How_Freeradius_can_handle_EAPSTA... I get a reject reject, it seems something more is needed partial log: (0) eap: Got EAP_START message (0) [eap] = handled (0) } # authorize = handled (0) There was no response configured: rejecting request Kind regards, Javier
On May 1, 2020, at 8:46 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I would appreciate your help, I am not that familiar with freeradius.
That's fine.
I am using FreeRADIUS Version 3.0.20. I do not success Radius server to initiate EAP-Identity Request after START as stated in
https://wiki.freeradius.org/modules/Rlm_eap#How_Freeradius_can_handle_EAPSTA... I get a reject reject, it seems something more is needed partial log:
Full logs are generally preferred.
(0) eap: Got EAP_START message (0) [eap] = handled (0) } # authorize = handled (0) There was no response configured: rejecting request
Hmm... I haven't seen that. What did you change? The default configuration works... Alan DeKok.
Thanks a lot Alan, sometime ago I commented some options in eap.conf to leave just eap-mschapv2, and also applied filter attr_filter.access_challenge.post-auth to remove some attributes in access-challenge. Also think I enabled eap in authorize/auth (i think under /etc/raddb/sites-enabled/inner-tunnel). I do not think I did more. EAP was working, EAP-start is a new use case I need to support. I have removed the access-challenge filter to check but have the same result. The full debug of the access-attmpt (0) Received Access-Request Id 5 from 10.0.87.205:64385 to 192.168.99.9:1812 length 152 (0) User-Name = "swan" (0) Acct-Session-Id = "172.172.172.40-172.20.182.6:4500-1588347078" (0) Calling-Station-Id = "172.20.182.6:4500" (0) Called-Station-Id = "172.172.172.40" (0) NAS-Port-Id = "tunnel-1.public:40" (0) NAS-Identifier = "vBNG" (0) EAP-Message = 0x (0) Message-Authenticator = 0x8cdfcf1a44d32676220a00a478daea33 (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "swan", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: Got EAP_START message (0) [eap] = handled (0) } # authorize = handled (0) There was no response configured: rejecting request (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> swan (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Waking up in 0.6 seconds. (0) Sending delayed response (0) Sent Access-Reject Id 5 from 192.168.99.9:1812 to 10.0.87.205:64385 length 27 (0) EAP-Message = 0x0100000501 Waking up in 3.9 seconds. (0) Cleaning up request packet ID 5 with timestamp +15 Ready to process requests Not sure if you refer to this debug. Kind regards, Javi En viernes, 1 de mayo de 2020 15:27:57 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 1, 2020, at 8:46 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I would appreciate your help, I am not that familiar with freeradius.
That's fine.
I am using FreeRADIUS Version 3.0.20. I do not success Radius server to initiate EAP-Identity Request after START as stated in
https://wiki.freeradius.org/modules/Rlm_eap#How_Freeradius_can_handle_EAPSTA... I get a reject reject, it seems something more is needed partial log:
Full logs are generally preferred.
(0) eap: Got EAP_START message (0) [eap] = handled (0) } # authorize = handled (0) There was no response configured: rejecting request
Hmm... I haven't seen that. What did you change? The default configuration works... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 1, 2020, at 11:48 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks a lot Alan, sometime ago I commented some options in eap.conf to leave just eap-mschapv2, and also applied filter attr_filter.access_challenge.post-auth to remove some attributes in access-challenge. Also think I enabled eap in authorize/auth (i think under /etc/raddb/sites-enabled/inner-tunnel). I do not think I did more. EAP was working, EAP-start is a new use case I need to support.
OK.
I have removed the access-challenge filter to check but have the same result. The full debug of the access-attmpt (0) Received Access-Request Id 5 from 10.0.87.205:64385 to 192.168.99.9:1812 length 152 (0) User-Name = "swan" (0) Acct-Session-Id = "172.172.172.40-172.20.182.6:4500-1588347078" (0) Calling-Station-Id = "172.20.182.6:4500" (0) Called-Station-Id = "172.172.172.40" (0) NAS-Port-Id = "tunnel-1.public:40" (0) NAS-Identifier = "vBNG" (0) EAP-Message = 0x
Yeah, that's a problem. The EAP peer MUST NOT send an empty EAP-Message attribute. See RFC 3579 Section 3.1. It should instead send 2 byte EAP start message. Or, more commonly, an EAP Identity. Which is what 99.999% of EAP peers do. It's not clear why you need to support EAP-Start. Perhaps explaining that may help.
Not sure if you refer to this debug.
Yes. I've pushed a fix, which will be in the next release. Alan DeKok.
Thanks Alan, I know the RFC, for start there is an exception the RFC states in 2.1EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). the server seems to recognize it as EAP-start according to the log This use case just is required to interoperate with a VPN server that do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2). In that case, the VPN server needs to tell someway to the Radius to initiate an EAP dialogue with the end customer. Using stat message is suggested also in RFC 3579 section 2.1 Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start.... Kind regards, Javier En viernes, 1 de mayo de 2020 18:02:21 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 1, 2020, at 11:48 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks a lot Alan, sometime ago I commented some options in eap.conf to leave just eap-mschapv2, and also applied filter attr_filter.access_challenge.post-auth to remove some attributes in access-challenge. Also think I enabled eap in authorize/auth (i think under /etc/raddb/sites-enabled/inner-tunnel). I do not think I did more. EAP was working, EAP-start is a new use case I need to support.
OK.
I have removed the access-challenge filter to check but have the same result. The full debug of the access-attmpt (0) Received Access-Request Id 5 from 10.0.87.205:64385 to 192.168.99.9:1812 length 152 (0) User-Name = "swan" (0) Acct-Session-Id = "172.172.172.40-172.20.182.6:4500-1588347078" (0) Calling-Station-Id = "172.20.182.6:4500" (0) Called-Station-Id = "172.172.172.40" (0) NAS-Port-Id = "tunnel-1.public:40" (0) NAS-Identifier = "vBNG" (0) EAP-Message = 0x
Yeah, that's a problem. The EAP peer MUST NOT send an empty EAP-Message attribute. See RFC 3579 Section 3.1. It should instead send 2 byte EAP start message. Or, more commonly, an EAP Identity. Which is what 99.999% of EAP peers do. It's not clear why you need to support EAP-Start. Perhaps explaining that may help.
Not sure if you refer to this debug.
Yes. I've pushed a fix, which will be in the next release. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 1, 2020, at 12:37 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks Alan, I know the RFC, for start there is an exception the RFC states in 2.1EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data).
Except that the later definition of EAP-Message indicates that's wrong. And RFC 2865 says that RADIUS attributes should never be sent with zero data.
the server seems to recognize it as EAP-start according to the log
Yes. Because there are many broken clients.
This use case just is required to interoperate with a VPN server that do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2).
Yes.
In that case, the VPN server needs to tell someway to the Radius to initiate an EAP dialogue with the end customer. Using stat message is suggested also in RFC 3579 section 2.1
Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start....
Sure. See the patch for a full fix. Alan DeKok.
Thanks a lot Alan En viernes, 1 de mayo de 2020 19:00:31 CEST, Alan DeKok <aland@deployingradius.com> escribió: On May 1, 2020, at 12:37 PM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks Alan, I know the RFC, for start there is an exception the RFC states in 2.1EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data).
Except that the later definition of EAP-Message indicates that's wrong. And RFC 2865 says that RADIUS attributes should never be sent with zero data.
the server seems to recognize it as EAP-start according to the log
Yes. Because there are many broken clients.
This use case just is required to interoperate with a VPN server that do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2).
Yes.
In that case, the VPN server needs to tell someway to the Radius to initiate an EAP dialogue with the end customer. Using stat message is suggested also in RFC 3579 section 2.1
Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start....
Sure. See the patch for a full fix. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
JAVIER SANDOVAL