MikroTik IPsec クライアント Fortigate 「不明な SPI を持つ ESP パケットを受信しました。」

Question

当社には、IPsec を使用する 6 つのサイトを持つクライアントがいます。ときどき、おそらく週に 1 回、ときには月に 1 回、リモート Fortigate VPN サーバーからローカル MikroTik IPsec VPN クライアントへのデータの流れが止まってしまいます。

問題の症状を示すために、図を添付しました。図の [インストールされた SA] タブでは、ソース IP アドレス xx186.50 が xx7.3 と通信しようとしているが、現在のバイト数は 0 であることがわかります。xx186.50 はクライアントのリモート Fortigate IPsec サーバーであり、xx7.73 は MikroTik ベースの IPsec エンドポイントです。リモート側から私たちへのデータが常に流れているわけではないようです。

フェーズ 1 と 2 は常に確立されますが、トラフィックはリモート側からこちら側に流れません。

再起動、クロックの設定、構成の調整、構成の再確認など、さまざまなことを時間をかけて試しましたが、問題は完全にランダムであるようです。また、ランダムなことが問題を解決することもあります。ある段階では、トンネルが彼ら側から開始されれば機能するという理論がありましたが、「最初のコンタクトの送信」をいじっても何も変わりませんでした。

この件についてクライアントと何度も話し合いましたが、クライアントにはさらに多くの国際 IPsec VPN があり、失敗しているのは当社の MikroTik 構成だけです。

Fortigate ログ:

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654

Fortigate のナレッジベースを見ると、SPI は一致せず、DPD が違いを生むようです。しかし、私はこちら側で DPD のあらゆる組み合わせを試しましたが、効果はありませんでした。反対側で DPD を有効にしたいのですが、変更管理のため、またクライアントが他のすべてのサイトでまったく同じ構成で動作していると言っているため、有効にできません。編集DPDが有効になりました

トラフィック フローが示されていないローカル VPN クライアントの図:

「有効な RU-THERE を受信し、ACK を送信しました」という連続ループを示す MikroTik ログ ファイルを添付しました:

echo: ipsec、debug、パケット xx7.183[500] から xx186.50[500] までの 84 バイト

エコー: ipsec、デバッグ、パケットsockname xx7.183[500]

echo: ipsec、debug、packet xx7.183[500]からパケットを送信

echo: ipsec、debug、packet パケットをxx186.50[500]に送信

エコー: ipsec、デバッグ、パケットsrc4 xx7.183[500]

エコー: ipsec、デバッグ、パケットdst4 xx186.50[500]

echo: ipsec,debug,packet 84バイトのメッセージが1回xx186.50[500]に送信されます

エコー: ipsec、デバッグ、パケット 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf

エコー: ipsec、デバッグ、パケット cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979

エコー: ipsec、デバッグ、パケット 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8

echo: ipsec、debug、packet sendto 情報通知。

エコー: ipsec、デバッグ、パケットは有効な RU-THERE を受信し、ACK が送信されました

IPsec の専門家や MikroTik 自身から、リモート側に問題があるというさまざまな提案を受けました。しかし、他の 5 つのサイトが機能しており、クライアントのファイアウォールが変更管理下にあるため、状況は大きく複雑になっています。セットアップも長年にわたって常に機能していたため、MikroTik 側の構成エラーではないと主張しています。この提案はもっともらしいように思えますが、変更管理のため実装できません。クライアント側のみ変更できる可能性があります。

IPSec レスポンダに、passive=yes と send-initial-contact=no の両方が設定されていることを確認します。

これは機能しませんでした。

編集 2013年12月9日

Fortigate 構成と、Mikrotik 側のクイック モード セレクターと思われる追加のスクリーンショットを貼り付けます。

もう一度言いますが、これは設定の問題ではないと思います。サイド A またはサイド B が情報を過度に送信しようとして、情報のネゴシエーション (SPI など) が同期しなくなるタイミングの問題ではないかと推測しています。

編集 2013年12月11日

残念ながら、この問題は諦めなければなりません。幸い、すべてうまくいっています。なぜうまくいっているのかは未だに謎ですが、私たちが行ったことをさらに説明するために、別の画像をインラインで投稿します。

以下の方法で修正しました:

1. クライアントで PPPoE をオフにします。
2. 完全に新しいルーター (ルーター B) をインストールし、Border でテストしました。Border では動作しました。
3. 境界で新しいルータ B をオフにします。その後、何も変更せずに、クライアントのエンドポイント ルータ A が動作し始めました。境界に複製ルータを追加し、このルータを再びオフラインにするだけで、元のルータが動作するようになりました。

