はじめに
EAP-TLS 認証を使用した Radius 認証で、認証が定期的にタイムアウトするケースがあります。
この問題は主にRadius パケットのフラグメンテーション に起因しており、特にパブリッククラウド上(Azure, AWS またはISE など)でRadius サービスを利用している場合やVPN などを用いて拠点を跨いでRadius サーバを利用する構成で発生しやすい傾向があります。
本記事では、問題の原因、確認方法、そして解決策について解説します。
EAP-TLS 認証に関しての詳細は、ドキュメントを参照ください。
問題の概要
EAP-TLS の性質上、大きなパケットサイズ(1500バイト以上)になることがあります。この際、ネットワークデバイス(MR)は フラグメンテーション(IP パケット分割) を行い、これが原因で以下の状況が発生する可能性があります。
- MTU の不一致などによる認証パケットドロップ:経路上のデバイスで MTU が異なる場合、フラグメントされたパケットが通信機器(特にファイアウォール)でドロップされる。
- Radius サーバでの再構成失敗:フラグメントパケットが Radius サーバに届かない、または過負荷状態になる。結果として、認証がタイムアウトし、失敗するケースが発生します。
- 経路上でパケットドロップされる:フラグメントされたUDP パケットをファイアウォール等の通信機器が(ポリシーで定義していなくても)ドロップしてしまう場合があります。(順序外のUDP フラグメント、フラグメントパケットをドロップしてしまう設定など。)
例:Azure 環境にISE を構築した場合にフラグメントパケットを順番通りに受信したホストが適切に再構成して処理を行うことができず、パケットドロップされる問題が確認されています。
参考情報:[フラグメンテーション問題のトラブルシューティング:Azureを使用するc9800ワイヤレスコントローラに影響を与える](https://www.cisco.com/c/ja_jp/support/docs/troubleshooting/222339-troubleshoot-fragmentation-issues-...)
フラグメンテーション問題の詳細
EAP-TLS フラグメンテーション:
- RFC 5216 に基づきフラグメントは正常な動作ですが、Radius プロトコル(通常 UDP 1812)ではフラグメント化されたパケットがファイアウォール等でドロップされることがあります。
- 特に、クラウド環境(AWS や Azure)に Radius サーバを移行した場合、経路上でのパケットドロップが発生する傾向があります。
初期症状:
- 認証がタイムアウトする。
- EAP-PEAP では認証成功、EAP-TLS では失敗という場合、この問題が疑われます。
問題の確認方法
パケットキャプチャの取得:
- Radius サーバ側と MR Wired 側の両方でパケットキャプチャを取得。
- フラグメントパケットが Radius サーバに届いていない場合、途中経路でドロップされている可能性があります。
Wireshark フィルタの使用: 以下のフィルタを使用してフラグメントパケットを確認します。
_ws.col.info contains "Fragmented IP protocol" or radius
または
eap.tls.fragments
例: Wireshark で以下のようなフラグメント情報が表示され、問題が特定できます。
以下の例では、Wireshark がパケット 6374、6376、6378、6380 を再構成したことが示されています。
EAPフラグメントのサイズは1,024、1,024、1,024および876で、EAP-TLSメッセージの合計サイズは 3948bytes になります。
[4 EAP-TLS Fragments (3948 bytes): #6374(1024), #6376(1024), #6378(1024), #6380(876)]

解決策
以下のアプローチでフラグメンテーション問題を解決できる可能性があります。
1. MTU サイズの調整
- 経路上の MTU を統一し、多くのフラグメントが発生しないように設定する。
- 経路上すべてでJumbo Frame を有効化(現実的には難しい場合あり)。
2. MR(Meraki)デバイスの MTU 設定
- 現在、MR デバイス自体の MTU 値はダッシュボードから変更できませんが、DHCP オプションを利用して調整可能です。これで、経路上のMTU が統一され、解決につながる見込みがあります。
- DHCP Option 26 を使用し、管理インターフェースの MTU を変更します。
※注意:設定反映には次回の DHCP リース更新が必要です。
(MR の場合、手動でRelease できないため、上位DHCP の設定変更などを実施してDHCP 情報をリセットする、MR の再起動などが必要。)
3. RadSec(RADIUS over TLS)を使用
- UDP を使用する RADIUS の代わりに RadSec(TCP ベース) を採用。
- フラグメントが発生しても問題なく通信が可能であり、TLS による暗号化も実現します。
メリット:
- インターネット越しの通信においてセキュリティが向上。
デメリット:
- MR 側と Radius サーバ側の両方で設定と証明書インストールが必要。
参考情報:[Configuring RADSec (MR) - Cisco Meraki Documentation](https://documentation.meraki.com/MR/Encryption_and_Authentication/MR_RADSec\)
4. 問題を特定したデバイスでオプション設定の見直し
- Azure 側のオプション設定にてUDP フラグメントの並べ替え機能を有効化するなど。
- これらのオプションに関しては、利用元のベンダに確認いただく必要があります。
参考情報:[フラグメンテーション問題のトラブルシューティング:Azureを使用するc9800ワイヤレスコントローラに影響を与える](https://www.cisco.com/c/ja_jp/support/docs/troubleshooting/222339-troubleshoot-fragmentation-issues-...)
まとめ
EAP-TLS 認証におけるフラグメンテーション問題は、Radius 認証のタイムアウトや失敗の主な原因となります。この問題を解決するには、MTU サイズの調整や RadSec の導入が効果的です。特にクラウド環境で Radius サーバを利用している場合には、経路上の MTU 設定や通信機器のポリシーに注意が必要です。