Skip to main content
Cisco Meraki

Meraki以外のサイト間VPNピアのトラブルシューティング

MXセキュリティ アプライアンスは、Meraki以外のデバイスへのVPNトンネルを設定する機能を備えています。 この記事では、Meraki以外のVPNの考慮事項、必要な構成設定、およびMXからMeraki以外へのVPN接続のトラブルシューティング方法について説明します。

Meraki間VPNのトラブルシューティングについては、サイト間VPNのトラブルシューティングを参照してください。

Cisco Meraki VPNの設定と要件

VPNの概念が説明されているナレッジ ベースの記事: IPsecおよびIKEを参照してください。

Meraki以外のピアへのVPN接続の場合、Cisco Merakiデバイスには以下のものが必要です。

  • 事前共有キー(証明書は不要)。
  • LANのスタティック ルート(VPNインターフェイス用のルーティング プロトコルは不要)。
  • メイン モードのIKEv1またはIKEv2(アグレッシブ モードはサポートされません)。
  • UDPポート500および4500によるアクセス。

IKEv2はバージョン15.12以上のファームウェアを実行しているMXセキュリティ アプライアンスでのみサポートされることに注意してください。  このバージョンのIKEが機能するためには、Cisco Merakiサポートによる有効化も必要です。 

次のIKEおよびIPsecパラメータは、MXで使用されるデフォルト設定です。

  • フェーズ1(IKEポリシー):3DES、SHA1、DHグループ2、ライフタイム8時間(28,800秒)。

  • フェーズ2(IPsecルール):3DESまたはAESのいずれか、MD5またはSHA1のいずれか、PFS無効、ライフタイム8時間(28,800秒)。

これらの設定は、可能なときにはデフォルトのままにしておくことをお勧めします。リモート ピアで必要な場合は、カスタムIPsecポリシーを実装することによって、これらのパラメータを変更できます。

 

Meraki以外のVPNピアはオーガナイゼーション全体が対象になるため、ピアはオーガナイゼーション内にあるこれらすべてのMXデバイスに対して設定されます。複数のMXを同じサードパーティVPNピアに接続する必要がある場合には、すべてに同じ共有シークレットが必要です。

 

Meraki以外のVPN接続は、プライマリ インターネット アップリンクを使用して確立されます。 プライマリ アップリンクに障害が発生した場合、VPN接続はセカンダリ インターネット アップリンクを使用します。フェールオーバーが発生した場合、サードパーティのピアは、セカンダリ アップリンクのIPアドレスが適切に設定されている必要があることに注意してください。プライマリ アップリンク設定は、Security & SD-WAN(セキュリティ& SD-WAN) > Configure(設定) > SD-WAN & traffic shaping(SD-WAN & トラフィック シェーピング) > Uplink selection(アップリンクの選択) > Global preferences(グローバル環境設定) > Primary uplink(プライマリ アップリンク)にあります。

 

異なるオーガナイゼーションにある2台のMXデバイス間でVPNを構築するには、Meraki以外のVPNピア接続が必要です。詳細については、ドキュメンテーションを参照してください。

イベントログを使用したトラブルシューティング

イベントログは、Network-wide(ネットワーク全体) > Monitor(監視) > Event log(イベントログ)から表示できます。All Non-Meraki / Client VPN(すべてのMeraki以外/クライアントVPN)イベントログ タイプを単独のEvent type include(含むイベント タイプ)オプションとして選択して、「Search(検索)」ボタンをクリックします。問題が発生した具体的な時間を知る必要がある場合は、特定の時間範囲を定義して、結果を絞り込むこともできます。

3rd party event log.PNG

以下のログ エントリは、MX(IP:1.1.1.1)とMeraki以外のVPNデバイス(IP:2.2.2.2)の間のVPN接続が正常であることを示しています。

 

Jan 1 06:50:05 VPN msg: IPsec-SA established: ESP/Tunnel 1.1.1.1[4500]->2.2.2.2[4500] spi=122738512(0x750d750)
Jan 1 06:50:04 VPN msg: initiate new phase 2 negotiation: 1.1.1.1[4500]<=>2.2.2.2[4500]
Jan 1 06:50:04 VPN msg: ISAKMP-SA established 1.1.1.1[4500]-2.2.2.2[4500] spi:91f7c94b98a41ce8:85abf36d937b096f
Jan 1 06:50:03 VPN msg: initiate new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]

 フェーズ1または2のネゴシエーション中に障害があったことを示すエントリがないか、イベントログを確認します。 以下は、フェーズ1の障害を示すログ エントリの例です。 

 

