Differences

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

--- siteadmin:radius_troubleshooting [2017/10/10 08:22] – created 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 13: / Line 20: @@
 To quote Hans:
-> I'm aware RFC 3580 states the Called-Station-ID
+<blockquote>
-> SHOULD append the SSID. However,
+I'm aware RFC 3580 states the Called-Station-ID
->
+SHOULD append the SSID. However,
-> 1. Not everything does; ArubaOS below 6.4 doesn't allow you to add this
->    to the RADIUS client configuration.
+. Not everything does; ArubaOS below 6.4 doesn't allow you to add this to the RADIUS client configuration.
-> 2. The default pre-proxy attribute filter in FreeRADIUS, if turned on,
->     will remove Called-Station-ID from a proxy request.
+. The default pre-proxy attribute filter in FreeRADIUS, if turned on, will remove Called-Station-ID from a proxy request.
->
-> So the policy condition is a bit strict for a 'federated' environment.
+So the policy condition is a bit strict for a 'federated' environment.
->
-> I've update our FreeRADIUS configuration to add the missing SSID
+I've update our FreeRADIUS configuration to add the missing SSID
-> if not supplied by the NAS client and I can now authenticate via
+if not supplied by the NAS client and I can now authenticate via
-> Camden's RADIUS server.
+Camden's RADIUS server.
+</blockquote>
+Further to this Hans has looked into the attribute filters and determined that NPS should be configured not to filter out the following from a proxied request:
+  NAS-IP-Address
+  NAS-Identifier
+  NAS-Port
+  NAS-Port-Type
+  Service-Type
+<blockquote>
+My interpretation is it that a RADIUS server will always see those
+if the request comes direct from a NAS client (AP, wireless controller,
+edge switch, ...) but not necessarily for a proxy request especially
+of the visited site uses filtering.
+</blockquote>
+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.