Microsoft Azure上で動作しているRADIUSサーバーでEAP-TLS認証ができなかった理由と対処方法

概要

2024年1月17日よりIaaS対応のNetAttest EPS仮想アプライアンスがリリースいたしまして、合わせて【EPS技術記事】Microsoft Azure 環境へのNetAttest EPS構築手順を公開しております。

この手順でMicrosoft AzureにNetAttest EPSをデプロイして無線APからの認証を行ってみたところ、EAP-TLS認証だけできない事象がありましたので紹介させていただきます。

なお、本内容はMicrosoft Azureに限らず、ご利用の環境によっては発生する問題であり、かつNetAttest EPS特有の制限事項ではありません。

構成

検証環境の概略図

社内検証環境に仮想VPNルーターを設置して、Microsoft AzureとSite to SiteでIPsec VPN接続しています。

Microsoft AzureのNetAttest EPSで各種認証を試した結果

実際のお客様での利用を想定して、社内検証環境からMicrosoft AzureのNetAttest EPSへ下記の認証をテストしました。

テストの結果は次の通りとなります。

PAP認証

PAP認証は有線スイッチでのMACアドレス認証を行う際に利用されるケースが多いため、有線スイッチにてMACアドレス認証を行う設定にしてテストしました。

問題なく認証できることが確認できました。

PEAP(MS-CHAPv2)認証

PEAP(MS-CHAPv2)認証はユーザー名、パスワードでの認証方式であり、Active Directoryと連携してWindowsアカウント、パスワードを使った認証やコンピューターアカウントを使った認証を行うことができます。
今回はNetAttest EPSのローカルにユーザーを登録して、Windows 10端末でWi-Fi接続時の認証ができるかをテストしました。。

こちらも問題なく認証できることが確認できました。

EAP-TLS認証

EAP-TLS認証はクライアント証明書を使った認証方式であり、主に企業ネットワークにおいてWindowsだけでなくmacOS、スマートフォン、タブレットなどでのWi-Fi接続の認証で多く利用されています。

NetAttest EPSから発行した証明書をWindows 10端末にインポートして、その証明書を使ってWi-Fi接続時の認証ができるかをテストしました。

PAP認証、PEAP(MS-CHAPv2)認証が成功していたので、EAP-TLS認証も問題なく認証できるだろうと考えておりましたが、結果としては不思議なことにEAP-TLS認証だけ「このネットワークに接続できません」と表示され、Wi-Fi接続ができませんでした。

EAP-TLS認証でWi-Fiに接続しようとした結果

EAP-TLSだけ認証ができなかった理由について

EAP-TLSだけ認証ができないという不思議な状況であったので、NetAttest EPSの認証ログを確認しましたがAccess-Rejectなど認証失敗につながるようなログは出力されていませんでした。
どうやら、無線APもしくはクライアント端末自体が接続できないと判断したようです。

Windows端末でイベントログを確認する

Windows OSではイベントビューアーの[アプリケーションとサービスログ]-[Microsoft]-[Windows]-[WLAN-AutoConfig]-[Operational]にWi-Fi接続のログが記録されるので確認したところ次のようなエラーが記録されていました。

イベントID 12013

イベントID 11006

イベントID 8002

これらのイベントは無線APポイントよりEAPエラーを受信したので、ネットワークが利用できないことを示す内容となっています。

この情報とNetAttest EPSではAccess-Rejectを返したわけではない点をあわせて考えると、端末と無線AP間の電波状況悪い、もしくは無線APが壊れているのでは無いかと考えたのですが、無線APとNetAttest EPSを同セグメントに配置した場合にはEAP-TLSは認証成功となったので、無線APとMicrosoft Azure上のEPS間のネットワークで何かが起こっているように思われます。

パケットキャプチャを取得して状況確認

検証環境とMicrosoft AzureのNetAttest EPSのそれぞれでパケットキャプチャを取得して、RADIUSパケットがどうなっているかを追ってみました。

仮想ルーター上で取得したパケットキャプチャ

Microsoft AzureのNetAttest EPSで取得したパケットキャプチャ

仮想ルーターのパケットもMicrosoft AzureのNetAttest EPSで取得したパケットもオレンジで囲った部分のNo.1からNo.10までのパケットは共通なので、APとEPS間の通信に問題がない事がわかります。

しかし、仮想ルーターで取得したパケットキャプチャで赤枠で囲ったNo.11からNo.15までのパケット(id=33)は、Microsoft AzureのEPSで取得したパケットキャプチャには存在していません。仮想ルーターからMicrosoft Azureの間のどこかでこのパケットが消失してしまったようです。

ちなみに届いていないフラグメントされたパケットを確認してみました。 

フラグメントされたパケットの中身

赤枠で囲った部分はEAP-TLS認証して使用したクライアント証明書の情報でした。

届いているパケットと届いてないパケットを見比べると、届いていないパケットはサイズが1500バイトを超えていることがわかります。

パケットサイズが大きいのが原因？

