Cisco Meraki MX（静的ルーティング）

このガイドは、Cisco Meraki MX アプライアンスが Cloudflare WAN への IPsec VPN トンネルを確立するための手順です。Cisco Meraki の管理に慣れており、有効な Cloudflare WAN サブスクリプションを持つネットワークエンジニア向けです。

以下の例のオブジェクト名と IP アドレスは、環境に合わせて置き換えてください。

トンネル作成後に IKE ID と pre-shared key を取得します。

トンネル作成後に IKE ID と pre-shared key を取得します。

モード: Routed

• ファームウェアの前提: この設定に必要な最小ファームウェアは MX 19.2.7 です。
• ハードウェア互換性: 古い Meraki ハードウェアは、物理的に 19.2.7 を実行できないことがあります。このアーキテクチャには Route-Based VPN サポートが必要です。MX プラットフォームがファームウェアリリース 19.2.7 以降に対応しているかは Product firmware restrictions ↗ を参照してください。
• Active/Standby 構成: Non-Meraki VPN 接続に関連する冗長トンネルは Active/Standby です。両方のトンネルは確立されますが、Meraki はプライマリ IPsec VPN ピア経由でのみトラフィックをルーティングし、トンネル監視プローブに基づいてセカンダリ IPsec VPN ピアへ動的にフェイルオーバーします。
  • Anycast とトンネル冗長性: MX プラットフォーム上の IPsec VPN トンネルは Active/Standby ですが、Cloudflare のリモートエンドポイント IP は Cloudflare グローバルネットワーク全体で BGP anycast により広告されるため、ネットワーク層では高可用性が維持され、地理的および論理的な冗長性が備わります。
• Route-Based VPN サポート: 特定のクラウド連携と結び付けられることが多いですが、バージョン 19.2.7 はサードパーティデバイス全般（Cloudflare WAN を含む）の Route-Based IPsec VPN をサポートします。
• 冗長性と Multi-Uplink: このドキュメントは Active/Standby トンネル構成のみを扱います。
  • Multi-Uplink IPsec VPN: Meraki の Multi-Uplink IPsec VPN ↗ 機能はこのガイドの範囲外です。
• Anti-Replay Protection: Cloudflare は、Cloudflare WAN での最適な性能のため Anti-Replay Protection を無効にする ことを推奨します。Cisco Meraki MX プラットフォームでは、管理者がこの機能を無効にできません。
  • これは既知の Meraki プラットフォームの制限です。
  • アンダーレイ（ISP ネットワーク）でジッターやパケットの順序乱れが多い環境では、IPsec VPN トンネルの MX 側で間欠的なパケットドロップが起きることがあります。
• MSS Clamping: Cloudflare は、IPsec オーバーヘッドを考慮し、フラグメンテーションを防ぐための特定の Maximum Segment Size (MSS) クランプ 値を推奨します。
  • Meraki Dashboard には、サードパーティ VPN トンネルの MSS クランプ値を変更するユーザー向けフィールドがありません。
  • お客様は Meraki Technical Support に連絡し、特定のネットワークまたはトンネルの MSS 値（およそ 1360。値は変わることがあります）のバックエンド手動変更を依頼する必要があります。
• ISP の範囲: 提供する設定は、単一の Internet Service Provider (ISP) 向けに検証されています。冗長 ISP へ拡張するロジックはありますが、マルチホーム構成はこのガイドの範囲外です。

• この設定には、Automatic Return Routing をサポートする Unified Routing データプレーンが必要です。
• Cloudflare ダッシュボードで IPsec トンネルと静的ルートをすでに設定済みであること。
• Cloudflare ダッシュボードを使い、各 IPsec トンネルのローカル識別子（FQDN / ホスト名）を取得し、pre-shared key を生成済みであること。
• MSS clamping の重要性と、Cloudflare WAN IPsec トンネルを通るトラフィックフローに応じた調整を理解していること。

Meraki 設定を進める前に、Cloudflare 設定から次の詳細が必要です。

• IPv4 interface address values (in Classless Inter-Domain Routing (CIDR) notation)
• Cloudflare anycast IPs
• Local ID (FQDN/hostname)
• Pre-shared keys
• Remote subnets

MX プラットフォームでは、「Private subnets」は、MX アプライアンスが IPsec トンネル経由でルーティングするリモートネットワークを指します。

このドキュメントでは、次のサブネットをリモートサブネットとします。

