シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

[CUWN] AP を Dynamic NAT (PAT) ファイアウォール環境下で使う場合の問題点と解決策

このドキュメントでは AP を Dynamic NAT (PAT) の背後に設置して CUWN をデザインする場合の注意点を説明します。

 

2つの CAPWAP フローの存在

Lightweight AP は WLC に Join して無線 LAN サービスを提供する際に、UDP の 5246 番と 5247番 宛の2本のフローを使います。
これらは CAPWAP と呼ばれるプロトコルを使った通信です。
5246 番宛のフローを CAPWAP コントロールリンク、5247 番宛のフローを CAPWAP データリンクと呼びます。
 
CAPWAP コントロールリンクは AP や WLC 自体の認証情報や不正 AP のレポート等のインフラに関する極めて重要なデータを含んでおり、セキュアに保つ必要があります。そのため、AP が WLC に Join をする際には DTLS プロトコルにより暗号化が実施され、DTLS トンネル内部で CAPWAP コントロールパケットがやりとりされます。
 
一方、CAPWAP データリンクは DTLS トンネルを最初は使用せず、単純に UDP 5247 番宛でデータパケットをやりとりします。データパケットにはセントラルスイッチングされる無線 LAN クライアントの一般的なトラフィックの他に、Association Request や EAPoL 4way handshake の情報等の 802.11 の管理フレームが含まれます。
 

Dynamic NAT (PAT) の背後の AP 

ここで WLC と AP の間にファイアウォール等の Dynamic NAT (PAT) デバイスが入り、CAPWAP フローがその対象になったときのことを考えます。
下記に例を図示します。
 
[AP1 (192.168.1.1:1234)]---->[ファイアウォール : Dynamic NAT (PAT) (64.1.1.1:5678)]---->(インターネット等)---->[WLC (64.3.3.3:5246/5247)]
 
このとき AP 発の UDP 5246 番と 5247 番宛の CAPWAP 通信は、それぞれ次のようにソースポート番号が変換されたうえで WLC に届くことになります。
 
PAT 通過前
[宛先 IP アドレス (WLC)  |  送信元 IP アドレス (AP ローカル IP アドレス) | UDP (送信元 AP ポート番号, 宛先 WLC ポート番号 5246/5247)| CAPWAP データ]
[64.3.3.3|192.168.1.1|UDP src 1234 dst 5246/5247|payload]
 
PAT 通過後
[宛先 IP アドレス (WLC)  |  送信元 IP アドレス (AP グローバル IP アドレス) | UDP (送信元 PAT 変換後の番号, 宛先 WLC ポート番号 5246/5247)| CAPWAP データ]
[64.3.3.3|64.1.1.1|UDP src 5678 dst 5246/5247|payload]
 
 
このように PAT を通過して WLC に AP が Join した場合は、WLC はその AP のグローバル IP アドレスと、PAT 変換後のポート番号をセットにしてその AP との CAPWAP フローを認識します。
 
上図の例の場合のWLC の認識状態
"AP1 は IP アドレス 64.1.1.1 を持っていて、送信元ポート番号として 5678 番を使っている"
 

想定される問題

ファイアウォールの NAT テーブルがエージング(カウントダウン)タイマーを有している場合、一度変換したフローが使われていないと一定時間経過後にその変換エントリーを消去することがあり、これが無線クライアントの通信断等に繋がる場合があります。PAT 変換に利用できるポートの番号は有限ですので、NAT テーブルがこのようなタイマーを利用して、常に利用可能なポート番号リソースを確保しておこうとすることは一般的です。
 
CAPWAP コントロールリンクでは自動的に 30秒おきのキープアライブ通信が入るため、30 秒よりも短いエージングタイマーがファイアウォールに設定されていない限りは、一度 WLC に AP が Join した後は、その変換エントリは保持され、DTLS トンネルも切断されることはありません。
しかしながら、CAPWAP データリンクでは定期的なキープアライブ通信が入りません (CUWN ソフトウェアバージョン 8.0 よりも前のソフトウェアに限る)。したがって無線クライアントのトラフィックが一定時間存在しない場合は、ファイアウォール上の CAPWAP データリンクフローに該当する NAT エントリがタイムアウトして消去されることがあります。消去された後に無線クライアントが再び通信や Association を実施しようとした際は NAT エントリが再生成されますが、このときの変換後の UDP の送信元番号が、消去される直前のエントリと同一のものになる保証はありません。
もしも異なる番号へと変換された場合、それは WLC が記録している AP の情報 (アドレスとポート番号のセット) と一致しませんので、その CAPWAP データリンクトラフィックは WLC で破棄され、無線通信断、あるいは Association できないといった障害に繋がってしまいます。
 

この問題への対処方法

この問題に対処するためには、次の対策を実施する必要があります。
 
  1. PAT エントリがタイムアウトしないようにファイアウォールを設定する
  2. CAPWAP データリンクをコントロールリンクと同様に DTLS トンネルを利用した暗号化通信にし、定期的なキープアライブ通信を実施させる
  3. CUWN ソフトウェアバージョン 8.0 リリース以降のソフトウェアを使う
 
上記の 3 番目の対処方法についてですが、CUWN ソフトウェアバージョン 8.0 リリースにて、CAPWAP データリンクについては暗号化を実施せずとも 30秒おきにキープアライブ通信を実施するように仕様が変更されたことが理由です。
2 番目の方法に比べると DTLS のオーバーヘッドが無くなってスループットの向上が見込まれますので、より優れた解決方法と言えます。
この追加されたキープアライブ機能は常に有効であり、次の debug により動作状況を確認することができます。
 
(Cisco Controller) >debug capwap dtls-keepalive enable

*capwapSocketTask: Jun 01 06:21:40.031: 08:cc:68:b4:46:c0 Data Keepalive received on IP 172.31.255.40, port 5247

*capwapSocketTask: Jun 01 06:21:40.031: 08:cc:68:b4:46:c0 Data Keepalive packet reflected back to 172.31.255.109:62319

*capwapSocketTask: Jun 01 06:22:01.594: 3c:ce:73:1a:09:60 Data Keepalive received on IP 172.31.255.40, port 5247

*capwapSocketTask: Jun 01 06:22:01.594: 3c:ce:73:1a:09:60 Data Keepalive packet reflected back to 10.10.21.209:43147

 

このソリューションは FlexConnect ローカルスイッチングを実施していて頻繁には CAPWAP データリンクを使わないデザイン等に、特に有効です。

 

バージョン履歴
改訂番号
1/1
最終更新:
‎01-25-2015 02:22 AM
更新者: