Access-Challenge on proxied radius request on eduroam
I am prepared for a lashing, because I am sure I have missed something stupid.. We are running 2.2.8 (yes, I know we should be on 3.X. My systems architect quit and we are hiring another one and one of the first projects will be to get to 3.X. If you want to apply, message me). Eduroam is our primary SSID on campus and we run EAP-TLS. We authenticate 10s of thousands of people on our campus, and people at foreign campuses, every single day. However, there is one school nearby where neither our users can authenticate on their network (using eduroam which proxies back to our campus) nor can their users authenticate on ours. I am totally miffed. If I do a radius -XXX on an attempt (UNC person is at foreign institution connecting which proxies the auth packet to us), this is what I see on our local freeradius server: (Summary: we are sending an access challenge to the user who connects perfectly fine on our own network, but fails to connect on their network- what is going on???) rad_recv: Access-Request packet from host 152.2.X.X port 1814, id=0, length=276 User-Name = "username_removed@unc.edu" NAS-IP-Address = 10.229.9.1 NAS-Port = 0 NAS-Identifier = "10.229.9.1" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "mac_address_removed" Called-Station-Id = "001A1E00ED18" Service-Type = Framed-User Framed-MTU = 1100 EAP-Message = 0x020800060d00 Aruba-Essid-Name = "eduroam" Aruba-Location-Id = "aEtc3-W" Aruba-AP-Group = "ncssm-hi-avail-hi-density-ap-group" Aruba-Device-Type = "OS X" Message-Authenticator = 0x7afdd181fbc9ca389829bce95736da1f State = 0x16deaa5213d6a791b4d184b49f08d1c8 Vendor-9048-Attr-0 = 0x50726f786965642d42793d544c5253322e656475726f616d2e7573 Proxy-State = 0x313937 Mon Oct 3 16:12:29 2016 : Info: # Executing section authorize from file /opt/unc/freeradius-2.2.8/root/etc/raddb/sites-enabled/default Mon Oct 3 16:12:29 2016 : Info: +group authorize { Mon Oct 3 16:12:29 2016 : Info: ++[preprocess] = ok Mon Oct 3 16:12:29 2016 : Info: ++[chap] = noop Mon Oct 3 16:12:29 2016 : Info: ++[mschap] = noop Mon Oct 3 16:12:29 2016 : Info: ++[digest] = noop Mon Oct 3 16:12:29 2016 : Info: [suffix] Looking up realm "unc.edu" for User-Name = "username_removed@unc.edu" Mon Oct 3 16:12:29 2016 : Info: [suffix] Found realm "unc.edu" Mon Oct 3 16:12:29 2016 : Info: [suffix] Adding Realm = "unc.edu" Mon Oct 3 16:12:29 2016 : Info: [suffix] Authentication realm is LOCAL. Mon Oct 3 16:12:29 2016 : Info: ++[suffix] = ok Mon Oct 3 16:12:29 2016 : Info: [eap] EAP packet type response id 8 length 6 Mon Oct 3 16:12:29 2016 : Info: [eap] No EAP Start, assuming it's an on-going EAP conversation Mon Oct 3 16:12:29 2016 : Info: ++[eap] = updated Mon Oct 3 16:12:29 2016 : Info: [files] users: Matched entry DEFAULT at line 42 Mon Oct 3 16:12:29 2016 : Info: ++[files] = ok Mon Oct 3 16:12:29 2016 : Info: ++[expiration] = noop Mon Oct 3 16:12:29 2016 : Info: ++[logintime] = noop Mon Oct 3 16:12:29 2016 : Info: ++[pap] = noop Mon Oct 3 16:12:29 2016 : Info: +} # group authorize = updated Mon Oct 3 16:12:29 2016 : Info: Found Auth-Type = EAP Mon Oct 3 16:12:29 2016 : Info: # Executing group from file /opt/unc/freeradius-2.2.8/root/etc/raddb/sites-enabled/default Mon Oct 3 16:12:29 2016 : Info: +group authenticate { Mon Oct 3 16:12:29 2016 : Info: [eap] Request found, released from the list Mon Oct 3 16:12:29 2016 : Info: [eap] EAP/tls Mon Oct 3 16:12:29 2016 : Info: [eap] processing type tls Mon Oct 3 16:12:29 2016 : Info: [tls] Authenticate Mon Oct 3 16:12:29 2016 : Info: [tls] processing EAP-TLS Mon Oct 3 16:12:29 2016 : Info: [tls] Received TLS ACK Mon Oct 3 16:12:29 2016 : Info: [tls] ACK handshake fragment handler Mon Oct 3 16:12:29 2016 : Info: [tls] eaptls_verify returned 1 Mon Oct 3 16:12:29 2016 : Info: [tls] eaptls_process returned 13 Mon Oct 3 16:12:29 2016 : Info: ++[eap] = handled Mon Oct 3 16:12:29 2016 : Info: +} # group authenticate = handled Sending Access-Challenge of id 0 to 152.2.X.X port 1814 EAP-Message = 0x010904000dc0000016d755040313056d736361310078307631133011060a0992268993f22c640119160365647531133011060a0992268993f22c6401191603756e6331123010060a0992268993f22c64011916026164313630340603550403132d556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c2053756234003b3039313730350603550403132e556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c20526f6f74330078307631133011060a0992268993f22c640119160365647531133011060a0992268993f22c6401191603756e6331123010 EAP-Message = 0x060a0992268993f22c64011916026164313630340603550403132d556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c205375623300b73081b4310b30090603550406130255533110300e060355040813074172697a6f6e61311330110603550407130a53636f74747364616c65311a3018060355040a1311476f44616464792e636f6d2c20496e632e312d302b060355040b1324687474703a2f2f63657274732e676f64616464792e636f6d2f7265706f7369746f72792f313330310603550403132a476f2044616464792053656375726520436572746966696361746520417574686f7269747920 Mon Oct 3 16:12:29 2016 : Info: ++[files] = ok Mon Oct 3 16:12:29 2016 : Info: ++[expiration] = noop Mon Oct 3 16:12:29 2016 : Info: ++[logintime] = noop Mon Oct 3 16:12:29 2016 : Info: ++[pap] = noop Mon Oct 3 16:12:29 2016 : Info: +} # group authorize = updated Mon Oct 3 16:12:29 2016 : Info: Found Auth-Type = EAP Mon Oct 3 16:12:29 2016 : Info: # Executing group from file /opt/unc/freeradius-2.2.8/root/etc/raddb/sites-enabled/default Mon Oct 3 16:12:29 2016 : Info: +group authenticate { Mon Oct 3 16:12:29 2016 : Info: [eap] Request found, released from the list Mon Oct 3 16:12:29 2016 : Info: [eap] EAP/tls Mon Oct 3 16:12:29 2016 : Info: [eap] processing type tls Mon Oct 3 16:12:29 2016 : Info: [tls] Authenticate Mon Oct 3 16:12:29 2016 : Info: [tls] processing EAP-TLS Mon Oct 3 16:12:29 2016 : Info: [tls] Received TLS ACK Mon Oct 3 16:12:29 2016 : Info: [tls] ACK handshake fragment handler Mon Oct 3 16:12:29 2016 : Info: [tls] eaptls_verify returned 1 Mon Oct 3 16:12:29 2016 : Info: [tls] eaptls_process returned 13 Mon Oct 3 16:12:29 2016 : Info: ++[eap] = handled Mon Oct 3 16:12:29 2016 : Info: +} # group authenticate = handled Sending Access-Challenge of id 0 to 152.2.X.X port 1814 EAP-Message = 0x010904000dc0000016d755040313056d736361310078307631133011060a0992268993f22c640119160365647531133011060a0992268993f22c6401191603756e6331123010060a0992268993f22c64011916026164313630340603550403132d556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c2053756234003b3039313730350603550403132e556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c20526f6f74330078307631133011060a0992268993f22c640119160365647531133011060a0992268993f22c6401191603756e6331123010 EAP-Message = 0x060a0992268993f22c64011916026164313630340603550403132d556e6976657273697479206f66204e6f727468204361726f6c696e612043686170656c2048696c6c205375623300b73081b4310b30090603550406130255533110300e060355040813074172697a6f6e61311330110603550407130a53636f74747364616c65311a3018060355040a1311476f44616464792e636f6d2c20496e632e312d302b060355040b1324687474703a2f2f63657274732e676f64616464792e636f6d2f7265706f7369746f72792f313330310603550403132a476f2044616464792053656375726520436572746966696361746520417574686f7269747920 EAP-Message = 0x2d2047320086308183310b30090603550406130255533110300e060355040813074172697a6f6e61311330110603550407130a53636f74747364616c65311a3018060355040a1311476f44616464792e636f6d2c20496e632e3131302f06035504031328476f20446164647920526f6f7420436572746966696361746520417574686f72697479202d20473200653063310b30090603550406130255533121301f060355040a131854686520476f2044616464792047726f75702c20496e632e3131302f060355040b1328476f20446164647920436c61737320322043657274696669636174696f6e20417574686f7269747900cd3081ca310b300906 EAP-Message = 0x03550406130255533110300e060355040813074172697a6f6e61311330110603550407130a53636f74747364616c65311a3018060355040a1311476f44616464792e636f6d2c20496e632e31333031060355040b132a687474703a2f2f6365727469666963617465732e676f64616464792e636f6d2f7265706f7369746f72793130302e06035504031327476f204461646479205365637572652043657274696669636174696f6e20417574686f726974793111300f06035504051308303739363932383701423082013e3136303406035504030c2d554e432d5365637572652047756573742041636365737320436572746966696361746520417574 EAP-Message = 0x686f72697479313830360603 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x16deaa5210d7a791b4d184b49f08d1c8 Proxy-State = 0x313937 Mon Oct 3 16:12:29 2016 : Info: Finished request 888. Mon Oct 3 16:12:29 2016 : Debug: Going to the next request Mon Oct 3 16:12:29 2016 : Debug: Waking up in 0.3 seconds. Ryan Turner Manager of Network Operations ITS Communication Technologies The University of North Carolina at Chapel Hill r@unc.edu<mailto:r@unc.edu> +1 919 445 0113 Office +1 919 274 7926 Mobile
On Oct 3, 2016, at 4:28 PM, Turner, Ryan H <rhturner@email.unc.edu> wrote:
Eduroam is our primary SSID on campus and we run EAP-TLS. We authenticate 10s of thousands of people on our campus, and people at foreign campuses, every single day. However, there is one school nearby where neither our users can authenticate on their network (using eduroam which proxies back to our campus) nor can their users authenticate on ours. I am totally miffed. If I do a radius -XXX on an attempt (UNC person is at foreign institution connecting which proxies the auth packet to us), this is what I see on our local freeradius server:
Can you post what you see when one of their users logs into your network?
(Summary: we are sending an access challenge to the user who connects perfectly fine on our own network, but fails to connect on their network- what is going on???)
It's normal for EAP to send challenges. The problem comes when the other side gets the challenge, and.... does nothing else. it's *supposed* to reply with the next step.
rad_recv: Access-Request packet from host 152.2.X.X port 1814, id=0, length=276 User-Name = "username_removed@unc.edu" NAS-IP-Address = 10.229.9.1 NAS-Port = 0 NAS-Identifier = "10.229.9.1" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "mac_address_removed" Called-Station-Id = "001A1E00ED18" Service-Type = Framed-User Framed-MTU = 1100
That's one guess as to what's going wrong. Maybe the other end is playing games with MTU? The EAP packets *have* to fit within MTU. If they don't, there's no way for the end user system to signal that. Maybe setting the MTU to something smaller, like 900 would help?
EAP-Message = 0x020800060d00 Aruba-Essid-Name = "eduroam" Aruba-Location-Id = "aEtc3-W" Aruba-AP-Group = "ncssm-hi-avail-hi-density-ap-group" Aruba-Device-Type = "OS X" Message-Authenticator = 0x7afdd181fbc9ca389829bce95736da1f State = 0x16deaa5213d6a791b4d184b49f08d1c8 Vendor-9048-Attr-0 = 0x50726f786965642d42793d544c5253322e656475726f616d2e7573
Ugh. Radiator. I dislike that. And attribute 0? Really? That's not nice. The contents of this attribute is "Proxied-By=TLRS2.eduroam.us". Which is cute, but not terribly useful. Honestly... these issues are magical to track down. You will likely *both* need to set up test RADIUS servers where you can send packets, to see what the heck is going on. Or, convince them to use FreeRADIUS. Which works. :) Alan DeKok.
Alan, Thank you. Would you suggest setting a fragment_size to something like 900 in the eap.conf file? The fragment size is currently commented out. Getting them to change won't work. They are using Aruba Clearpass. And when I can run debug and get lots of things through the command line, the GUI based Clearpass doesn't seem to be very deep with diagnostics. You are confirming what I am seeing, however. We are sending them back a message and they aren't replying. Thanks, Ryan -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+rhturner=email.unc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Monday, October 3, 2016 4:44 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Access-Challenge on proxied radius request on eduroam On Oct 3, 2016, at 4:28 PM, Turner, Ryan H <rhturner@email.unc.edu> wrote:
Eduroam is our primary SSID on campus and we run EAP-TLS. We authenticate 10s of thousands of people on our campus, and people at foreign campuses, every single day. However, there is one school nearby where neither our users can authenticate on their network (using eduroam which proxies back to our campus) nor can their users authenticate on ours. I am totally miffed. If I do a radius -XXX on an attempt (UNC person is at foreign institution connecting which proxies the auth packet to us), this is what I see on our local freeradius server:
Can you post what you see when one of their users logs into your network?
(Summary: we are sending an access challenge to the user who connects perfectly fine on our own network, but fails to connect on their network- what is going on???)
It's normal for EAP to send challenges. The problem comes when the other side gets the challenge, and.... does nothing else. it's *supposed* to reply with the next step.
rad_recv: Access-Request packet from host 152.2.X.X port 1814, id=0, length=276 User-Name = "username_removed@unc.edu" NAS-IP-Address = 10.229.9.1 NAS-Port = 0 NAS-Identifier = "10.229.9.1" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "mac_address_removed" Called-Station-Id = "001A1E00ED18" Service-Type = Framed-User Framed-MTU = 1100
That's one guess as to what's going wrong. Maybe the other end is playing games with MTU? The EAP packets *have* to fit within MTU. If they don't, there's no way for the end user system to signal that. Maybe setting the MTU to something smaller, like 900 would help?
EAP-Message = 0x020800060d00 Aruba-Essid-Name = "eduroam" Aruba-Location-Id = "aEtc3-W" Aruba-AP-Group = "ncssm-hi-avail-hi-density-ap-group" Aruba-Device-Type = "OS X" Message-Authenticator = 0x7afdd181fbc9ca389829bce95736da1f State = 0x16deaa5213d6a791b4d184b49f08d1c8 Vendor-9048-Attr-0 = 0x50726f786965642d42793d544c5253322e656475726f616d2e7573
Ugh. Radiator. I dislike that. And attribute 0? Really? That's not nice. The contents of this attribute is "Proxied-By=TLRS2.eduroam.us". Which is cute, but not terribly useful. Honestly... these issues are magical to track down. You will likely *both* need to set up test RADIUS servers where you can send packets, to see what the heck is going on. Or, convince them to use FreeRADIUS. Which works. :) Alan DeKok. - List info/subscribe/unsubscribe? See https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradi...
On Oct 3, 2016, at 5:04 PM, Turner, Ryan H <rhturner@email.unc.edu> wrote:
Thank you. Would you suggest setting a fragment_size to something like 900 in the eap.conf file? The fragment size is currently commented out.
It might help.
Getting them to change won't work. They are using Aruba Clearpass. And when I can run debug and get lots of things through the command line, the GUI based Clearpass doesn't seem to be very deep with diagnostics.
Hmm... that's based on a very old version of FreeRADIUS. But it should sort of work. Alan DeKok.
Thanks!! I'll send the logs of their user connection tomorrow. Ryan Turner Manager of Network Operations, ITS The University of North Carolina at Chapel Hill +1 919 274 7926 Mobile +1 919 445 0113 Office On Oct 3, 2016, at 5:12 PM, Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote: On Oct 3, 2016, at 5:04 PM, Turner, Ryan H <rhturner@email.unc.edu<mailto:rhturner@email.unc.edu>> wrote: Thank you. Would you suggest setting a fragment_size to something like 900 in the eap.conf file? The fragment size is currently commented out. It might help. Getting them to change won't work. They are using Aruba Clearpass. And when I can run debug and get lots of things through the command line, the GUI based Clearpass doesn't seem to be very deep with diagnostics. Hmm... that's based on a very old version of FreeRADIUS. But it should sort of work. Alan DeKok. - List info/subscribe/unsubscribe? See https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradi...
Hi,
Vendor-9048-Attr-0 = 0x50726f786965642d42793d544c5253322e656475726f616d2e7573
Ugh. Radiator. I dislike that. And attribute 0? Really? That's not nice.
I believe thats fixed in latest release (the use of '0')
The contents of this attribute is "Proxied-By=TLRS2.eduroam.us". Which is cute, but not terribly useful.
adding these random non standard attributes can cause problems with more sensitive RADIUS servers too... :/ (one particular platform silently drops RADIUS datagrams as 'malformed' rather than just ignoring the value...) alan
Hi,
I am prepared for a lashing, because I am sure I have missed something stupid..
yes. you have forgotten the other peoples system ;-)
We are running 2.2.8 (yes, I know we should be on 3.X. My systems architect quit and we are hiring another one and one of the first projects will be to get to 3.X. If you want to apply, message me).
;-)
Eduroam is our primary SSID on campus and we run EAP-TLS. We authenticate 10s of thousands of people on our campus, and people at foreign campuses, every single day. However, there is one school nearby where neither our users can authenticate on their network (using eduroam which proxies back to our campus) nor can their users authenticate on ours. I am totally miffed. If I do a radius -XXX on an attempt (UNC person is at foreign institution connecting which proxies the auth packet to us), this is what I see on our local freeradius server:
your users work everywhere but at that one place....other people can visit you ...but not if they are from that place. at this point I see a place to be looking. it could be several reasons.... eg MTU needing to be advertised in the RADIUS datagram - you can adjust the maximum reply size in eap.conf - but really oyou should not need to go lower than around 1240. it could be that their firewall in front of their systems is dropping fragmented UDP. you use EAP-TLS - thats a prime candidate for this as the server cert and client cert (and intermediates) are being chucked around) - big RADIUS datagrams on small pipes = it gets fragmented. legitimately. alan
Many thanks. I have passed this along. The framed-MTU in the request... I haven't looked at this field more closely in other auths. Is this an administrative request being sent from their system to limit the size of the response? I believe I have read that freeRadius doesn't honor these. Ryan -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+rhturner=email.unc.edu@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Monday, October 3, 2016 6:12 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Access-Challenge on proxied radius request on eduroam Hi,
I am prepared for a lashing, because I am sure I have missed something stupid..
yes. you have forgotten the other peoples system ;-)
We are running 2.2.8 (yes, I know we should be on 3.X. My systems architect quit and we are hiring another one and one of the first projects will be to get to 3.X. If you want to apply, message me).
;-)
Eduroam is our primary SSID on campus and we run EAP-TLS. We authenticate 10s of thousands of people on our campus, and people at foreign campuses, every single day. However, there is one school nearby where neither our users can authenticate on their network (using eduroam which proxies back to our campus) nor can their users authenticate on ours. I am totally miffed. If I do a radius -XXX on an attempt (UNC person is at foreign institution connecting which proxies the auth packet to us), this is what I see on our local freeradius server:
your users work everywhere but at that one place....other people can visit you ...but not if they are from that place. at this point I see a place to be looking. it could be several reasons.... eg MTU needing to be advertised in the RADIUS datagram - you can adjust the maximum reply size in eap.conf - but really oyou should not need to go lower than around 1240. it could be that their firewall in front of their systems is dropping fragmented UDP. you use EAP-TLS - thats a prime candidate for this as the server cert and client cert (and intermediates) are being chucked around) - big RADIUS datagrams on small pipes = it gets fragmented. legitimately. alan - List info/subscribe/unsubscribe? See https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradi...
On Oct 4, 2016, at 9:56 AM, Turner, Ryan H <rhturner@email.unc.edu> wrote: The framed-MTU in the request... I haven't looked at this field more closely in other auths. Is this an administrative request being sent from their system to limit the size of the response?
It is the Ethernet MTU on the side of the client PC. EAP packets *must* be smaller than this.
I believe I have read that freeRadius doesn't honor these.
Yes, it does. It's followed MTU for well over a decade. Alan DeKok.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Turner, Ryan H