Remote users - proxying fails - NPS timeout

Caines, Max Max.Caines at wlv.ac.uk
Tue Aug 22 12:53:35 CEST 2017


Hi John

We use FR proxying to NPS ourselves. We are currently using FR2.2.10, but last year I felt it was time we moved on and built 3.0.11 on Ubuntu 16.04. While testing with individual authentication requests seemed to work fine, when I came to switch over our production traffic to the FR3 server, packets immediately started being dropped by NPS. In our case it was more like 25%, but looking at the captured packets that were dropped by NPS and the ones accepted, I couldn't see any difference. In the end I gave up and concluded that NPS is so difficult to debug that it would be simpler to join the FR server to the domain and use "winbind". I've built a test server, but not made the transition yet. I have to get it past our Change Advisory Board first!

I never did try anything earlier than 3.0.11, but this sounds fairly similar to your experience. However, I have the advantage that I run the NPS servers too. In our case the event log did show the requests being rejected. Of course the end result is the same, because no response goes back to the FR server, and the reject message doesn't give any information about what's wrong. But it might be worth asking your NPS admin to check again, because it doesn't generally drop requests without logging it.

As I say, when it came to it implementing "winbind" wasn't that painful, given that it's just a package. You don't have to get heavily involved with Samba

Regards

max

-----Original Message-----
From: Freeradius-Users [mailto:freeradius-users-bounces+max.caines=wlv.ac.uk at lists.freeradius.org] On Behalf Of Alan Buxey
Sent: 19 August 2017 17:46
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: Re: Remote users - proxying fails - NPS timeout

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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



More information about the Freeradius-Users mailing list