• 172.16.10.0/24
• 172.16.11.0/24

MX プラットフォームは、プライマリとセカンダリの IPsec VPN トンネル間のフェイルオーバーを有効にするためにトンネル監視を使います。トンネル監視は、トンネル経由の接続性を検出します（BGP 有効トンネルではサポートされません）。トンネル監視は、IPsec トンネルの状態を判定する Dead Peer Detection とは独立して動作します。

トンネルヘルスプローブは、Dead Peer Detection に加えて、IPsec トンネルのリモート側リソースの到達性全体を判定するために使われます。

Meraki は、トンネル監視プローブの送信元 IP として 192.0.2.3/32（TEST-NET-1 の一部。RFC 5737 ↗ で定義）を予約しています。詳細は Primary and secondary IPsec tunnels ↗ を参照してください。

192.0.2.3/32 は従来の RFC 1918 ↗ アドレス空間の外にあるため、Cloudflare アカウントに関連する Unified Routing データプレーンに追加する必要があります。

internal_authorized_prefixes オプションをアカウントに追加し、192.0.2.3/32 を含める作業については、Cloudflare へ支援を依頼してください。

トンネル監視プローブの送信元 IP アドレスが、対象 IP/URL（HTTP — ポート 80/tcp）へ到達できる HTTP ポリシー を定義します。

Cloudflare ダッシュボードで Zero Trust > Traffic policies > Firewall policies > HTTP を開きます。

1. 新しいルールを追加します。
2. Policy Name に Meraki Tunnel Health Checks - HTTP Policy を入力します。
3. 種類 Traffic の式を組み立てます。
4. Selector に Source Internal IP is 192.0.2.3 を入力します。
5. Action で Do Not Inspect を選びます。

このポリシーは、HTTP ポリシーのルールベースの先頭またはその近くに置きます。

次の図は、予約されたトンネル監視送信元 IP（192.0.2.3/32）からのトラフィックフローです。IPsec トンネルを通って Cloudflare WAN へ進み、Cloudflare Gateway を経てインターネットへエグレスします。応答経路は完全に対称です。