May 8 07:23:53 VPN msg: failed to get valid proposal.
May 8 07:23:53 VPN msg: no suitable proposal found.
May 8 07:23:43 VPN msg: phase1 negotiation failed.

イベントログ:「no-proposal-chosen received」(フェーズ1)

エラーの説明: フェーズ1を確立できません。ダッシュボードのイベントログに「no-proposal-chosen received in informational exchange」というエラーが記録されています。

エラーの解決策: このエラーは一般に、2台のVPNアプライアンス間で設定が一致していないことによって発生します。 以下に示すステップは、問題のトラブルシューティングに役立ちます。

  1. フェーズ1のパラメータが一致していることを確認します。
  2. 事前共有シークレットが同じであることを確認します。
  3. 各サイドがトンネルに記述されてるピア アドレスに到達できることを確認します。
  4. アウトバウンド インターフェイスでISAKMPが有効であることを確認します。

イベントログ:「no-proposal-chosen received」(フェーズ2)

エラーの説明: トンネルを確立できません。イベントログにはフェーズ1のネゴシエーションの成功が示されていますが、フェーズ2の開始フェーズの後にエラー メッセージ「no-proposal-chosen received in informational exchange」が記録されています。

エラーの解決策:これはフェーズ2のセキュリティ アソシエーションが一致していないために発生することがあります。サードパーティのVPNピアが同じフェーズ2パラメータを共有していることと、以下の要件が満たされていることを確認してください。

  • ライフタイム:時間に基づくライフタイム(データに基づくライフタイムを使用しない)
  • IKEのバージョン:v1/v2(IKEv2は15.12以上のファームウェアを実行しているMXデバイスでのみサポートされ、Merakiサポートによって有効化される必要があります)
  • モード:VPNにはトランスポート モードではなくトンネル モードを使用します

イベントログ:「failed to pre-process ph2 packet/failed to get sainfo」

エラーの説明: トンネルを確立できません。ダッシュボードのイベントログにエラー「msg: failed to pre-process ph2 packet (side:1, status:1),  msg: failed to get sainfo」が記録されています。

エラーの解決策:これはIPsecトンネル定義内のサブネットの不一致(一般にサブネット マスクの不一致)によって発生することがあります。VPNトンネルの両側でローカルおよびリモート サブネットが一致していることを確認します。

このエラーは、Microsoft Azureを使用してVPNトンネルの確立を試みたときに発生することがあります。詳細については、この記事のMicrosoft Azureのトラブルシューティングのセクションを参照してください。

 

イベントログ:「invalid flag 0x08」

エラーの説明: MXはIKEv1およびIKEv2を使用しているサイト間VPNをサポートします(IKEv2はファームウェア15.12以上を実行しているMXアプライアンスでサポートされます)。IKEのバージョンが各エンドで設定されているバージョンに一致しない場合、メッセージ「invalid flag 0x08」がイベントログに記録されることがあります。

エラーの解決策:リモート ピアで使用されているIKEのバージョンがMXアプライアンスと互換性があることを確認します。  MXリモート ピアが、バージョン15.12未満のファームウェアを実行しているピアへのトンネルの確立を試みる場合、リモート エンドが使用するバージョンをIKE v2からv1に切り替えてください。  

イベントログ:「exchange Aggressive not allowed in any applicable rmconf」

エラーの説明: MXは、フェーズ1のネゴシエーションについてメイン モードのみをサポートします。Meraki以外のピアがアグレッシブ モードを使用するように設定されている場合、トンネルの確立に失敗したことを示すこのエラーがイベントログに記録されることがあります。

エラーの解決策: フェーズ1ではメイン モードを使用するようにリモート ピアの設定を変更します。

イベントログ:「exchange Identity Protection not allowed in any applicable rmconf.」

エラーの説明: 1つ以上のピアで有効なフェーズ1設定がないため、ピア間の不一致が発生しています。これは、リモート ピアがアグレッシブ モードISAKMP(MXによってサポートされません)について設定されているか、ダッシュボードでまったく設定されていないサードパーティ ピアからMXがISAKMPトラフィックを受信した場合にも発生します。

