Differences

This shows you the differences between two versions of the page.

--- siteadmin:radius_troubleshooting [2017/10/10 08:30] – admin
+++ siteadmin:radius_troubleshooting [2019/08/28 13:32] (current) – admin
@@ Line 1: / Line 1: @@
+======General Troubleshooting======
+=====Common Problems====
+  * The govroam monitoring system should be sending ICMP and RADIUS requests to your servers quite frequently (several times every five minutes). So you should be able to see these in your firewall logs or using Wireshark on your server. If you can't then check your firewall settings to allow ICMP echo/response and UDP port 1812 (incoming for Home sites, outgoing for Visited).
+  * A log message similar to: "message authenticator attribute that is not valid" means, most likely, that the shared secret with the sending system is incorrect.
 ====Rejected authentication requests====
@@ Line 33: / Line 40: @@
   NAS-Port
   NAS-Port-Type
+  Service-Type
 <blockquote>
@@ Line 42: / Line 50: @@
 What isn't know at the moment is if this standard NPS policy or a configuration being placed on NPS by administrators.
+===A general note about attributes and filtering===
+The Govroam tech spec talks about attributes and what should be in the various packets and what shouldn't. The key things to note, relevant to the above, are in section 2.4.1.13:
+<code>
+The following RADIUS attributes MUST be forwarded unaltered by participants’
+ORPSs if present in RADIUS Access-Request, Access-Challenge, Access-Accept
+or Access-Reject messages.
+.1. User-Name
+.2. Reply-Message
+.3. State
+.4. Class
+.5. Message-Authenticator
+.6. Proxy-State
+.7. EAP-Message
+.8. MS-MPPE-Send-Key
+.9. MS-MPPE-Recv-Key
+.10. Calling-Station-Id
+.11. Operator-Name
+.12. Chargeable-User-Identity
+Participants’ ORPSs MUST log all RADIUS authentication requests exchanged
+</code>
+which is fine but if RADIUS servers are expecting OTHER attributes, such as NAS-*, and rejecting if they're not there then it'll cause a problem, as seen above. The discussion section 2.4.3 says:
+<blockquote>
+The inclusion of spurious RADIUS attributes in packets exchanged between
+organisations can have unexpected effects and result in problems. It is therefore best
+practice to filter out unnecessary attributes. It is however essential that the key
+attributes detailed in this specification are not filtered and must be retained in
+forwarded packets.
+</blockquote>
+So the solution to the problem of failed authentications is to NOT filter out certain attributes and the spec says that they ought to be. Which is correct? The best advice is to filter out these attributes when proxing outwards but if there are any authentication issues with remote sites that you're struggling to fix then consider removing the filter to see what happens.
+At the same time ensure that your RADIUS is NOT configured to expect these extra attributes. It WILL be possible to run a service with just the key attributes mentioned in the spec.