マイクロソフト社のドキュメントではSite to SiteのIPsec VPNではMSSを1350するか、MTUを1400バイトにすると記載がありました。こちらもヒントになりそうです。

EAP-TLS認証だけ認証ができなかったのは、クライアント証明書が含まれている大きなサイズのパケットがMicrosoft Azureの仮想ネットワークまで届かない為に、認証が成立しない状況だったと考えられます。

参考までに手元の検証環境での各認証のパケットの最大サイズはおおよそ次の通りでした。

• PAP認証のパケットサイズ Access-Request(AP→EPS)でおおよそ130バイト
• PEAP(MS-CHAPv2)認証のパケットサイズ Access-Challenge(EPS→AP)でおおよそ1200バイト
• EAP-TLS認証のパケットサイズ 赤枠で囲ったフラグメントしたAccess-Request(AP→EPS)パケットを結合するとおおよそ1800バイト(1514バイト+227バイト=1741バイト)でした。

※本検証で使用したCA証明書、EPSのサーバー証明書、クライアント証明書は共にRSA暗号の鍵長2048bit、署名アルゴリズムはSHA256の物を使用しています。

パケットサイズを制限してEAP-TLS認証を行う方法

今回の検証環境では、大きなサイズのUDPパケットが届かないことがわかりましたが、幸いなことにRADIUSパケットのDFビット(Don't Fragment bit)は0が指定されておりパケットの分割ができるようになっていましたので、大きなサイズのパケットをどこかで分割するように制限すれば解決できそうです。

そこで以下を試しましたが、今回の検証環境ではRADIUS認証のUDPパケットは小さくならず、改善には至りませんでした。

• Windows PCの無線インターフェースのMTU変更
• 無線APのLANインターフェースのMTU変更
• VPNルーターのLANインターフェースのMTU変更

さらに調査を進めた結果、UDPパケットを分割する方法をいくつか見つけることが出来ました。

IPsec トンネルインターフェイスでMTUサイズを変更する

VPNルーターのドキュメントを確認したところVPN接続するIPsecトンネルインターフェイス(Virtual Tunnle Interface/VTI)でMTUサイズを制限する方法が案内されていたため、こちらを使ってIPsecトンネルインターフェイスにてMTUを1400に絞ったところ、EAP-TLS認証に成功しました。

認証したときのパケットキャプチャを取得しました。

仮想ルーターでのパケットキャプチャ

Microsoft Azure上のNetAttest EPSでのパケットキャプチャ

赤枠で囲ったフラグメントされた部分のパケットサイズが一致していない様に見えますが、足し算してみますと

• 仮想ルーター：1514バイト+227バイト=1741バイト
• Azure上のEPS：1410バイト+331バイト=1741バイト

と同じサイズになっており、無線APとMicrosoft Azure間でパケットが消失されないようにパケットを分割して送っていることがわかります。

Arubaアクセスポイントを利用する

HPE Aruba Networking製アクセスポイントにはEAPパケットを指定サイズにフラグメントするdot1x eap-frag-mtuコマンドがあり、これを設定することでAruba APから発出されるRADIUSパケットのサイズを調整する事ができました。

Arubaアクセスポイントのコンフィグ

仮想ルーターで取得したArubaアクセスポイントとEPS間のパケットキャプチャ

RADIUS以外のUDPを使うプロトコル

TCPであれば3ウェイ・ハンドシェイクでMSSを調整できたり、PATH MTU Discoveryなどでパケットサイズ調整が行いやすく問題になりにくいのですが、そのような機構がないUDPの場合にはプロトコル自身で配慮しているものもあります。

UDPを使う他のプロトコルとして、有名所ではDNSやQUICなどがありますが、様々な経路を経由してもパケットが消失しないよう配慮したパケットサイズを使うように定められています。

• DNS
  RFC791(Internet Protocol)のsection3.1を意識してDNSメッセージサイズを512バイトまで
• QUIC
  RFC2460(Internet Protocol, Version 6)のsection5を意識してUDPペイロードは1200バイト
  ハンドシェイク無しに通信するUDPをインターネット越しに利用することと、通信の効率性を考慮して、1200バイトにすること定められている

これらのプロトコルとは異なり、プロトコルでパケットサイズを配慮していない場合には、ネットワーク機器で配慮した設計が必要になります。

終わりに

本事象の原因であるUDP通信のフラグメントについては、必ずしも発生する現象ではありませんが、VPN機器や無線メーカー側でも考慮・対応されているものがありました。

ただ、機器によって設定や対応方法の違いなどがありますので、NetAttest EPSをMicrosoft Azure上やVPN越しに配置する場合は、ネットワーク機器の仕様もご確認しつつ進めていただければと思います。

なお、仮想アプライアンスの評価版をご用意しておりますので、NetAttest EPSをご購入頂く前に現在ご利用中のネットワーク機器や設定でEAP-TLS認証ができるかの確認にぜひご活用いただければ幸いです。