Access-Challenge on proxied radius request on eduroam

[Alan DeKok]

On Oct 3, 2016, at 4:28 PM, Turner, Ryan H <rhturner at 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 at 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.