エラーの解決策: 両方のピアでフェーズ1設定が一致することと、リモート ピアがメイン モードで設定されていることを確認します。フォローアップ ステップとして、MXのプライマリ インターネット インターフェイスのパケット キャプチャを取り、IPアドレスと「isakmp」でフィルタリングして、両方のピアが通信していることを確認します。また、IPアドレスを調べて、ダッシュボードで追加された有効なピアであることを確認します。

イベントログ:「phase1 negotiation failed due to time up」

エラーの説明: まだトンネルを確立していないMeraki以外のVPNピアに対して、VPNピアバインド トラフィックが生成されました。 トンネルを確立するためにフェーズ1ネゴシエーションの開始を試みましたが、リモート側から応答がありませんでした。

エラーの解決策: 何らかの単純なテスト(pingなど)を行って、2つのサイト間のパケット損失を調べます。パケット キャプチャを取り、ローカル ピアからISAKMPトラフィックが送信されていることを確認します。ISAKMPトラフィックが受信されても、リモート側が応答しない場合は、リモート側がローカル ピアとのトンネルを確立するように設定されていることを確認します。

トンネルを介して通信できるホストと通信できないホストがある

エラーの説明: トンネルは正常に確立されましたが、一部のホストがトンネルを介して通信できません。

エラーの解決策:一部のホストでVPNトンネル経由でのトラフィックの送信に問題があり、他のホストにはない場合、最も可能性の高い原因は、クライアント システムからのパケットがMXにルーティングされていないことにあります。クライアント システムのゲートウェイが正しくないか、サブネット マスクが正しくありません。

しばらくすると、トンネルが定期的にダウンする

エラーの説明: トンネルは正常に確立され、トラフィックの受け渡しができますが、ある程度の時間がたつと、トンネルがダウンします。

エラーの解決策: フェーズ2のライフタイムがMXとリモート ピアの間で一致していない場合、短い方のフェーズ2ライフタイムが経過するまで、トンネルは確立され、正常に機能します。両方のピアでフェーズ2のライフタイムが同じに設定されていることを確認します。MXのデフォルトは28,800秒であり、MXはデータに基づくライフタイムをサポートしていません。

まとめとベンダー固有の例

イベントログを使用して、Meraki以外のVPN接続が成功したかどうかを調べることができ、失敗エントリによってデバイス間で一致していない可能性のある設定をすばやく特定できます。デバイス間での設定の一致が確認されると、VPNトンネルが確立されたことを示すネゴシエーション成功メッセージが表示されます。 ベンダー固有の設定例については、以下のリンクを参照してください。 

Microsoft Azureのトラブルシューティング

Cisco MerakiアプライアンスとMicrosoft Azureの間のサイト間VPNの最も一般的な問題の1つは、上記のように、ローカル/リモート サブネットの不一致が原因で発生します。

Microsoft AzureでのVPN設定が完了したら、VPNトンネルを通過するように指定されているアドレス空間を確認してください。これには一般に、スーパーネット(サマリー アドレス)とその個々のサブネットが含まれます。 たとえば、192.168.10.0/24と192.168.20.0/24のネットワークをアドバタイズするとき、スーパーネットは192.168.0.0/19です。 

ダッシュボードのNon-Meraki peers(Meraki以外のピア) > Private subnets(プライベート サブネット)フィールドで、個々のサブネットではなく、Microsoft Azureネットワークのスーパーネット(この例では、192.168.0.0/19)を追加します。このようにしなかった場合、サブネットの不一致によってVPNトンネルを確立できません。

 

Meraki MXとMicrosoft Azure Gatewaysの間の互換性の制約により、MXとAzure VNet Gateways間のサイト間VPN接続が時々不安定になる場合があることに注意してください。サイト間VPNの最適なパフォーマンス、安定性、および可視性のためには、Azure MarketplaceにあるvMX100ネットワーク仮想アプライアンスを使用することをお勧めします。

 

Google Cloud VPNのトラブルシューティング

Google CloudはIPsec VPNの使用をサポートしているため、VPNピアとして機能できます。バージョン15.12未満のファームウェアを実行しているMXアプライアンスはIKEv1のみをサポートすることに注意してください。 Google側でIKEv2が設定されていた場合、トンネルは機能しません。  Google側でIKEv1を使用するように設定するか、IKEv2が必要な場合はMXのファームウェアをバージョン15.12以上にアップグレードする必要があります。 さらに、Google側のゲートウェイはICMPに応答しないため、pingテストは接続性のテストとして有効ではありません。

詳細については、クラウドVPNのセットアップに関するGoogleのドキュメンテーションを参照してください。

  • Was this article helpful?