ブログ_固定IP回線でAWS_VPNを張った話

前回の MAP-E 回線での失敗を踏まえ、今回は固定グローバル IPv4 アドレスの回線を使ってヤマハ RTX1210 と AWS の Site-to-Site VPN 構築に挑戦しました。VPN は張れたものの、設定で3つのつまずきがありました。その原因と解決方法をまとめます。

ito-taiga

2026.11.09

はじめに

前回の記事の続きです。前回は、MAP-E 回線ではヤマハ RTX1210 の IKE に AWS からの応答が返ってこず、トンネルが張れませんでした。

今回は、研修用 PC の通信を AWS 経由でインターネットに出すという目的を実現できるかを確かめるため、固定のグローバル IPv4 アドレスがある回線に切り替えて、同じ構成を試しました。VPN は張れましたが、トンネル内に通信が通るまでに、ルーター側の設定で 3 回つまずきました。

構成

項目	内容
ルーター	ヤマハ RTX1210（Rev.14.01.42）
回線	固定のグローバル IPv4 アドレスがある回線。RTX の WAN ポートに直接アドレスを設定し、IKE も WAN のアドレスで終端
AWS	東京リージョン。AWS Site-to-Site VPN（静的ルーティング、IKEv1）、Transit Gateway、NAT ゲートウェイ

つまずいた 3 点

症状	原因
① IKE が始まらない	`ipsec auto refresh on` がない
② SA は確立するが、トンネル内に通信が通らない	以前の構成向けの NAT の静的変換が残っている
③ RTX からの送信がトンネル 2 にだけ流れる	同じ宛先のデフォルトルートを 2 行で設定し、後の行で上書きしていた

前回の MAP-E 回線では、IKE を送っても AWS から何も返ってきませんでした。今回は①を修正した直後に AWS から応答があり、SA まで確立しました。

① IKE が始まらない

設定を投入して再起動しても、ログに [IKE] のネゴシエーションの行が 1 行も出ませんでした。

RTX は ipsec auto refresh on がないと、自分から IKE を開始しません。AWS 側のトンネルのスタートアップアクションも「追加」（AWS からは IKE を開始しない設定。デフォルト値）だったため、RTX と AWS の双方が相手からの IKE を待ち続ける状態になっていました。なお、スタートアップアクションを「開始」にして AWS 側から IKE ネゴシエーションを開始する機能は、IKEv2 でのみサポートされています。IKEv1 の今回の構成では、ルーター側から開始させる必要があります。

ipsec auto refresh on
save

設定した直後に IKE が始まり、2 本とも SA が確立しました。

# show ipsec sa
Total: isakmp:2 send:2 recv:2

② SA は確立するが、トンネル内に通信が通らない

RTX の show status tunnel ではトンネルが Online なのに、AWS 側のトンネル内側アドレスへの ping 169.254.10.1 が通りませんでした（RTX 側の内側アドレスは ip tunnel address 169.254.10.2/30 で設定済み）。

今回の環境では、以前の構成で使っていた LAN 側アドレス 192.168.118.1 を変換先にした静的 IP マスカレードが残っていました。

nat descriptor masquerade static 1000 1 192.168.118.1 esp
nat descriptor masquerade static 1000 2 192.168.118.1 udp 500
nat descriptor masquerade static 1000 3 192.168.118.1 udp 4500

この 3 エントリを削除して SA を張り直したところ、トンネル内の通信が通るようになりました。

no nat descriptor masquerade static 1000 1
no nat descriptor masquerade static 1000 2
no nat descriptor masquerade static 1000 3
ipsec sa delete all
save

SA を張り直すと、トンネル 1 の送信と受信がどちらも増えるようになりました。

③ RTX からの送信がトンネル 2 にだけ流れる

デフォルトルートをトンネルに向ける前に、AWS の外側 IP アドレス 2 つ宛ての経路を WAN 側に固定しておきます。これがないと、IKE や ESP のパケット自体がトンネルに入ってしまい、VPN が切れます。

ip route <トンネル1の外側IPアドレス> gateway <WAN側ゲートウェイのIPアドレス>
ip route <トンネル2の外側IPアドレス> gateway <WAN側ゲートウェイのIPアドレス>

そのうえでデフォルトルートを VPN に付け替えたところ、トンネル 2 の送信だけが 191 パケットまで増え、受信は 0 でした。AWS からの戻りの経路は AWS 側が 2 本のトンネルから選ぶため、送信と受信で別のトンネルを使うことがあります。

トンネル 1 を主系、トンネル 2 を待機系にするつもりで、次の 2 行を設定していました。

ip route default gateway tunnel 1 metric 1
ip route default gateway tunnel 2 metric 2

ところが show config に残っていたのは、2 行目だけでした。RTX の ip route は宛先 1 つにつき 1 行で、同じ宛先で設定し直すと前の行が置き換わります。

複数のゲートウェイは 1 行で書きます。

ip route default gateway tunnel 1 hide gateway tunnel 2 hide weight 0
save

hide：そのトンネルが Online のときだけ経路として使う
weight 0：トンネル 2 を待機系にする

この設定では、RTX から AWS への送信は、トンネル 1 が使える間はトンネル 1 を優先し、使えなくなるとトンネル 2 を使います。AWS からの戻りの経路は AWS 側が選ぶため、この設定では固定されません。トンネル 2 の送信カウンターがふだん増えないのは想定どおりです。

なお、hide で待機系に切り替わるには、RTX がトンネルの断を検知できる必要があります。今回は ipsec ike keepalive use 1 on dpd 10 3（トンネル 2 も同様）を設定しています。

注意：IKE のログ設定に PSK が出る

no ipsec ike log 1
no ipsec ike log 2
syslog debug off

syslog debug on を設定していた場合は、あわせて syslog debug off で戻します。

まとめ

RTX から IKE を開始させるには ipsec auto refresh on が必要
IKE の終端アドレスと NAT 設定が合っているかを確認する。今回は、以前の構成向けに残っていた静的 IP マスカレードを削除した
デフォルトルートをトンネルに向ける前に、AWS の外側 IP アドレス宛ての経路を WAN 側に固定する
RTX の ip route は宛先 1 つにつき 1 行。主系・待機系の 2 本は 1 行で書く
ipsec ike log ... key-info はログに PSK が出るので、切り分けが終わったら外す

参考

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社コーポレートサイトをぜひご覧ください。
※2026年1月アノテーション㈱から社名変更しました。