Remote users - proxying fails - NPS timeout

[Alan Buxey]

Same offer here. Initial thought is handling of some attribute. Best thing
to do is ensure you're calling attribute filter for all packets destined to
NPS to strip them down to bare essentials (ie the minimum EAP contents for
NPS to do its job with no other attrs present). I assume you're sending the
EAP onward to NPS and not terminating EAP on FR and only sending inner Auth
to NPS?

alan

On 18 Aug 2017 12:37 am, "John Horne" <john.horne at plymouth.ac.uk> wrote:

Hello,

We have 2 CentOS 7 servers which act solely as RADIUS proxy servers using
PEAP.
They proxy to backend Microsoft NPS servers. The servers proxy local
(wireless)
users (to NPS), visiting eduroam users (to NRPS) and our own (eduroam) users
(to NPS) who are visting external sites. The eduroam users are proxied
to/from
the UK national proxy servers (NRPS). Both local radius servers ran the
freeradius 3.0.4 CentOS package. This all worked well.

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

Thu Aug 17 23:16:20 2017 : Auth: (7299) Login incorrect (Home Server failed
to
respond): [abc at students.plymouth.ac.uk] (from client NRPS-0 port 13 cli
FC-FC-
48-FF-AA-DD) SSID: eduroam

Thu Aug 17 23:16:20 2017 : Auth: (7299) Login incorrect (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): [abc at students.plymouth.ac.uk]
(from client NRPS-0 port 13 cli FC-FC-48-DD-AA-DD) SSID: eduroam
==========

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.

A little googling seemed to indicate that MS NPS is known for just dropping
packets rather than rejecting them or even logging them. I asked the
sysadmin
of the NPS servers if the logs showed anything, but he said not. The servers
themselves were not under any particular load, so that was not a reason to
drop
the packets.

Although the freeradius config files have had to be modified a little bit
due
to differences between 3.0.4 and 3.0.15, they are basically the same.

I tried downgrading to an RHEL 7 beta RPM of freeradius 3.0.13, but we got
the
same timeout problem. I have now gone back to 3.0.4, and the problem has
gone.

I am a bit stumped with this. My first thought was that we had changed
something to cause the MS NPS servers to drop the packets. Filtering seemed
possible as I gather if NPS is sent a packet with unrecognised radius
attributes then it is likely to drop it. However, the filtering is the same
between 3.0.4 and 3.0.15. I have also gone through the changelog from 3.0.5
to
3.0.15, but could not find anything obvious (to me) that might explain this.
My thoughts are that perhaps some core part of freeradius has been modified
such that it is now causing NPS (for us) a problem. We could start to work
through the versions from 3.0.5 upwards to see at what version we hit the
problem, and then look further at the commits for that version.

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



Thanks,

John.

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
________________________________
[http://www.plymouth.ac.uk/images/email_footer.gif]<http:
//www.plymouth.ac.uk/worldclass>

This email and any files with it are confidential and intended solely for
the use of the recipient to whom it is addressed. If you are not the
intended recipient then copying, distribution or other use of the
information contained is strictly prohibited and you should not rely on it.
If you have received this email in error please let the sender know
immediately and delete it from your system(s). Internet emails are not
necessarily secure. While we take every care, Plymouth University accepts
no responsibility for viruses and it is your responsibility to scan emails
and their attachments. Plymouth University does not accept responsibility
for any changes made after it was sent. Nothing in this email or its
attachments constitutes an order for goods or services unless accompanied
by an official order form.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/
list/users.html