Cisco と YAMAHA の IPsec が約 1 分で切断｜DPD で解消

はじめに

Cisco C891FJ-K9 と YAMAHA RTX1210 を IKEv1 / IPsec で拠点間接続したところ、Phase 1 / Phase 2 が完了して LAN 側への ping も通るにもかかわらず、約 1 分でトンネルが切断され、1〜2 分後に再接続する動作を繰り返す事象が発生しました。

最初から VPN がつながらない問題とは異なり、暗号設定や認証には問題がないように見えるため、原因の切り分けに迷いやすいケースです。本記事では、この周期断を YAMAHA 側の設定変更 1 つで解消した実機事例を、公式仕様と照らし合わせながら整理します。

結論として、今回の構成ではYAMAHA の死活監視を heartbeat から DPD に変更しただけで、接続してから約 1 分で切断される症状が解消しました。YAMAHA 側の Phase 1 のアルゴリズム明示は、解消を確認した後に行った追加の設定整理です。IPsec が確立して通信できていても、死活監視の方式が対向と合っているかは別に確認する必要があります。

Cisco と YAMAHA の IPsec が約 1 分で切断された環境

本記事の内容は、以下の実機環境で確認した事例です。他の機種や IOS / ファームウェアのバージョンで同じ結果になることを保証するものではありません。

検証環境

Cisco の VTI 構成の基本は『Cisco VTI を使った IPsec VPN の設定例｜IKEv2 と GRE 不要構成』で解説しています。ただし同記事は IOS XE 17.x と IKEv2 を前提としており、本記事の IOS 15.3 / IKEv1 環境とはコマンド体系が異なります。

接続は確立するが約 1 分で切れる症状

実機では次の動作を繰り返していました。時間は現場で観測したおおよその値で、精密に測定したものではありません。

1. IKEv1 の Phase 1 / Phase 2 が完了し、IPsec トンネルが確立する。
2. VPN 経由で LAN 側への ping が通る。
3. 約 1 分でトンネルが切断される。
4. 約 1〜2 分後に再接続する。

当初は、死活監視方式の不整合か rekey の問題を疑っていました。ただし、今回提供された記録では、SA の寿命や rekey の失敗を示すログは確認できていません。

問題発生時の設定

以下は問題の説明に必要な部分だけを抜粋したもので、VPN 構築用のテンプレートではありません。Cisco 側では、IKE Phase 1 の暗号、ハッシュ、DH グループと、死活監視の設定が明示されていました。

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
!
crypto isakmp keepalive 10 6 periodic
!
crypto ipsec transform-set TS-VPN esp-aes 256 esp-sha256-hmac
 mode tunnel

YAMAHA 側では、Phase 2 の条件と、heartbeat 方式によるキープアライブが明示されていました。一方、Phase 1 に関係する ipsec ike encryption、ipsec ike hash、ipsec ike group は設定されていませんでした。

tunnel select 1
 ipsec tunnel 1
  ipsec sa policy 1 1 esp aes256-cbc sha256-hmac
  ipsec ike keepalive log 1 off
  ipsec ike keepalive use 1 on heartbeat 10 6

今回の問題は、YAMAHA のキープアライブ方式として on heartbeat を明示した構成で発生しています。また、Cisco 側に crypto isakmp keepalive が設定されていても、変更前に Cisco が実際に DPD パケットを送信していたかは、この設定行だけでは判断できません。Cisco のコマンドリファレンスでは、対向が対応する方式に応じて使用する方式が決まると説明されています。

参考: Cisco IOS Security Command Reference – crypto isakmp keepalive
“negotiates the use of Cisco IOS keepalives or DPD”
（Cisco IOS keepalive と DPD のどちらを使うかをネゴシエーションする）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-cr-book/sec-cr-c4.html

約 1 分という周期から死活監視を疑った理由

切断までの時間がほぼ一定だったことが、死活監視を疑う手掛かりになりました。ここでは、YAMAHA の heartbeat と DPD の違い、設定値と切断周期の関係、Cisco と YAMAHA でのパラメーターの意味の違いを整理します。

