自宅からAWS上の strongSwan と張っていたIPsec VPNを、Cisco C891FJからFortiGateに移し替えました。
今回の構成 移行前はCisco C891FJがIPsec VPNを終端していました。
crypto ikev2 proposal IKEV2-PROP
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes esp-sha256-hmac
mode tunnel
!
crypto map IPSEC-MAP 10 ipsec-isakmp
set peer 203.0.113.43
set transform-set ESP-AES256-SHA
set ikev2-profile IKEV2-PROFILE
match address IPSEC-ACL
!
ip access-list extended IPSEC-ACL
permit ip 10.102.103.0 0.0.0.31 10.0.0.0 0.0.255.255
permit ip 10.102.103.0 0.0.0.31 172.16.255.0 0.0.0.3
permit ip 10.102.103.0 0.0.0.31 192.168.250.0 0.0.0.255
!
interface GigabitEthernet8
crypto map IPSEC-MAP上記のアクセスリスト（IPSEC-ACL）の 0.0.0.31 が今回の記事の主役です。 頭の片隅に置いておいてください。
前提知識：IPsec は何をしているのか 切り分けの話に入る前に、IPsecの構造を整理します。ここが分かっていないと、後半のログが読めません。
なぜ 2 段階に分かれているのか IPsec のトンネル確立は 2 段階に分かれています。
理由 1：鍵交換そのものを暗号化したいから 通信を暗号化するには、両者が同じ鍵を持つ必要があります。
理由 2：役割が根本的に違う 第 1 段階（IKE SA） 第 2 段階（Child SA） 目的 交渉するための安全な通話路を作る 実データを運ぶトンネルを作る 運ぶもの 制御メッセージのみ ユーザの通信 寿命 長い 短い 本数 1 本 複数持てる
電話で例えると、第 1 段階が「電話をかけて相手を確認し、暗号で話す取り決めをする」、
理由 3：鍵を定期的に作り直すため 暗号鍵は長く使うほど解読リスクが上がるので、定期的に作り直す必要があります。
理由 4：1 本の通話路で複数のトンネルを張れる 今回、FortiGate 側には Phase2 が 3 本定義されていました。
P2-AWS-10.0 : 10.102.103.0/24 ⇔ 10.0.0.0/16
P2-AWS-10.70.200 : 10.70.200.0/24 ⇔ 10.0.0.0/16
P2-AWS-10.83.86 : 10.83.86.0/24 ⇔ 10.0.0.0/16これらは全部 set phase1name "VPN-AWS" を参照しています。
UDP 500 と 4500 は何をしているのか sniffer のログを読むために必要な知識です。
UDP 500 は交渉用の窓口 IKE（鍵交換や認証の会話）は UDP 500 番ポートを使うと決められています。
実データはポートを持たない ここが混乱の元です。交渉が終わった後、実際の暗号化データは ESP（プロトコル番号 50） で運ばれます。
NAT があると ESP が通れない NAT は複数の端末を 1 つのグローバル IP に集約する仕組みです。
192.168.1.10:12345 → 203.0.113.1:50001
192.168.1.11:12345 → 203.0.113.1:50002ところが ESP にはポートがありません。
そこで UDP 4500 でくるむ この問題を回避するのが NAT-T（NAT Traversal） です。
[IP][UDP 4500] [ESP][暗号化データ]UDP になったのでポート番号を持ち、NAT を問題なく通過できます。
ポート / プロトコル 用途 NAT 配下 UDP 500 IKE（交渉） 常に使う ESP（プロトコル 50） 実データ 通れない UDP 4500 IKE + ESP のカプセル化 これを使う
今回の FortiGate は WAN 側が 100.64.XX.XX、つまり CGNAT（キャリアグレード NAT）配下でした。当然 NAT-T が使われます。
トラフィックセレクタとは何か 今回の原因そのものです。
装置 設定方法 Cisco crypto ACL（match address で crypto map に紐付け） FortiGate Phase2 の src-subnet / dst-subnet strongSwan leftsubnet / rightsubnet
そして重要なのが、この基準は両端で一致していなければならない という点です。
では TS は必ず絞る必要があるのか。 答えは「TS の交換は必須だが、範囲を絞る必要はない」です。0.0.0.0/0 ⇔ 0.0.0.0/0 と提案すれば「全部 OK」という合意になります。これがルートベース VPN の考え方で、暗号化範囲を広く取っておいて、実際に何を通すかはルーティングテーブルとファイアウォールポリシーで制御します。
移行手順：891F から IPsec を切り離す FortiGate 側の設定投入が終わったら、891F 側を止めます。
Host#conf t
Host(config)#interface GigabitEthernet8
Host(config-if)# no crypto map IPSEC-MAP
end
Host#clear crypto session
Host##clear crypto ikev2 sa古い SA が残っていると対向側の Phase1 が通らないことがあるので、明示的にクリアしておきます。
Host#show crypto session
Host#show crypto ikev2 sa
Host#show crypto ipsec sa | include peer|pkts3 つとも出力が空なら、891F は対向と一切ネゴシエートしない状態です。crypto map の定義自体は show crypto map に残って見えますが、末尾の Interfaces using crypto map IPSEC-MAP: の下が空欄であれば、どのインターフェイスにも適用されていません。
Host#conf t
Host(config)#interface GigabitEthernet8
Host(config-if)# crypto map IPSEC-MAP
endこの状態での注意点 crypto map を外すと、891F は対向宛のパケットを暗号化せずにデフォルトルートへ転送します。新しい終端装置がまだ上がっていない状態で該当セグメントの通信が発生すると、その分は平文でインターネット側に出ます。
トンネルが上がらない — 切り分けの流れ FortiGate 側に切り替えたところ、トンネルが上がりませんでした。ここからが本題です。
段階 1：状態を確認する FortiGate # diagnose vpn ike gateway list
FortiGate # get vpn ipsec tunnel summary
'VPN-AWS' 203.0.113.43:0 selectors(total,up): 3/0 rx(pkt,err): 0/0 tx(pkt,err): 0/0diagnose vpn ike gateway list が完全に空です。一方 get vpn ipsec tunnel summary には表示されている。
コマンド 見えるもの diagnose vpn ike gateway list Phase1 の SA（生きている接続） diagnose vpn tunnel list Phase2 の SA、セレクタごとの状態、鍵、パケット数 get vpn ipsec tunnel summary 設定ベースの一覧と up 数
gateway list は「gateway」という名前が紛らわしいのですが、設定として定義したゲートウェイの一覧ではありません。実際に確立している、あるいは確立処理中のセッションを表示します。
段階 2：設定の妥当性を見る FortiGate # show vpn ipsec phase1-interface
config vpn ipsec phase1-interface
edit "VPN-AWS"
set interface "wan1"
set ike-version 2
set peertype any
set proposal aes256-sha256
set localid-type address
set dpd on-idle
set npu-offload disable
set dhgrp 14
set remote-gw 203.0.113.43
set psksecret ENC <REDACTED>
set dpd-retryinterval 30
next
endinterface は wan1、remote-gw も正しい、proposal（aes256-sha256）と dhgrp（14）も 891F 側と一致しています。設定不備ではなさそうです。
FortiGate # show vpn ipsec phase2-interface
config vpn ipsec phase2-interface
edit "P2-AWS-10.0"
set phase1name "VPN-AWS"
set proposal aes256-sha256
set pfs disable
set auto-negotiate enable
set keylifeseconds 3600
set src-subnet 10.102.103.0 255.255.255.0
set dst-subnet 10.0.0.0 255.255.0.0
next
...
endauto-negotiate enable が入っているので、トラフィックがなくても FortiGate 側から自動でネゴシエーションを開始するはずです。それでも gateway list が空、というのが不可解でした。
段階 3：土台を疑う 設定が正しいなら、その下のレイヤを確認します。
FortiGate # get system interface physical | grep -A5 wan1
==[wan1]
mode: dhcp
ip: 100.64.XX.XX 255.255.252.0
status: up
speed: 1000Mbps (Duplex: full)wan1 は up で IP も取得済み。次に経路です。
FortiGate # get router info routing-table all
S* 0.0.0.0/0 [5/0] via 100.64.XX.XX, wan1
C 10.70.200.0/24 is directly connected, vlan.0720
S 10.102.103.0/27 [10/0] via 10.12.13.253, vlan.3121
C 10.102.103.224/27 is directly connected, vlan.3121
S 10.83.86.0/24 [10/0] via 10.12.13.253, vlan.3121
C 100.64.0.0/22 is directly connected, wan1
...デフォルトルートも入っています。対向への経路は問題ありません。
段階 4：パケットレベルで確認する FortiGate # diagnose sniffer packet any 'host 203.0.113.43' 4 0 aこれが決定打でした。
05:11:26.529161 wan1 out 100.64.XX.XX.500 -> 203.0.113.43.500: udp 432
05:11:26.535597 wan1 in 203.0.113.43.500 -> 100.64.XX.XX.500: udp 473
05:11:26.536662 wan1 out 100.64.XX.XX.4500 -> 203.0.113.43.4500: udp 244
05:11:26.543038 wan1 in 203.0.113.43.4500 -> 100.64.XX.XX.4500: udp 132
05:11:27.269514 wan1 out 100.64.XX.XX.500 -> 203.0.113.43.500: udp 432
05:11:27.276204 wan1 in 203.0.113.43.500 -> 100.64.XX.XX.500: udp 473
（以降 0.7 秒周期で繰り返し）前提知識のパートを読んだ後なら、この 4 行から多くのことが読み取れます。UDP 500 で往復している → 第 1 段階（IKE_SA_INIT）は成立しています。暗号方式や DH グループが合わないなら、ここで応答は返りません。UDP 4500 に切り替わっている → NAT-T が検出され、以降の通信が 4500 番に移動しました。CGNAT 配下なので当然の動作です。4500 での応答が 132 バイトと短い → 正常な IKE_AUTH 応答なら、認証情報やトラフィックセレクタを含むのでもっと大きくなります。この短さは、エラー通知が返っていることを示しています。0.7 秒周期で最初から繰り返している → SA が確立せず即座に破棄され、再試行のループに入っています。gateway list が空だった理由もこれで説明がつきます。コマンドを打った瞬間に SA が存在しない確率が高かったわけです。第 1 段階は通っていて、第 2 段階の交渉で拒否されている ところまで絞れました。
段階 5：拒否理由を特定する あとは対向が何を理由に拒否しているかを見るだけです。
diagnose debug reset
diagnose vpn ike log-filter dst-addr4 203.0.113.43
diagnose debug application ike -1
diagnose debug enableデバッグを停止するときは diagnose debug disable と diagnose debug reset です。
ike 0:VPN-AWS:45486: initiator received SA_INIT response
ike 0:VPN-AWS:45486: NAT detected: ME PEER
ike 0:VPN-AWS:45486: matched proposal id 1
ike 0:VPN-AWS:45486: type=ENCR, val=AES_CBC (key_len = 256)
ike 0:VPN-AWS:45486: type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 0:VPN-AWS:45486: type=DH_GROUP, val=MODP2048.
ike 0:VPN-AWS:45486: NAT-T float port 4500
ike 0:VPN-AWS:45486: sent IKE msg (AUTH): 100.64.XX.XX:4500->203.0.113.43:4500
ike 0:VPN-AWS:45486: initiator received AUTH msg
ike 0:VPN-AWS:45486: peer identifier IPV4_ADDR 203.0.113.43
ike 0:VPN-AWS:45486: auth verify done
ike 0:VPN-AWS:45486: authentication succeeded
ike 0:VPN-AWS:45486: received notify type TS_UNACCEPTABLE
ike 0:VPN-AWS:45486: schedule delete of IKE SA
ike 0:VPN-AWS: connection expiring due to phase1 down
ike 0:VPN-AWS: schedule auto-negotiate決定的な 2 行が並んでいます。
authentication succeeded
received notify type TS_UNACCEPTABLE認証は成功している。 事前共有鍵もローカル ID も問題なし。落ちているのはトラフィックセレクタです。
原因の特定：トラフィックセレクタの範囲不一致 TS が原因と分かったので、実際に何を提案していたのかを見ます。デバッグログには送信した AUTH メッセージの中身が 16 進数で出ています。
...2D00001801000000070000100000FFFF0A6667000A6667FF0000001801000000070000100000FFFF0A0000000A00FFFF...TS ペイロードのデコード 16 進数なので 2 文字で 1 バイトです。IKEv2 の TS ペイロードは以下の構造をしています。
ペイロードヘッダ 値 意味 2D ペイロードタイプ 45 = TSi (イニシエータ側のセレクタ) 00 フラグ 0018 ペイロード長 = 24バイト 01 含まれるセレクタの数 = 1 000000 予約領域
セレクタ本体 バイト 値 意味 1 07 TSタイプ = IPv4アドレス範囲 2 00 プロトコルID = 全プロトコル 3-4 0010 セレクタ長 = 16バイト 5-6 0000 開始ポート = 0 7-8 FFFF 終了ポート = 65535 (全ポート) 9-12 0A666700 開始アドレス 13-16 0A6667FF 終了アドレス
アドレス部分を 10 進数に直します。
0A = 10
66 = 102
67 = 103
00 = 0 → 10.102.103.0
0A = 10
66 = 102
67 = 103
FF = 255 → 10.102.103.255FortiGate は「10.102.103.0 から 10.102.103.255 まで」と提案していました。
0A000000 → 10.0.0.0
0A00FFFF → 10.0.255.255こちらは dst-subnet 10.0.0.0 255.255.0.0（/16）に対応していて、対向と一致していたので問題ありませんでした。なぜその値になったのか
set src-subnet 10.102.103.0 255.255.255.0 ← /24/24 は 10.102.103.0 〜 10.102.103.255 の 256 個。だから終了アドレスが 0A6667FF（10.102.103.255）になりました。
FortiGate が提案: 10.102.103.0 - 10.102.103.255 ← /24
strongSwan の期待: 10.102.103.0 - 10.102.103.31 ← /27範囲が広すぎるので、strongSwan は「その提案は受け入れられない」と TS_UNACCEPTABLE を返していました。
原因は Cisco のワイルドカードマスクの読み違え 891F の ACL に戻ります。
permit ip 10.102.103.0 0.0.0.31 10.0.0.0 0.0.255.2550.0.0.31 は Cisco のワイルドカードマスクです。ビットを反転させると 255.255.255.224、つまり /27。
ワイルドカードマスク プレフィックス サブネットマスク 0.0.0.3 /30 255.255.255.252 0.0.0.7 /29 255.255.255.248 0.0.0.15 /28 255.255.255.240 0.0.0.31 /27 255.255.255.224 0.0.0.63 /26 255.255.255.192 0.0.0.127 /25 255.255.255.128 0.0.0.255 /24 255.255.255.0 0.0.255.255 /16 255.255.0.0
修正と確認 Phase2 の src-subnet を /27 に直します。
config vpn ipsec phase2-interface
edit "P2-AWS-10.0"
set src-subnet 10.102.103.0 255.255.255.224
next
end再ネゴシエーションを促します。
diagnose vpn ike gateway flush name VPN-AWS
diagnose vpn tunnel up P2-AWS-10.0 VPN-AWSFortiGate # get vpn ipsec tunnel summary
'VPN-AWS' 203.0.113.43:4500 selectors(total,up): 1/1 rx(pkt,err): 0/0 tx(pkt,err): 0/0selectors 1/1。上がりました。
FortiGate # diagnose vpn ike gateway list
vd: root/0
name: VPN-AWS
version: 2
interface: wan1 5
addr: 100.64.XX.XX:4500 -> 203.0.113.43:4500
created: 71s ago
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 1/29 established 1/1 time 10/10/10 ms
direction: initiator
status: established 71-71s ago = 10ms
proposal: aes256-sha256
lifetime/rekey: 86400/86028
DPD sent/recv: 00000002/00000002established になり、lifetime/rekey で SA の有効期限と次回鍵更新までの秒数が見えます。DPD sent/recv が往復しているので死活監視も正常です。
FortiGate # diagnose vpn tunnel list name VPN-AWS
name=VPN-AWS ver=2 serial=1 100.64.XX.XX:4500->203.0.113.43:4500
proxyid_num=1 child_num=0 refcnt=16
dpd: mode=on-idle on=1 idle=30000ms retry=3 count=0 seqno=14
natt: mode=keepalive draft=0 interval=10 remote_port=4500
proxyid=P2-AWS-10.0 proto=0 sa=1 ref=2 serial=5 auto-negotiate
src: 0:10.102.103.0/255.255.255.224:0
dst: 0:10.0.0.0/255.255.0.0:0
SA: ref=3 options=802f type=00 soft=0 mtu=1422 expire=3560/0B
life: type=01 bytes=0/0 timeout=3576/3600src が 255.255.255.224 になり、891F の IPSEC-ACL と一致しました。natt: mode=keepalive interval=10 で NAT テーブル維持のための keepalive も動いています。
execute ping-options source 10.102.103.254
execute ping <対向のIP>
diagnose vpn tunnel list name VPN-AWSdec:pkts/bytes と enc:pkts/bytes の両方が増えていれば完了です。enc だけ増えて dec が 0 の場合は、対向側のルートテーブルやセキュリティグループで戻りが落ちています。
891F 側の設定を完全に削除する 新終端が安定稼働していることを数日確認できたら、891F の設定本体を消します。投入順序が重要です。
conf t
no crypto map IPSEC-MAP 10
no crypto ipsec transform-set ESP-AES256-SHA
no crypto ikev2 profile IKEV2-PROFILE
no crypto ikev2 keyring IKEV2-KEY
no crypto ikev2 policy IKEV2-POL
no crypto ikev2 proposal IKEV2-PROP
no crypto isakmp nat keepalive 30
end
write memoryprofile が keyring を参照しているので、profile → keyring の順です。逆にすると使用中エラーで弾かれます。
no route-map RM-NAT deny 10
no ip access-list extended NAT0-IPSEC
no ip access-list extended IPSEC-ACLroute-map の deny 句を先に消してから ACL を消します。逆順にすると route-map が空マッチになり、NAT の挙動が変わって通信が壊れます。
まとめ 症状 FortiGate から対向へ IPsec が上がらない。diagnose vpn ike gateway list が空。
原因 Phase2 の src-subnet が /24。対向は /27 で待っていたため、TS の範囲が一致せず TS_UNACCEPTABLE で拒否されていた。Cisco のワイルドカードマスク 0.0.0.31 を /24 と読み違えたことが発端。
切り分けの流れ 1. diagnose vpn ike gateway list が空 → Phase1 の SA が生成されていない
教訓
IPsec が 2 段階に分かれている構造を理解していると、sniffer の出力だけで原因を半分に絞り込める
UDP 500 で往復していれば暗号方式と経路は正常、それ以降で落ちるなら認証か TS
Cisco から他ベンダへ移行する際は、ワイルドカードマスクの変換を必ず検算する
対向がマネージド VPN か自前の strongSwan かで、TS の厳密さが変わる
1 ビットの差でトンネルが上がらない、という結果だけ見れば単純なミスです。ただ、そこに至る過程で IKEv2 のメッセージ構造や NAT-T の動作を実際のパケットで確認できたのは、設定を眺めているだけでは得られない理解でした。
コメントを残す