したがって、この修正を私たちが行ったことのリストに追加します。

1. 再起動。一度はうまくいきました。
2. 新しい IP で新しいトンネルを作成します。これは一度だけ機能しましたが、一度だけです。IP を元に戻した後、クライアント エンドポイントは再び有効になりました。
3. タイムサーバーを変更します。
4. 可能なすべての設定をいじってみます。
5. 待ってください。かつては、1日経つと、すべてがうまくいきました。今回は、何日経っても、何もうまくいきませんでした。

したがって、私は、Fortigate 側または MikroTik 側のいずれかに非互換性があり、それが非常にランダムな状況でのみ発生すると仮定します。試すことができなかった唯一のことは、Fortigate のファームウェアをアップグレードすることです。おそらく、構成者には見えない隠れた破損した構成値またはタイミングの問題があるのでしょう。

さらに、この問題はタイミングの問題によって SPI の不一致が引き起こされているのではないかと推測しています。また、Fortigate は DPD が機能していないかのように、古い SPI を「忘れる」ことを望まないのではないかと思います。これはランダムに発生し、エンドポイント A が Fortigate でエンドポイント B が MikroTik の場合のみ発生します。接続を再確立しようとする継続的な積極的な試みにより、古い SPI 値が「保持」されます。

再度発生した場合はこの投稿に追加します。

編集 2013年12月12日

予想通り、また同じことが起こりました。ご存知のとおり、6台のMikroTikクライアントIPsecエンドポイントルーターが設定されています。まったく同じ1 つの Fortigate サーバーに接続しています。最新のインシデントは、私が最初にここに投稿したルーターではなく、ランダムなルーターで発生しました。この重複ルーターをインストールした最後の修正を考慮して、次のショートカットを使用しました。

1. Fortigate からのパケットを受信したくないルータであるルータ A を無効にします。
2. ルータ A の IPsec 構成を、ネットワークの境界に近い一時的なルータにコピーします。
3. 新しく作成した構成をすぐに無効にします。
4. ルータ A を再度有効にします。
5. 自動的に動作を開始します。

@mbrownnyc のコメントを見ると、DPD がオンになっているにもかかわらず、Fortigate が古い SPI を忘れないという問題が発生していると思います。クライアントのファームウェアを調査して投稿します。

これは、前回の図とよく似ていますが、私の「修正」を示す新しい図です。

Answer 1

これはあなたの問題の原因ではないかもしれませんが、他のユーザーにとっては役立つ情報かもしれません。Mikrotik と Sonicwall 間の VPN で、少し似たような問題が発生しました。トラフィックがランダムに停止し、SA をフラッシュする必要がありました。

最終的に、Sonicwall がネットワーク ポリシーごとに個別の SA を作成していることに気付きました (スクリーンショットを見ると、VPN 経由で 2 つのポリシー/サブネットが使用されているようです)。Sonicwall にアクセスできなかったため、この「ポリシーごとの SA」設定がハードコードされているのか、構成可能なのかはわかりません。

当社の Mikrotik は、ポリシーに「require」レベルを使用していました (これはデフォルトで、スクリーンショットに表示されています)。これにより、ルータはリモート ピアとの単一の SA を作成します。そのピアのポリシーのいずれかのトラフィックを送信する場合、src/dest サブネットに関係なく、この同じ SA が使用されます。

これは基本的に、1 つのサブネットのみを使用している限り機能することを意味します。Mikrotik が 2 番目のサブネットにトラフィックを送信しようとすると、既存の SA (Sonicwall に関する限り、特定のサブネット ペア用) を介して送信され、Sonicwall がエラーを発し、SA シーケンス番号が狂い、すべてが停止します。(当社のケースでは、顧客側で「リプレイ」エラーが発生しました)

最終的には、ポリシー レベルを「一意」に変更するだけで済み、両端で一意のサブネット ペアごとに一意の SA が使用されるようになりました。その後、トンネルは完全に正常になりました。

Answer 2

すでに確認済みだと思いますが (私も同様の、しかしまったく異なる断続的な問題があったときに確認しました)、ルータ A が共有している IP アドレスが重複していないことを確認してください。これにより、ハイサイド ルータがルータ A の ARP ルックアップを実行して混乱したときに、断続的な問題が発生します。ルータ上の重複した IP は一貫したエラーになると思われますが、そうではありません。