heartbeat と DPD は異なる方式

YAMAHA ルーターの IKEv1 のキープアライブには、heartbeat、ICMP Echo、DPD の 3 方式があります。YAMAHA の技術資料によると、IKE Heartbeat の仕様は Internet-Draft として提案されたものの RFC にはならず、DPD（Dead Peer Detection）は RFC 3706 として公開されています。そのうえで、相互接続の観点では DPD のほうが問題が少ないと説明しています。

参考: ヤマハネットワーク製品 技術資料 – IPsec DPD
「相互接続の観点ではDPDの方が問題が少ないといえます。」
https://www.rtpro.yamaha.co.jp/RT/docs/ipsec/dpd.html

つまり heartbeat は、標準化されなかった仕様に基づく方式です。他社製品と接続する場合は、対向がその方式に対応しているかを確認する必要があります。DPD の仕組みそのものは『IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴』で解説しています。

YAMAHA の 10 秒 × 6 回と約 1 分の切断周期

問題発生時の YAMAHA の設定は ipsec ike keepalive use 1 on heartbeat 10 6 です。公式リファレンスでは、1 つ目の数値はキープアライブパケットの送信間隔（秒）、2 つ目の数値は次のように定義されています。

参考: ヤマハルーター コマンドリファレンス – ipsec ike keepalive use
「キープアライブパケットが届かないときに障害とみなすまでの試行回数」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_keepalive_use.html

送信間隔 10 秒で 6 回試行すると約 60 秒となり、観測した「約 1 分で切断」とほぼ一致します。切断周期が死活監視の判定時間と近い場合は、暗号設定より先に死活監視を疑う価値があります。ただし、今回の記録からはタイマーの起点や内部処理を判断できないため、トンネル確立から正確に 60 秒で切れるという意味ではありません。

Cisco と YAMAHA では同じ「10 6」でも意味が違う

両機器とも設定値は「10 6」ですが、パラメーターの意味は異なります。

Cisco の 2 つ目の数値は回数ではなく秒数です。Cisco のコマンドリファレンスでは、DPD メッセージに応答がない場合は再送間隔で DPD を再送し、5 回の再送に応答がなければトンネルをダウンと判定すると説明されています。そのため、数値を両機器でそろえても、死活監視の判定時間が同じになるわけではありません。相互接続では、数値よりも方式が対向と一致しているかを先に確認します。

heartbeat から DPD への変更と実機での改善結果

YAMAHA の死活監視を DPD に変更したことで、周期的な切断は見られなくなりました。ここでは変更内容と結果、原因についての考察を、確認できた範囲と分けて示します。

変更した設定

YAMAHA 側で、キープアライブの方式を heartbeat から DPD に変更しました。送信間隔と試行回数は変更していません。Cisco 側の設定はそのまま維持しています。

tunnel select 1
 ipsec ike keepalive use 1 on dpd 10 6

変更前後の比較

周期断の解消は、Phase 1 のアルゴリズムを明示する前の DPD 単独変更の段階で確認しています。アルゴリズムの明示は解消に必要だった変更ではなく、後から行った設定整理です。

実機で確認したことと原因についての考察

実機で確認したこと

YAMAHA を heartbeat から DPD に変更すると、接続してから約 1 分で切断され再接続を繰り返す症状が見られなくなりました。その後 Phase 1 の条件を明示しても、引き続き問題なく動作しています。

公式仕様で確認できること

YAMAHA は heartbeat と DPD を別の方式として扱い、相互接続では DPD のほうが問題が少ないと説明しています。Cisco の crypto isakmp keepalive は、対向が対応する方式に応じて Cisco IOS keepalive か DPD を使用します。

設定値と観測結果からの考察

heartbeat による死活監視が Cisco との間で期待どおりに成立せず、YAMAHA 側が設定した試行回数の後に障害と判定し、周期的な切断につながっていた可能性が高いと考えられます。ただし、heartbeat の未受信から切断に至る内部処理は、今回提供された記録からは追跡できません。

