MAP-E 回線で AWS Site-to-Site VPN を張ろうとして失敗した話(RTX1210)

ネットワーク研修用の環境で、インターネット出口を「PPPoE」から「MAP-E 回線 + AWS 経由」に変えようとしました。
結論から書くと、RTX1210 の MAP-E 回線では AWS Site-to-Site VPN（IPsec）のトンネルが張れませんでした。 この記事では、構成の考え方、構築内容、失敗したときのログ、そこから分かったことをまとめます。
後半で述べるとおり、原因は MAP-E 回線側の制約が最も疑わしいと考えています。

この記事で分かること

• MAP-E 回線で IPsec VPN が難しいと考えられる理由
• AWS の Site-to-Site VPN から、NAT ゲートウェイ経由でインターネットに出る構成の注意点
• RTX1210 でトンネルが張れないときに、ログのどこを見るか

環境

やりたかったこと

ルーターのデフォルトルートを VPN トンネルに向けて、研修用 PC のインターネット通信を、いったん AWS を経由してから外に出す構成です。

構成を考えるときに引っかかった点

1. VGW では NAT ゲートウェイに通信を流せない

最初は「接続は 1 拠点だけなので、普通の Site-to-Site VPN（仮想プライベートゲートウェイ、VGW）で足りる」と考えていました。
しかし、AWS のドキュメント NAT ゲートウェイの基本 には、次のように書かれています。

仮想プライベートゲートウェイを使用して Site-to-Site VPN または Direct Connect から NAT ゲートウェイへの方向のトラフィックをルーティングすることはできません。仮想プライベートゲートウェイではなく、トランジットゲートウェイを使用する場合は、Site-to-Site VPN または Direct Connect から NAT ゲートウェイにトラフィックをルーティングできます。

つまり、オンプレから VPN 経由で NAT ゲートウェイを使うには、VGW ではなく Transit Gateway（TGW）が必要です。接続が 1 拠点だけでも変わりません。

2. 「NAT はルーターでやるから、AWS 側は不要」とはいかない

ルーター側で NAT しても、AWS 側から戻ってくる通信が届かなければ意味がありません。インターネットゲートウェイ（IGW）が変換できるのは、パブリック IP を割り当てた ENI 自身のプライベート IP だけです。そのため、AWS 側にも NAT の役割が要ります。

3. VGW のゲートウェイルートテーブルでは回避できない

VGW に関連付けるゲートウェイルートテーブルで、0.0.0.0/0 を EC2（NAT インスタンス）に向ける方法は使えません。AWS の Gateway route tables に、VPC の CIDR 外へのルートは追加できないと書かれています。

この結果、構成は次のようになりました。

構築したもの（概要）

AWS 側はマネジメントコンソールで、次の順に作りました。

1. VPC（10.100.0.0/16）、パブリックサブネットと TGW アタッチメント用サブネット
2. IGW、Elastic IP、NAT ゲートウェイ
3. ルートテーブル（TGW 用サブネットの 0.0.0.0/0 を NAT ゲートウェイへ、パブリックサブネットに 192.168.0.0/16 → TGW を追加）
4. Transit Gateway と VPC アタッチメント
5. カスタマーゲートウェイ（MAP-E の IPv4 アドレスで登録）
6. Site-to-Site VPN 接続（静的ルーティング、トンネル 2 本、スタートアップアクションは「追加」で RTX から開始）
7. TGW ルートテーブルに、0.0.0.0/0 と戻りの 192.168.0.0/16 を静的ルートで追加

RTX 側は、MAP-E 用のトンネル（tunnel 1）とは別に、VPN 用に tunnel 2 と tunnel 3 を作りました。AWS の外側 IP 宛ての /32 ルートは、MAP-E のトンネル（tunnel 1）に向けました。

失敗:トンネルが上がらない

デフォルトルートを tunnel 1（MAP-E）に向けた状態では、ルーターも PC もインターネットに出られました。
一方、VPN のトンネル（tunnel 2、3）は、まったく上がりませんでした。ルーター側のトンネルの状態は、一度もつながらないまま Offline でした。

ルートの確認

show ip route では、AWS の外側 IP への /32 が tunnel 1 を向いていました。

default             -        TUNNEL[1]    static
x.x.x.x/32          -        TUNNEL[1]    static   ← AWS 側トンネル 1 の外側 IP(RTX の tunnel 2 に対応)
y.y.y.y/32          -        TUNNEL[1]    static   ← AWS 側トンネル 2 の外側 IP(RTX の tunnel 3 に対応)
169.254.10.0/30     -        TUNNEL[2]    implicit
169.254.10.4/30     -        TUNNEL[3]    implicit

（IP アドレスは伏せています。）ルーティングは想定どおりに設定されていました。

ログの確認

IKE のログを見ると、次のことが分かりました。

• RTX は IKEv1 のメインモードの最初のメッセージを、AWS の外側 IP 2 つに送っている。
• 送信元アドレスは、[MAP-E] tunnel 1 up v4=<MAP-E の IPv4> で表示されたアドレスと一致している。
• その後、10 回再送し（count = 9 から count = 0 まで）、約 2 分 45 秒で retransmission timeout。そのまま張り直しを始め、同じ流れを 6 回繰り返している。
• 約 960 行のログのなかに、AWS からの受信を示す行は 1 つもない。

