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@lists.freeradius.org] On Behalf Of Alan Buxey Sent: 19 August 2017 17:46 To: FreeRadius users mailing list <freeradius-users@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@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@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@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@students.plymouth.ac.uk", due to lack of any response from home server 141.163.xxx.yyy port 1812): [abc@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