概要
本記事では、Auto VPN における、Unfriendly 状態の理解とトラブルシュートについて記載をしております。
Auto VPN におけるトンネル確立のトラブルシュートは以下の記事をご参照ください。
Auto VPN機能におけるVPNトンネル確立のトラブルシューティングについて - The Meraki Community
Auto VPN の前提理解
NAT デバイスのLAN 側でMX を利用する場合、通常のIPsec-VPN では、そのNAT デバイスでUDP port 500,4500 をMX に対してポートフォワーディングする設定が必要となります。
しかし、Auto VPN では、UDP ホールパンチングという仕組みを利用してNAT 配下の場合にも、特に設定変更を意識せずにVPN を構築することが可能となります。※NAT デバイスやFW が厳しい要件の場合の例外はあります。
Auto VPN のUDP ホールパンチングの仕組みについては深く解説しませんが、前提理解のため簡単に記載をいたします。
初めにVPN Registry と呼ばれるMeraki クラウド側のサーバと接続を実施し、同じダッシュボードネットワークでVPN を有効としている隣接情報を取得します。
これによって、接続先のIP アドレスとポート番号などの情報がMX 間で通知されます。
(Warm spare 構成の場合、Spare 機器に切り替わる際にもPrimary と同じポートが使われます。)
*構成例(アップリンクにファイアウォールデバイスが存在する想定)
その後、Registry から取得した情報をもとに拠点間でVPN のコネクションを実施します。
一般的に、ファイアウォールではWAN からのインバウンド通信に対してブロックされる動作となるため、図の通りにブロックされる動作となります。
その後、先ほどの通信で拠点のアップストリームファイアウォールではNAT テーブルが生成され、ステートフルファイアウォールによって戻りのトラフィックが許可されるため、
パケットがNAT デバイスを超えてMX に到達することになります。これが、UDP ホールパンチングという仕組みになります。
Auto VPN とUDP ホールパンチングの詳細については、以下のドキュメントも参考となります。
Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation
Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers - Cisco Meraki Documentati...
Unfriendly 状態について
UDP ホールパンチングは、拠点間のMX で一貫した IP アドレスとポートである必要があります。
VPN Registry は冗長性のために2 つのサーバーが使用されており、どちらもMX が同じパブリック IP アドレスとポートで利用可能であることを確認しています。
Unfriendly 状態としてマークされる場合、以下の状態にあることが考えられます。
1. 一部のNAT デバイス(ファイアウォールなど)で、VPN registry ごとに異なるソースポートに書き換え通信を実施している。
2. 一部のNAT デバイスまたはロードバランサーで、VPN registry ごとに2つの異なるパブリックIP アドレスを用いて通信を実施している。
これは、SNAT Load Balancing とも呼ばれる機能となります。
また、このような環境やCarrier-Grade NAT(通信事業者がIP 枯渇の対策として利用する機能)環境においては、Auto VPN に関するポート番号が変更されることでUDP ホールパンチングが機能しない場合があります。
以下の例では、片側のファイアウォール にて送信元ポート番号が変更されたことでUDP ホールパンチングが機能せずVPN パケットが通過できない状態となっています。
トラブルシュート
解決策1：
MX のアップストリームのNAT デバイスでPreserve Source Port（送信元ポートの保持）設定を有効にする。
この問題は、パブリックIP とポート番号の組み合わせが変更されることによって発生するため、書き換えをしないことで解消する可能性があります。
以下の例では、赤い丸のデバイスが送信元ポート番号を変更しているため、設定対象となります。
NAT デバイスのPreserve Source Port 設定に関しては、ご利用機器のベンダに確認をいただくことが推奨されます。
解決策2：
MX のアップストリームファイアウォールデバイスによっては、MX のWarm spare の切り替わり時に、MX の送信元IP が変更となることで、転送時の送信元ポートを変更する動作をとる場合があります。
NAT 配下でMX を利用する場合、耐障害性を高めるためにも仮想IP を用いて、MX が利用するIP を1つとすることで解決する可能性があります。
以下の例では、Spoke 拠点がWarm spare 構成を取っていると仮定した時、赤い丸のデバイスが設定対象となります。
MX の仮想IP の設定方法は以下のドキュメントをご参照ください。
MX Warm Spare - High-Availability Pair - Cisco Meraki Documentation
NAT デバイスにて、SNAT Load Balancing などが利用されており、VPN Registry 宛ての通信が2つのパブリック IP アドレスに変換されてしまっている場合、
内部からのMX のトラフィックを単一のパブリックIP アドレスにマッピングするように設定を行います。
これにより、VPN レジストリで参照されるパブリック IP アドレスが常に同じになるため、解決する可能性があります。
以下の例では、赤い丸のデバイスがパブリックIP を複数のIP に変更している想定のため、設定対象となります。
SNAT Load Balancing は、Cisco RT などであればNAT Pool を用いたOverload の設定となるため、
これを1つのパブリックIP を利用するように設定変更を行う必要があります。(1:1 NAT など)
解決策4：
Meraki ダッシュボードにて、Auto VPN の手動ポート転送にて任意のポート番号を設定し、アップストリームファイアウォールでポートフォワーディング機能を有効にして、MX へトラフィックを転送する。
これによってポート書き換えされたトラフィックを転送することが可能となるため、解決する可能性があります。
以下の例では、赤い丸のデバイスとMX が設定対象となります。
まずは、セキュリティ&SD-WAN > サイト間VPN > NAT トラバーサル > 手動: ポート転送 にて、左側の拠点で利用されるパブリックIP と任意のポート番号の指定を行います。（ポート範囲は1024-65535）
例の場合は、Spoke からHub に対してUDP 60000 を宛先としてUDP ホールパンチングが行われます。
次に、Hub 拠点のアップストリームファイアウォールにてUDP 60000 で受けたトラフィックをLAN 側のMX へ転送するようにポートフォワーディングの設定を行います。
これにより、Hub に到達できるようになります。
Hub はVPN Registry から取得した情報に存在しないSpoke から有効なAuto VPN パケットを受信すると、パケットのパブリックIP とUDP ポートを使用して新しいコネクションベースのエントリを追加してVPN 通信を開始します。
デモンストレーション
Fortigate 50E(v6.2.16 build1392 (GA)) を用いて疑似的にUnfriendly 状態を再現し、アップリンクデバイスにて状況を確認しました。
デモンストレーション構成は以下の試験構成となります。
※試験結果は、あくまで試験としての参考情報としていただけますと幸いです。
また、こちらはラボ環境の設定例となります。ファームウェアバージョンなどによっても変動する可能性はありますので、
設定などの詳細はベンダーへご確認ください。
シナリオ：NAT デバイスが送信元ポートを変更してしまう環境にて、Primary 機器をダウンさせた時の挙動
通常時、VPN Registry への通信は、Primary 機器から送信されたものが確認されています。
Primary 機器の電源断を行い、Warm spare の切り替えを実施します。すると、新しくSecondary 機器のNAT テーブルが作成されます。
しかし、画像の通りにSecondary の通信の送信元ポートの書き換えが行われていることが確認できます。
この状態の場合、MXではUnfriendly 状態を検知します。
また、Secondary 機器から対向ピアに対してのVPN 通信のポート番号も変更されるため、VPN 通信に影響を及ぼすことになります。
この時、Fortigate におけるポリシーの設定では、Preserve Source Port（送信元ポートの保持）設定が無効となっていたため、有効として確認を行います。
ポリシー変更後、Primary 機器をもとに戻し、通常状態のNAT テーブルを確認します。
その後、Primary 機器の電源断を行い確認をすると、Primary 機器のNAT フローテーブルを保持せずに単一のNAT フローが残っている状態を確認することができます。
この状態の場合、MXではFriendly 状態を検知し、Auto VPN の通信に異常は見られませんでした。
また、上記検証では、MX にて個別のIP を利用する設定となっていたが、仮想IP を設定した場合には、2つのNAT フローが作成されることはなかったため、今回の事象は発生しませんでした。
追加リソース
Carrier-Grade NAT and Meraki Auto VPN - Cisco Meraki Documentation
Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation
Meraki Auto VPN General Best Practices - Cisco Meraki Documentation
Auto VPN Hub Deployment Recommendations - Cisco Meraki Documentation
Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers - Cisco Meraki Documentati...