以下は、show log の 1 回分（約 2 分 45 秒）を抜き出したものです。実際のログには、各送信の間に 16 進数のダンプ行が 8 行ずつ入るため、ダンプ行、2 本目のトンネルの行、send IKE message の重複行を省略しています。AWS の外側 IP と MAP-E の IPv4 は伏せ字です。

17:03:54: [IKE] initiate ISAKMP phase to x.x.x.x (local address <MAP-E の IPv4>)
17:03:55: [IKE] main mode initiator 0
17:03:55: [IKE] send IKE message to x.x.x.x
17:04:00: [IKE] [1] retransmit to x.x.x.x (count = 9)
17:04:07: [IKE] [1] retransmit to x.x.x.x (count = 8)
17:04:16: [IKE] [1] retransmit to x.x.x.x (count = 7)
17:04:27: [IKE] [1] retransmit to x.x.x.x (count = 6)
17:04:40: [IKE] [1] retransmit to x.x.x.x (count = 5)
17:04:55: [IKE] [1] retransmit to x.x.x.x (count = 4)
17:05:12: [IKE] [1] retransmit to x.x.x.x (count = 3)
17:05:31: [IKE] [1] retransmit to x.x.x.x (count = 2)
17:05:52: [IKE] [1] retransmit to x.x.x.x (count = 1)
17:06:15: [IKE] [1] retransmit to x.x.x.x (count = 0)
17:06:40: [IKE] [1] retransmission timeout
17:06:40: [IKE] initiate ISAKMP phase to x.x.x.x (local address <MAP-E の IPv4>)

最後の行の initiate は、タイムアウトのあとに、また最初からやり直しているところです。この流れを 6 回繰り返し、2 本目のトンネルも同じ結果でした。

実際のログの一部です。2 本のトンネルが交互に再送しています。16 進数の行は、再送している IKE メッセージの中身です。

つまり、RTX は IKE を送っているのに、AWS から何も返ってこない状態でした。暗号方式の不一致や PSK の間違いなら、そこまでのやり取りで AWS から何らかの応答が返ってくることが多いと考えられます。受信が 1 回もないことから、通信自体が往復できていない可能性が高いと考えられます。

原因の考察:MAP-E 回線側の制約

MAP-E で使えるポート

MAP-E は、1 つのグローバル IPv4 アドレスを複数の契約者で共有します。そのため、契約者ごとに使えるポートが限られます。
[MAP-E] tunnel 1 up のログから、今回の回線で割り当てられたポートは、4608-4623 から始まり、4096 ごとに 16 ポートずつのブロックが並ぶ形でした。IPsec に使う UDP 500 も 4500 も、この範囲に含まれません。

通常の NAT との違い

NAT の配下にあるルーターでも IKE の送信元ポートは変換されますが、AWS との VPN は NAT トラバーサル（NAT-T）で張れます。今回も RTX で ipsec ike nat-traversal を有効にしていました。そのため、「送信元ポートが 500 でないから AWS が拒否した」とは言い切れません。

MAP-E では、ルーター自身が送る IKE も、割り当て範囲内のポートに変換されてから送られます。この変換や、MAP-E の中継装置（BR）での扱いのどこかで、パケットが AWS まで届いていなかった可能性があると考えています。

学び

1. MAP-E 回線の IPsec VPN は制約が多い。 今回の環境では張れなかった。VPN を使う予定があるなら、回線を決める前に対応状況を確認しておく。
2. オンプレから VPN 経由で NAT ゲートウェイを使うには、VGW ではなく Transit Gateway が必要。 1 拠点でも同じ。
3. IKE のログで、AWS からの受信行があるかを最初に見る。 受信がなければ、暗号方式や PSK より前に、通信が往復できているかを疑う。
4. AWS 側の VPN のトンネルログ（CloudWatch Logs）は、最初から有効にしておく。 IKE が AWS に届いているかを AWS 側から確認でき、原因をもっと絞り込めた可能性がある。
5. この構成は、使っている間ずっと課金される。 失敗が分かったら、VPN 接続、TGW のアタッチメント、NAT ゲートウェイ、EIP を早めに削除する。

後片付け

AWS のリソースは、依存関係の順に削除しました。

1. VPN 接続 → カスタマーゲートウェイ
2. TGW のアタッチメント（Deleted になるまで待つ）→ Transit Gateway
3. NAT ゲートウェイ（Deleted になるまで待つ）→ Elastic IP の解放
4. IGW のデタッチと削除 → ルートテーブル、サブネット、VPC

ダウンロードした VPN の設定ファイルと PSK も、手元から削除しました。

次にやること

MAP-E 回線での原因の深掘りよりも、「研修用 PC の通信を AWS 経由でインターネットに出す」という目的を実現できるかの検証を優先することにしました。研修環境では固定のグローバル IPv4 アドレスがある回線も使えるため、そちらに切り替えて同じ構成を試します。ポート制限のない回線で VPN が張れれば、今回の原因がルーターの設定ではなく MAP-E 回線側にあったことの裏付けになります。結果は、別の記事にまとめます。

参考

• NAT ゲートウェイの基本（AWS ドキュメント）
• インターネットゲートウェイを使用して VPC のインターネットアクセスを有効にする（AWS ドキュメント）
• Gateway route tables（AWS ドキュメント）
• How do I access the internet using Site-to-Site VPN in my on-premises network?（AWS re:Post）

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

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