// 概要 //
本記事ではMXのAuto VPN機能においてVPNトンネルの確立に問題が発生した場合の切り分け及び対応方法について解説しています。
VPNトンネルの確立後に発生する問題（VPN経由での通信不可事象や速度遅延、Auto VPN機能を前提とた各種SD-WAN関連機能における問題等）については、本記事の対象外としております。
VPNトンネルの確立において問題が発生する場合、通常”セキュリティ＆SD-WAM” > “VPNの状況”の画面において対向ピアとの接続が下記のように赤い状態となります。
またイベントログ上でも以下のように ピアのconnectivityがfalseに変化(復旧時にはtrue）した事が記録されます。
// Auto VPNについて//
MerakiのAuto VPNはこちらの仕組みによって実現されますが、前提として各機器の情報（パブリックIPアドレス、UDPポート）がVPNレジストリに登録され各機器がそれを参照し、MXがNATの背後であってもUDP hole punchingの仕組みによりVPNの通信を実現しています。
各MXは機器起動時に自身が送信元に利用するUDPポートをランダムに採択し、これは再起動によって変化しますが上述の通り都度VPNレジストリを介して対向ピアに伝達されることで、再度VPNの通信が確立される仕組みとなります。上記利用ポートについては”セキュリティ＆SD-WAM” > “VPNの状況” の画面にて確認が可能です。
上記例においてはVPNレジストリへの接続に問題がなく、またMXがNAT配下で動作しており、MX自身のWANのIPアドレスは192.168.10.254でUDPポートは43610を利用しています。
上位のNATにてグローバルIPアドレス（xxx.xxx.17.166）に変換されポートは同じものが送信元ポートとして利用されています。
この箇所にてunfriendly NATで表示される場合や、そもそもVPNレジストリの接続に問題が出ているような場合はこちらの手順にしたがって事象解消をする必要があります。なお、VPNレジストリへの接続に問題があってもそれが即座にVPNの通信自体に影響を及ぼすわけではありません。
// 影響範囲の考え方について//
VPNトンネルの確立の問題においては、まずは事象発生タイミングがポイントの一つとなり以下のように整理します。
(1)新規の機器設置時（これまでに一度もVPNの通信が確立していない場合）
この場合、 再度通信要件を見直し下記に対して上流環境で制御を実施していないかを確認します。または該当環境の上流がunfriendly NATとなっていないか等を確認します。
・Ports used for IPsec tunneling:
Source UDP port range 32768-61000
Destination UDP port range 32768-61000
(2) 機器運用時における発生
上記の通信要件に関わるような変更作業などが特になかった場合、問題がある区間においてのトラブルシューティングを行いますがこの場合事象が単一区間か複数区間で発生しているかを確認します。
・単一区間
下記のような例の場合、事象は拠点AのSpokeだけで発生しておりその他の拠点については問題ないことから拠点A側の問題である可能性が高くなります。
HUB — 拠点AのSpoke
・複数区間
下記のような例で事象がすべての拠点で発生している場合、HUB側に事象発生要因がある可能性が高くなります。
HUB
┣拠点AのSpoke
┣拠点BのSpoke
┗拠点CのSpoke
以降に具体的な事象発生事例とそれぞれの確認・対応方法を記載します。
なお、事象がすでに解消している場合は事象発生時のパケットキャプチャ実施が実施できず原因特定が難しい場合もあります。
// 主な原因と問題切り分け方法 //
上記にて事象発生箇所を絞り込んだ場合、特に事象発生時にリアルタイムでのトラブルシューティングを実施する場合はまずは調査対象の事象発生区間の情報を整理します。
その後、事象発生時においてそれぞれのMXのインターネットポートにてこちらの手順でパケットキャプチャを実施し、双方向通信ができているかを確認します。
この場合、本事象においてはインターフェースにSite-to-Site VPNは利用せず、WANポートである「インターネット」を指定します。
以下の例では事象発生が複数区間である場合において、上述のような”HUBと拠点A間”での調査パターンを例にしており、各MX のパブリックIPアドレスと利用ポートは下記の通りです。
また、それぞれFriendly NATの背後にありVPNレジストリへの通信も問題がない事を前提としています。
HUB (3.3.3.3:35000 behind NAT) —— 拠点A間 (4.4.4.4:40000 behind NAT)
この場合に期待される通信としては、 HUBは4.4.4.4に対し宛先ポート40000（送信元ポートは自身の35000）でUDP通信をし、その逆方向で拠点AのMXは3.3.3.3に対して宛先ポート35000（送信元ポートは自身の40000）でUDPパケットを送信します。
そのため、問題がない場合は互いのMXのWAN側では必ず双方向通信が確認できますが、いずれかのMXで片方向通信となっている場合としては主に下記のような事項が考えられます。
(1)MXの上流（機器・ISP）の障害
この場合MX自体もオフラインとなる場合がありますが、すでに事象が解消しているような場合は対象MX画面の「デバイスの履歴データ 」より「接続不可」等となっている箇所がないか、または「アップリンク」画面の「デバイスの履歴データ」にて事象発生時間に高い損失がないか等の詳細確認が可能です。
例：5/16の10:49頃から8分程度MXが接続不可となっている場合
例：5/10の12:00前後にアップリンクにて最大26.5%の損失が出ている場合
※この情報はインターネット上にある特定のIPアドレス(デフォルトではGoogle Public DNS(8.8.8.8))に対しての疎通確認であり、Meraki側サーバやデバイス動作との関連はありません。
(2)MX上流のNAT機器の問題
上記の問題がなく、また対向ピアがパケットキャプチャ上で正しいパブリックIPアドレスと宛先ポートに通信をしているにも関わらずそれが見えていないような場合、上流NAT機器が正常に動作しておらず配下のMXに必要な通信を届けられていないといったことが考えられます。
その場合、NAT機器のWAN側とMXと接続しているLAN側でパケットキャプチャをすることで詳細確認可能で、またはNAT機器再起動によって事象解消を試みることが可能です。
下記例のパケットキャプチャでは、NAT配下のHUB側（10.x.x.x）において対向ピア(xxx.xxx.165.2)からのUDPパケットが確認できず、下記のように自身の機器が対向ピアに送信している事だけが確認できます。
(3) UDP チェックサムにおける問題
互いのMXのWAN側で問題なく双方向通信となっていることが確認できた場合でも、UDP Checksum Errorsを原因とした（invalidもしくはbad UDP checksumが検知される等）ことでトンネルが確立できない問題が発生する場合があります。
この原因としては、主にMXの上流機器を経由することによってchecksumがinvalid になるようなケースです。
下記パケットキャプチャの例では対向ピアxxx.xxx.54.12からのUDPパケットのchecksumの箇所がBad checksumのErrorとなっています。
Wiresharkではパケットの詳細画面にて右クリック、“User Datagram Protocol” ＞ “Protocol Preferences”、“Validate UDP Checksum if Possible”にチェックを入れることで上記画面のようにわかりやすい形で確認可能です。
この場合、上位機器の再起動やファームウェアバージョンアップ等で解消しない場合は回避方法としては上流機器を介さない構成とするか、別の上位機器を利用することで改善を試みます。
// 参考情報 //
Site-to-Site VPN Troubleshooting
Meraki Auto VPN - Configuration and Troubleshooting