今回の記録からは確認できないこと

長時間の連続稼働時間、rekey をまたぐ継続試験、パケットロス率、切断時のパケットキャプチャと詳細ログは、今回提供された記録には含まれていません。

同様の問題が起きた場合の確認・変更手順

以下は、同様の周期断を調べる際に推奨する手順です。DPD への変更による改善は実機で確認していますが、ログ取得や SA のクリアなど、以下の作業をすべて今回の検証で実施した記録はありません。変更を 1 つずつ分けて適用し、効果を確認してから次へ進むことで、何が改善に効いたのかを判断できます。

ipsec ike keepalive log 1 on
syslog debug on

tunnel select 1
ipsec ike keepalive use 1 on dpd 10 6

clear crypto session remote <YAMAHAの対向IPアドレス>

tunnel select 1
ipsec ike encryption 1 aes256-cbc
ipsec ike hash 1 sha256
ipsec ike group 1 modp2048

show crypto isakmp policy
show crypto isakmp sa detail
show crypto ipsec sa

show ipsec sa gateway 1 detail
show log

ipsec ike keepalive log 1 off
syslog debug off

YAMAHA の Phase 1 設定で注意したいこと

今回の設定記録では、YAMAHA 側に Phase 1 の暗号、ハッシュ、DH グループが設定されていませんでした。それでも IKE SA が確立する場合がある理由を、公式仕様から補足します。

省略時の値と Cisco の明示設定

設定ファイル上の値は異なりますが、これは両端が異なる暗号のまま通信していたという意味ではありません。

始動側と応答側で異なる動作と negotiate-strictly

YAMAHA の公式リファレンスでは、ipsec ike encryption などの設定値は、始動側として動作するときに提案する値と説明されています。応答側として動作する場合は、IKEv1 で ipsec ike negotiate-strictly が off であれば、自身の設定と異なっていても、対応しているアルゴリズムやグループであれば受け入れます。negotiate-strictly の初期値は off です。

参考: ヤマハルーター コマンドリファレンス – ipsec ike negotiate-strictly
「相手の提案するパラメータが自分の設定と異なる場合でも、そのパラメータをサポートしていれば、それを受理する。」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_negotiate-strictly.html

そのため、YAMAHA が応答側となる場合は、Cisco の提案した条件で IKE SA が確立しうると考えられます。この補足を読む際は、次の点に注意してください。

• 受け入れの対象は暗号、ハッシュ、グループなどのパラメーターであり、PSK などの認証条件まで無条件に受け入れるわけではない
• アルゴリズムを明示することと、negotiate-strictly で受け入れ条件を厳格化することは別の設定
• 今回の実機で実際に採用された IKE SA の暗号条件は、今回提供された記録からは判断できない
• 今回の周期断の解消は、Phase 1 のアルゴリズムを明示する前に確認している

本記事は IKEv1 の既存構成で確認した事例です。IKEv1 は RFC 9395 で非推奨（Deprecated）とされているため、新規構築や更改の際は IKEv2 への移行を検討することをおすすめします。

まとめ

Cisco C891FJ-K9 と YAMAHA RTX1210 の IKEv1 / IPsec で発生した、接続してから約 1 分で切断される症状は、YAMAHA の死活監視を heartbeat から DPD に変更することで解消しました。IPsec の確立と死活監視の成立は別の問題であり、周期的な切断では暗号設定に加えて死活監視の方式と判定条件を確認することが切り分けの近道になります。

• IPsec が確立して通信できても、死活監視が動作しているかは別に確認する。
• 切断周期が死活監視の判定時間と近ければ、まず死活監視を疑う。
• YAMAHA は相互接続の観点で DPD のほうが問題が少ないと説明している。
• 同じ「10 6」でも、メーカーごとにパラメーターの意味が異なる場合がある。
• 変更を分けて検証することで、効果のあった変更を特定しやすくなる。
• IKEv1 で negotiate-strictly が off なら、YAMAHA は応答側で異なる提案も受け入れる。

以上、最後までお読みいただきありがとうございました。