Remote users - proxying fails - NPS timeout

[Alan DeKok]

On Aug 18, 2017, at 1:37 AM, John Horne <john.horne at plymouth.ac.uk> wrote:
> However, I have updated freeradius to 3.0.15 (locally built RPM) on one of the
> servers. Whilst the local and visiting eduroam users are authenticating
> correctly, the majority of our own eduroam users authenticating to us via the
> NRPS servers now fail. The radius log shows (for example):
> 
> ==========
> Thu Aug 17 23:16:20 2017 : ERROR: (7299) ERROR: Failing proxied request for
> user "abc at students.plymouth.ac.uk", due to lack of any response from home
> server 141.163.xxx.yyy port 1812

  If NPS doesn't respond, NPS is the problem.  :(

> For the NRPS clients this occurs nearly 100% of the time. For some reason an
> occassional user will authenticate successfully. I have captured the debug
> output for a user who authenticated successfully on the 3.0.4 server, but then
> failed to authenticate on the 3.0.15 server. Although the last packet sent
> seemed acceptable, with no reply from the MS NPS server it is difficult to know
> what happened next.

  Well, both 3.0.4 and 3.0.15 are compliant with all RADIUS standards.  I suspect NPS isn't.

  I suspect that there are minor differences in packets which causes NPS to barf.  I suggest looking at PCAPs (tcpdump / wireshark) to see what's different about the packets.

  Or, send me the PCAPs (off-list), and say which packets are the problems.  I'll see if I can discover anything.

> However, before that I thought I would ask here if anyone has any thoughts
> about this? Has anyone had a similar problem?

  I've seen similar issues before with NPS.  If NPS receives an attribute that it thinks is type "integer", but is instead 8 bytes long (i.e. not an integer), NPS will *drop the whole packet*.

  This behaviour is beyond stupid.  I put text into RFC 6929 to address this exact problem:

https://tools.ietf.org/html/rfc6929#section-2.8

  I've also seen issues with other proprietary RADIUS servers that sometimes expect to see attributes in a particular order.  One in particular had the idiotic behaviour of replying to "bad" packets by *echoing the bad packet back to the client*.  I'm at a loss for how anyone ever thought that was a good idea.

  Alan DeKok.