flowchart LR
accTitle: Cloudflare WAN での Meraki トンネル監視
accDescr: トンネル監視送信元 IP から Meraki MX、IPsec トンネル、Cloudflare WAN、Cloudflare Gateway を経て、パブリックインターネット上の HTTP ターゲットへ向かうトラフィックフローです。
 subgraph CPE["Cisco Meraki (CPE) Active/Standby モデル"]
    direction TB
        FW["Cisco Meraki MX
        WAN: 203.0.113.100/24
        ---
        LAN: 192.168.125.1/24
        ---
        LAN Subnet: 192.168.125.0/24"]
        L7_Health_Check["L7 Health Check
        ---
        Internal Src IP: 192.0.2.3/32"]
  end
 subgraph T1["Active - IPsec トンネル 1"]
    direction LR
        T1_CPE["CPE VTI 1
        Internal to MX"]
        T1_CF["Cloudflare VTI 1
        169.254.250.0/31"]
  end
 subgraph T2["Standby - IPsec トンネル 2"]
    direction LR
        T2_CPE["CPE VTI 2
        Internal to MX"]
        T2_CF["Cloudflare VTI 2
        169.254.250.2/31"]
  end
 subgraph CF["Cloudflare WAN"]
    direction TB
        EP1["Anycast Endpoint 1
        162.159.135.1"]
        EP2["Anycast Endpoint 2
        172.64.135.1"]
  end
 subgraph CF_GW["Cloudflare Gateway"]
    direction TB
        GW["Policy
        Src IP 192.0.2.3
        Allow"]
  end
    L7HCT["HTTP Target"]

    T1_CPE === T1_CF
    T2_CPE === T2_CF
    FW <==> T1_CPE & T2_CPE
    T1_CF <==> EP1
    T2_CF <==> EP2

    L7_Health_Check -.-> FW
    FW -.-> T1_CPE
    FW -.-> T2_CPE
    T1_CPE -.-> T1_CF
    T2_CPE -.-> T2_CF
    T1_CF -.-> EP1
    T2_CF -.-> EP2
    EP1 -.-> GW
    EP2 -.-> GW
    GW -.-> L7HCT
    FW@{ shape: stadium}
    T1_CPE@{ shape: stadium}
    T1_CF@{ shape: stadium}
    T2_CPE@{ shape: stadium}
    T2_CF@{ shape: stadium}
    EP1@{ shape: stadium}
    EP2@{ shape: stadium}
    GW@{ shape: stadium}

Meraki の設定管理は 2 層の階層で構成されます。オブジェクトとその関連設定は、次のいずれかとして定義されます。

• Organization-wide: テナント全体で 1 回定義するグローバルオブジェクトです。
• Network-specific: 個々のサイトまたはデバイスに適用する設定です。

Non-Meraki VPN 設定は Organization 層のオブジェクトです。対応する Network Tag に関連付けると、特定の MX アプライアンスへプッシュされます。この継承モデルは重要な要素です。タグが、どの物理ハードウェアが Cloudflare へのトンネル確立を試みるかを制御します。

Orbital Path Ventures は、Meraki Dashboard で定義された Organization を表すために、設定全体で参照する架空の会社です。

この会社は Austin, TX の支店で 1 台の Meraki MX アプライアンスを管理し、Orbital Path Ventures - Austin TX という Network に関連付けています。

Orbital_Path_AUS_Office という Network Tag が、Orbital Path Ventures - Austin TX Network に関連付けられています。

Network > Networks を開き、Organization を選びます。

• Orbit Path Ventures（Organization 名を置き換えます）。
• Network: Orbit Path Ventures - Austin TX（Network 名を置き換えます）。
• Tag: Orbital_Path_AUS_Office（Network 名に関連付けた Tag を置き換えます）。

Cloudflare WAN と連携するとき、Meraki Network Tag は、どのアプライアンスが Cloudflare トンネル設定を継承するかを決めます。

Non-Meraki VPN 設定はグローバルオブジェクトです。関連する Network Tag を持つ MX アプライアンスは、同じ IPsec VPN ピアを使って Cloudflare へのトンネル確立を試みます。

予測可能なトラフィックフローを確保し、ルーティングの競合を防ぐため、Cloudflare は次のベストプラクティスを推奨します。

• 厳密なトンネル対応: Cloudflare で定義した冗長 IPsec トンネルペアと、それらのトンネルを開始する特定の MX アプライアンスを 1 対 1 で対応させます。
• サイト固有の Network Tag: 広い汎用タグではなく、粒度の細かいサイト固有タグ（例: Orbital_Path_AUS_Office）を使い、意図した MX だけがトンネル設定を継承するようにします。
• 一意の IPsec VPN ピアオブジェクト: 物理的な地理的場所が異なる場合は、Organization レベルで別々の Non-Meraki VPN ピアオブジェクトを作成します。Availability オプションで 1 対 1 の対応を確立します。

Cloudflare WAN からの戻りトラフィックは、Cloudflare の仮想ネットワークルーティングテーブルに基づいて誘導されます（詳細は トラフィックステアリング を参照）。ルートは MX LAN プレフィックスと対応する IPsec トンネルに基づいて指定します。

Source-Based Default Routing ↗ を使うと、管理者は送信元ベースのデフォルトルートを作成し、Auto VPN 上のセキュリティアプライアンス、または LAN 上のデバイスをネクストホップとして指定できます。

Source-Based Default Routing は、Cloudflare WAN を含む Non-Meraki VPN エンドポイントと併用できません。

MX アプライアンスが各トンネル経由でトラフィックを誘導する方法を制御するには、IPsec VPN ピア設定でプライベートサブネットを定義します。

IPsec VPN ピア設定でプライベートサブネットとして定義した IP プレフィックスは、プライマリおよびセカンダリ VPN トンネルを通るトラフィックを制御します。特定の MX アプライアンスに対応するルーティングテーブルに表示されます。

このドキュメントでは、次の 3 つのルートトポロジを扱います。

1. 東西のみ:
   • Cloudflare WAN 経由のプライベートトラフィック。
   • ローカルインターネット経由のインターネット。
2. Cloudflare Gateway 経由のインターネットのみ:
   • インターネットトラフィックだけを Cloudflare WAN 経由でルーティングします。
3. Cloudflare WAN と Gateway 経由のすべてのトラフィック:
   • 東西およびインターネットトラフィックを Cloudflare WAN 経由でルーティングします。

3 つのトポロジはすべて IPsec VPN ピア セクションで扱います。

Security & SD-WAN > Site-to-site VPN を開きます。

Hub (Mesh) を選びます。

MX デバイスの背後にあるローカルネットワークで VPN モードをオンにします。

変更前:

変更後:

Security & SD-WAN > Site-to-site VPN > Organization Wide Settings を開きます。

MX プラットフォームが IPsec VPN トンネル経由のリソース到達性を判定するために使う、レイヤー 7 ヘルスチェック HTTP プローブを設定します。

1. Configure Health Checks を選びます。

2. 次の値を指定します。

   Name	Endpoint
   Google	http://www.google.com

3. OK を選びます。

次のトポロジ向けに IPsec VPN ピア設定を提供します。

• 東西トラフィックのみ
• Cloudflare Gateway 経由のインターネットのみ
• Cloudflare WAN と Gateway 経由のすべてのトラフィック

Cloudflare WAN 経由で東西トラフィックをルーティングするには、次が必要です。

• MX アプライアンスの背後の LAN サブネット（192.168.125.0/24）向けに、CF_WAN_TUN_01 と CF_WAN_TUN_02 経由の Cloudflare ルートを指定する。
• リモートサブネット（172.16.10.0/24 と 172.16.11.0/24）を、Meraki のプライマリおよびセカンダリ IPsec VPN ピアのプライベートサブネットとして指定する。
• CF_WAN_TUN_01 と CF_WAN_TUN_02 の両方に指定した IPv4 インターフェイスアドレスプレフィックス（169.254.250.0/31 と 169.254.250.2/31）を、Meraki のプライマリおよびセカンダリ IPsec VPN ピアのプライベートサブネットとして指定する。

これにより次が保証されます。

• Cloudflare は、MX アプライアンスの背後の LAN サブネット宛てのトラフィックを CF_WAN_TUN_01 と CF_WAN_TUN_02 経由でルーティングします。
• MX アプライアンスは、リモートサブネット（172.16.10.0/24 と 172.16.11.0/24）宛てのトラフィックを、それぞれプライマリおよびセカンダリ IPsec VPN ピア経由で明示的にルーティングします。
• MX アプライアンスは、Cloudflare トンネルヘルスチェックに関連する ICMP Reply パケットを、CF_WAN_TUN_01 と CF_WAN_TUN_02 に指定した IPv4 インターフェイスアドレス（169.254.250.0/31 と 169.254.250.2/31）へ、それぞれプライマリおよびセカンダリ IPsec VPN ピア経由で明示的にルーティングします。
• MX アプライアンスの背後の LAN サブネットからのインターネットトラフィックは、WAN アップリンク経由でルーティングされます。
• MX アプライアンスは、WAN アップリンク経由で Cloudflare エンドポイント（162.159.135.1 と 172.64.135.1）への IPsec トンネルを確立します。

次を設定します。

Cloudflare IPsec トンネル — automatic return routing:

Cloudflare ルート:

Meraki プライベートサブネット:

1. + Add a peer を選びます。

2. 次の値を指定します。

   Attribute	Value
   Name	cf-wan-tun-01
   IKE Version	IKEv2
   Public IP or Hostname	162.159.135.1
   Local ID	bf6c493d03<REDACTED>.ipsec.cloudflare.com
   Remote ID	—
   Shared Secret	Cloudflare-WAN-T1-PSK-1234!
   Routing	Static
   Private Subnets	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24
   Availability	Orbital_Path_AUS_Office
   Tunnel Monitoring	Google Health Check
   Failover directly to internet	—
   IPsec Policy	—
   Preset	Custom
   Phase 1 — Encryption	AES 256
   Phase 1 — Authentication	SHA256
   Phase 1 — Pseudo-Random Function	SHA256
   Phase 1 — Diffie-Hellman group	14
   Phase 1 — Lifetime (sec)	28800
   Phase 2 — Encryption	AES256
   Phase 2 — Authentication	SHA256
   Phase 2 — PFS Group	14
   Phase 2 — Lifetime (sec)	28800

3. Save を選びます。

1. 設定列の --- アイコンを選びます。

2. + Add secondary peer を選びます。

3. Inherit primary peer configurations は選ばないでください。Public IP or Hostname、Local ID、Remote ID、Shared secret が、IPsec トンネル CF_WAN_TUN_02 のネゴシエーションに必要な設定になるようにします。

4. 次の値を指定します。

   Attribute	Value
   Name	cf-wan-tun-02
   IKE Version	IKEv2 (Inherited)
   Public IP or Hostname	172.64.135.1
   Local ID	0287844e9d<REDACTED>.ipsec.cloudflare.com
   Remote ID	172.64.135.1
   Shared Secret	Cloudflare-WAN-T2-PSK-1234!
   Routing	Static (Inherited)
   Private Subnets	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24 (Inherited)
   Availability	Orbital_Path_AUS_Office (Inherited)
   Tunnel Monitoring	Google Health Check
   Failover directly to internet	—
   IPsec Policy	—
   Preset	Custom
   Phase 1 — Encryption	AES 256
   Phase 1 — Authentication	SHA256
   Phase 1 — Pseudo-Random Function	SHA256
   Phase 1 — Diffie-Hellman group	14
   Phase 1 — Lifetime (sec)	28800
   Phase 2 — Encryption	AES256
   Phase 2 — Authentication	SHA256
   Phase 2 — PFS Group	14
   Phase 2 — Lifetime (sec)	28800

5. Save を選びます。

MX アプライアンスのルートテーブルに、プライマリおよびセカンダリ IPsec VPN ピア設定で定義したプライベートサブネット向けのルートが含まれることを確認します。

Security & SD-WAN > Monitor > Route table を開きます。

Meraki のルートテーブルは、cf-wan-tun-01 と cf-wan-tun-02 経由のルートを次のように反映します。

Meraki はトンネル監視を使い、セカンダリ IPsec VPN ピアへの自動フェイルオーバーのタイミングを判定します。Meraki は Dead Peer Detection を使い、IPsec トンネル全体の健全性を判定します。

Non-Meraki VPN ピアは Active/Standby モデルに対応します。フェイルオーバーが起きるまでトラフィックは cf-wan-tun-01 経由で送られ、その時点で cf-wan-tun-02 がアクティブになります。トンネルが再接続されると、トラフィックは動的に cf-wan-tun-01 へ戻されます。

フェイルオーバーテストでは、数秒間トラフィックが中断されることがあります。Cloudflare は 15〜20 秒かかるフェイルオーバーも観測していますが、こうした事象はまれです。

Cloudflare のトンネルヘルスチェックは、スタンバイとマークされたトンネルで 100% 失敗を示します。これにより、トラフィックはアクティブなトンネル経由でのみ誘導されます。

Meraki Dashboard を使い、IPsec トンネルのステータスを確認します。

1. Security & SD-WAN > Monitor > VPN Status を開きます。
2. Overview セクションまでスクロールします。
3. 2 IPsec peers というフィルタを選びます。

アクティブトンネル: cf-wan-tun-01:

アクティブトンネル: cf-wan-tun-02:

アクティブトンネル: cf-wan-tun-01:

アクティブトンネル: cf-wan-tun-02:

アクティブトンネル: cf-wan-tun-01:

アクティブトンネル: cf-wan-tun-02:

IPsec トンネル経由でルーティングされるトラフィックと、直接インターネットへルーティングされるトラフィックを判別するには、MX ルートテーブルを確認します。

Security & SD-WAN > Monitor > Route Table を開きます。

VPN Status が、両方のトンネルでヘルスチェックが失敗していると報告します。

Cloudflare Gateway のログとポリシーを確認し、192.0.2.3/32 を送信元とする HTTP リクエストがブロックされていないかを判定します。

ブロックされている場合は、トンネル監視 HTTP リクエストを復元するルールを作成します。詳細は Cloudflare Gateway HTTP ポリシー を参照してください。

次で利用できます。

• Log Explorer
• Logpush > IPsec logs

IPsec ログは、IPsec トンネル関連のさまざまな問題の診断に役立ちます。次を含みます。

• サポートされない Phase 1 または Phase 2 の暗号化または完全性設定を使っている — No proposal chosen を示すメッセージを探します。
  • 定義した Phase 1 および Phase 2 の暗号化または完全性の値が Cloudflare WAN でサポートされていることを確認します。
  • サポートされる設定パラメーター を参照してください。
• IKE/IPsec ID: ローカルまたはリモート ID が未定義、または値が正しくない。
  • FQDN ベースのローカル識別の例は Palo Alto サードパーティ連携ガイド を参照してください。
• 認証失敗: pre-shared key が間違っている。

詳細は トンネルエンドポイントを設定する を参照してください。

CF_WAN_TUN_01 と CF_WAN_TUN_02 の両方のトンネルヘルスチェックが、次の設定になっていることを確認します。

• Connection Monitoring for WAN Failover ↗
• MX Routing Behavior ↗
• Organization Overview ↗
• Primary and Secondary IPsec VPN Tunnels ↗
• Site-to-Site VPN ↗