Windows ServerのNPSはファイアウォール設定が必要？
目次
Windows ServerをRADIUSサーバにするため、NPSを有効にしたが、なぜかファイアウォールの設定も必要だったのでメモ
状況
ネットで調べながらNPSを有効にしたが、CiscoのスイッチとWindows Server間の通信がうまくいっていないように見えた。
-
Syslog
Feb 28 12:38:47 10.255.xxx.xxx 306: Feb 28 03:38:46.149: %DOT1X-5-FAIL: Authentication failed for client (xxxx.xxxx.xxxx) on Interface Gi0/3 AuditSessionID XXXXXXXXXXXXXXXXXXXXXXXX Feb 28 12:39:21 10.255.xxx.xxx 307: Feb 28 03:39:20.875: %RADIUS-4-RADIUS_DEAD: RADIUS server xxx.xxx.xxx.xxx:1812,1813 is not responding. Feb 28 12:39:21 10.255.xxx.xxx 308: Feb 28 03:39:20.875: %RADIUS-4-RADIUS_ALIVE: RADIUS server xxx.xxx.xxx.xxx:1812,1813 is being marked alive. -
show aaa serversc3560cg#show aaa servers RADIUS: id 2, priority 1, host xxx.xxx.xxx.xxx, auth-port 1812, acct-port 1813 State: current UP, duration 265s, previous duration 0s Dead: total time 0s, count 8 Quarantined: No Authen: request 88, timeouts 88, failover 0, retransmission 66 Response: accept 0, reject 0, challenge 0 Response: unexpected 0, server error 0, incorrect 0, time 0ms Transaction: success 0, failure 22 Throttled: transaction 0, timeout 0, failure 0 Author: request 0, timeouts 0, failover 0, retransmission 0 Response: accept 0, reject 0, challenge 0 Response: unexpected 0, server error 0, incorrect 0, time 0ms Transaction: success 0, failure 0 Throttled: transaction 0, timeout 0, failure 0 Account: request 0, timeouts 0, failover 0, retransmission 0 Request: start 0, interim 0, stop 0 Response: start 0, interim 0, stop 0 Response: unexpected 0, server error 0, incorrect 0, time 0ms Transaction: success 0, failure 0 Throttled: transaction 0, timeout 0, failure 0 Elapsed time since counters last cleared: 1h2m Estimated Outstanding Access Transactions: 0 Estimated Outstanding Accounting Transactions: 0 Estimated Throttled Access Transactions: 0 Estimated Throttled Accounting Transactions: 0 Maximum Throttled Transactions: access 0, accounting 0 Requests per minute past 24 hours: high - 0 hours, 30 minutes ago: 8 low - 1 hours, 3 minutes ago: 0 average: 1request 88 = timeouts 88 なので、すべてのパケットがタイムアウトしている。
-
show radius statisticsc3560cg#show radius statistics Auth. Acct. Both Maximum inQ length: NA NA 1 Maximum waitQ length: NA NA 2 Maximum doneQ length: NA NA 1 Total responses seen: 0 0 0 Packets with responses: 0 0 0 Packets without responses: 22 0 22 Access Rejects : 0 Average response delay(ms): 0 0 0 Maximum response delay(ms): 0 0 0 Number of Radius timeouts: 88 0 88 Duplicate ID detects: 0 0 0 Buffer Allocation Failures: 0 0 0 Maximum Buffer Size (bytes): 287 0 287 Malformed Responses : 0 0 0 Bad Authenticators : 0 0 0 Unknown Responses : 0 0 0 Source Port Range: (2 ports only) 1645 - 1646 Last used Source Port/Identifier: 1645/22 1646/0 Elapsed time since counters last cleared: 1w53m Radius Latency Distribution: <= 2ms : 0 0 3-5ms : 0 0 5-10ms : 0 0 10-20ms: 0 0 20-50ms: 0 0 50-100m: 0 0 >100ms : 0 0 Current inQ length : 0 Current doneQ length: 0 -
Windows ServerのNPSのイベントログ (カスタムビュー -> サーバーの役割 -> ネットワーク ポリシーとアクセス サービス) にもログが出てこない。
暫定対処
Windows Serverのファイアウォールを確認してみたが、デフォルトのポートの場合は、既に許可ルールが作成されていたが、どうにもならないのでひとまずファイアウォールをオフにしてみると、問題が解消した。
そのため、ファイアウォールの問題と判断。
ファイアウォールのルールには、ポートのほかにプログラム %systemroot%\system32\svchost.exe の設定が入っていたため、netstat -aon で UDP 1812,1813をListenしているプロセスを調べてみたところ、svchost.exeだったため、問題はなさそうに見える…..
また、サービスもiasになっているため、問題なさそうに見える…
しかし、ファイアウォールのDROPログを取ると、以下のように綺麗にDROPしていた。
2021-02-28 13:35:35 DROP UDP 10.255.xxx.xxx xxx.xxx.xxx.xxx 1645 1812 277 - - - - - - - RECEIVE
2021-02-28 13:35:40 DROP UDP 10.255.xxx.xxx xxx.xxx.xxx.xxx 1645 1812 277 - - - - - - - RECEIVE
どうしようもないので、新規ルールを作成し、UDP Port 1812-1813 を許可する設定を追加したところ、問題は解決した。
なんなんだ(´・ω・｀)