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...