Der Radius-Health-Check (RHC) ist seit AOS 6.7.1.R03 in der AOS Software enthalten und soll für per MAC oder 802.1x-authentifizierte Nutzer eine schnellere Fehlererkennung ermöglichen wenn der RADIUS nicht verfügbar ist / nicht antwortet.

Der eingerichtete RADIUS „rad01“ wird nach Eingabe des Kommandos aaa radius-health-check name <radius-name> status enable periodisch abgefragt.

OS6450-P10-> show configuration snapshot aaa
! AAA :
aaa radius-server "rad01" host 192.168.5.1 key 3851dff6d9e5ddb1d77cba2e58159549 retransmit 3 timeout 2 auth-port 1812 acct-port 1813 
aaa authentication default "local" 
user password-size min 9
user password-policy min-uppercase 1
user password-policy min-lowercase 1
user password-policy min-digit 1
user password-policy min-nonalpha 1
aaa switch-access mode enhanced
aaa radius-health-check name "rad01" status enable 

Eine Anpassung des Benutzernamen/Passwort die für die Anfrage genutzt werden ist möglich, aber unnötig und aus meiner Sicht nicht zu empfehlen.

Der Radius-Health-Check prüft ob der RADIUS auf die Anfrage antwortet. Es ist dabei egal ob ein Access-Accept, Access-Challenge oder Access-Reject zurückgemeldet wird. In jedem Fall gilt der Server als „UP“. Ein gültiger RADIUS-Account führt im schlimmsten Fall zu einem Sicherheitsproblem, daher halte ich es für sinnvoll den verwendeten Account zu deaktivieren und auf Basis des „Access-Reject“ zu arbeiten.

Anfrage eines OmniSwitch am RADIUS per Radius-Health-Check (ohne Korrekturen an der RADIUS-Konfiguration):

rad_recv: Access-Request packet from host 192.168.5.102 port 1071, id=79, length=73
	User-Name = "alcatel"
	EAP-Message = 0x0250000c01616c636174656c
	NAS-IP-Address = 172.18.16.42
	NAS-Port-Type = Ethernet
	Message-Authenticator = 0x39b53e4608b9fd6bd8d2f9cbccb35266
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+group authorize {
++[preprocess] = ok
++[chap] = noop
++[mschap] = noop
++[digest] = noop
[suffix] No '@' in User-Name = "alcatel", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] = noop
[eap] EAP packet type response id 80 length 12
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] = updated
[files] users: Matched entry alcatel at line 105
++[files] = ok
++[expiration] = noop
++[logintime] = noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] = noop
+} # group authorize = updated
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+group authenticate {
[eap] EAP Identity
[eap] processing type md5
rlm_eap_md5: Issuing Challenge
++[eap] = handled
+} # group authenticate = handled
Sending Access-Challenge of id 79 to 192.168.5.102 port 1071
	EAP-Message = 0x0151001604106d6476e552bfc4fcef07042a5881e0b3
	Message-Authenticator = 0x00000000000000000000000000000000
	State = 0xab784abcab294ef8bc3a9ed9189b7460
Finished request 16.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 16 ID 79 with timestamp +824
Ready to process requests.

Es fallen eine Reihe von Dingen auf:

• NAS-IP-Address „172.18.16.42“ ist nicht korrekt
• EAP in der Anfrage enthalten, obwohl es PAP sein sollte
• User-Password fehlt, daher ist die ganze Anfrage hinfällig (und daher auch ein benutzerdefinierten Passwort überflüssig)
• Die enthaltene EAP-Identity führt zu einer EAP-MD5 Challenge, die den RADIUS unnötig beschäftigt
• Der Request muss in den „cleanup_delay“ laufen

Daher meine Empfehlung für den RHC-Benutzer in /etc/freeradius/users:

# Deaktivierter Benutzer fuer OmniSwitch Radius-Health-Check
"alcatel"       Auth-Type := Reject

Ergebnis:

rad_recv: Access-Request packet from host 192.168.5.102 port 1093, id=123, length=73
	User-Name = "alcatel"
	EAP-Message = 0x027c000c01616c636174656c
	NAS-IP-Address = 172.18.16.42
	NAS-Port-Type = Ethernet
	Message-Authenticator = 0x45f67b77eb649c1baf1c5df5011e23d1
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+group authorize {
++[preprocess] = ok
++[chap] = noop
++[mschap] = noop
++[digest] = noop
[suffix] No '@' in User-Name = "alcatel", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] = noop
[eap] EAP packet type response id 124 length 12
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] = updated
[files] users: Matched entry alcatel at line 105
++[files] = ok
++[expiration] = noop
++[logintime] = noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] = noop
+} # group authorize = updated
Found Auth-Type = Reject
Auth-Type = Reject, rejecting user
Failed to authenticate the user.
Using Post-Auth-Type REJECT
# Executing group from file /etc/freeradius/sites-enabled/default
+group REJECT {
[attr_filter.access_reject] 	expand: %{User-Name} -> alcatel
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] = updated
+} # group REJECT = updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 123 to 192.168.5.102 port 1093
Waking up in 4.9 seconds.
Cleaning up request 0 ID 123 with timestamp +9
Ready to process requests.

Auf dem Switch sieht dies so aus:

OS6450-P10-> show aaa server 
Server name = rad01
  Server type             = RADIUS,
  IP Address 1            = 192.168.5.1,
  Retry number            = 3,
  Time out (sec)          = 2,
  Authentication port     = 1812,
  Accounting port         = 1813,
  Nas port                = default,
  Nas port id             = disable,
  Nas port type           = ethernet,
  Mac Addr Format Status  = disable,
  Mac Address Format      = uppercase,
  Unique Acct Session Id  = disable,
  Health Check Status     = ENABLED,
  Server oper status      = UP,
  Primary oper status     = UP,
  Polling interval        = 50,
  User name               = alcatel,
  Failover Status         = DISABLED