IPsecとNAT/NAPTが共存できない理由
IPsecは暗号化と認証によって通信の安全性を確保する仕組みですが、NATやNAPTとは基本的に相性が良くありません。これは、NAT/NAPTがパケットのIPアドレスやポート番号を書き換える処理を行うためであり、IPsecの仕様と衝突してしまうからです。ここでは、AH、ESP、IKEそれぞれの観点で問題点を整理します。
AHにおける問題
AH（Authentication Header）は、IPヘッダそのものを認証範囲に含めます。そのためNATやNAPTによって送信元や宛先のIPアドレスが書き換えられると、受信側は改ざんされたパケットだと判断し認証に失敗します。このためNAT環境ではAHは利用が難しいと考えるのが一般的です。
ESPにおける問題
ESP（Encapsulating Security Payload）は認証範囲にIPヘッダを含めないため、AHのようにアドレス書き換えで認証エラーが起きることはありません。しかしESPは暗号化の対象にTCP/UDPヘッダを含むため、NAPTが必要とするポート番号を書き換えることができません。NAPT機能はポート番号を基準にセッションを識別しますが、暗号化によってポート番号を読み取れなくなり、通信処理ができなくなります。
IKEにおける問題
IKE（Internet Key Exchange）は、IPsecでの鍵交換を担うプロトコルです。IKEでやり取りされるISAKMPメッセージは、RFC2408で定められているとおりUDPの500番ポートを固定で利用します。NAPT環境では通常ポート番号を変換して通信を成立させますが、IKEはポート番号が固定のため変換できず、結果として通信が成立しません。
NAT/NAPT環境で発生する典型的な問題
- AH利用時は、送信元IPが書き換えられたと認識され、認証エラーが発生する
- ESP利用時は、暗号化によりポート番号を読み取れず、NAPTで処理できない
- IKE利用時は、固定ポートUDP500のためポート変換が行えない
解決策としてのNAT Traversal（NAT-T）
この問題を解消するために考案されたのがNAT Traversal（NAT-T）です。NAT-TではESPパケットをUDPでカプセル化し、通常のUDP通信としてNAT/NAPTを通過させます。またIKEについてもUDP4500を利用することでNAPTによるポート変換が可能になり、通信が成立します。
IPsec – NAT Traversalとは
NAT Traversal（NAT-T）は、NATやNAPTが存在するネットワーク環境でIPsecを問題なく利用できるようにするための拡張技術です。仕組みとしては、ESPパケットをUDPでカプセル化することで、NAPT機器がポート番号を書き換え可能にします。UDPヘッダは暗号化されないため、NAPT装置がポート変換処理を行えるのです。
UDPカプセル化の判断は誰が行うのか
この判定と切り替えはIKEが自動で行います。IKEのやり取りの中で、NAT/NAPT機器の存在を検出し、必要に応じてUDPカプセル化に切り替えるようネゴシエーションします。流れは以下の通りです。
- IKEフェーズ1で、相手がNAT Traversalをサポートしているか確認し、ネットワーク経路上にNAPT装置が存在するかを検出。必要に応じてISAKMP通信ポートをUDP500から4500に切り替える。
- IKEフェーズ2で、ESPをUDPでカプセル化するモードを決定。NAPTによるIPアドレス変換前の情報を交換することもある。
- VPN確立後、ESPパケットはUDPカプセル化されて送信される。
IKEフェーズ1での拡張機能
IKEフェーズ1のISAKMPメッセージには、NAT Traversalを利用するための拡張要素が含まれます。
- Vendor ID（タイプ13）
第1、第2メッセージで「自分はNAT Traversalをサポートしている」という情報を交換します。 - NAT-D（タイプ20）
Mainモードでは第3、第4メッセージ、Aggressiveモードでは第2、第3メッセージで送信し、経路上にNAT装置があるかどうかを検出します。 - ポート番号の切り替え
NATが検出されると、Mainモードは第5、第6メッセージ以降、Aggressiveモードは第3メッセージ以降、ISAKMP通信のポート番号を500から4500に変更します。この際、UDPヘッダとISAKMPヘッダの間にNon-ESP Marker（4バイトの0）が挿入され、メッセージフォーマットが変化します。
ポイントとして、NAT環境下では送信元ポートが500以外に書き換わる可能性があるため、ルータ側ACLでUDP500や4500以外のISAKMPパケットも受信できるよう考慮しておく必要があります。
IKEフェーズ2での拡張機能
IKEフェーズ2（Quickモード）では、ESPパケットをどのようにUDPでカプセル化するかを決定します。
- Transform（タイプ3）
UDPカプセル化トンネルモードか、UDPカプセル化トランスポートモードかを伝える。 - NAT-OA（タイプ21）
トランスポートモード利用時、NAPTで書き換えられる前のオリジナルIPアドレスを相手に伝達することで、チェックサムエラーを防ぐ。
この拡張によって、NAT環境でもIPsec-VPNが安定して動作可能になります。
動的グローバルIPアドレスを使った拠点とのIPsec-VPN接続
通常、企業が拠点間VPNを構築する場合は固定のグローバルIPアドレスを取得し、それを互いのVPNピア（接続相手）として指定して接続を行います。しかし、小規模拠点や営業所のように固定IPを契約しないケースでは、動的に割り当てられるグローバルIPを利用することもあります。この場合でも、工夫をすれば本社と拠点間でIPsec-VPNを実現することができます。
動的IPを利用する場合の接続開始の仕組み
IKE（鍵交換）を始めるには、まず相手のIPアドレスを知っている必要があります。そのため、動的IPを利用する側が必ず接続の開始者（イニシエータ）となり、固定IPを持つ側は応答者（レスポンダ）として動作します。つまり「拠点から本社へVPNを張りにいく」形で接続が確立されます。
認証方式の選択
IKE Phase 1では、MainモードとAggressiveモードがあります。
- Mainモード + Pre-Shared Key では、相手のIPアドレスを使って認証を行います。しかし動的IP環境では、相手のIPを事前に特定できないため使えません。
- Aggressiveモード + Pre-Shared Key では、FQDN（ドメイン名）やユーザー名といった識別子をIDとして使うことができます。これにより、動的IPでも認証が可能となります。
このため、動的グローバルIP環境ではAggressiveモードを利用するのが基本です。なお、デジタル署名方式を使えばMainモードも利用可能ですが、一般的な小規模拠点ではほとんど使われません。
本社側の設定の考え方
本社ルータ（固定IP側）は、拠点ルータを識別するためにFQDNを使います。設定のポイントは、対向拠点のIDを明示的に指定することです。
- 対向拠点のID:
office1.infraexpert.com（FQDN） - 認証方式: Pre-Shared Key
- 認証パスワード:
cisco - フェーズ1交換モード: Aggressiveモード
- ISAKMP SAパラメータ: 3DES、SHA-1、DHグループ2、ライフタイムはデフォルト
- IPsec SAパラメータ: ESP、3DES、HMAC-SHA1、PFSなし、トンネルモード、ライフタイムはデフォルト
拠点側の設定の考え方
拠点ルータ（動的IP側）は、自身を本社に識別してもらう必要があるため、Aggressiveモードの第一メッセージにIdentificationペイロードを含めます。これにより、固定IP側は拠点をFQDNで認識します。
- Identificationペイロード:
- IDタイプ: FQDN
- 値:
office1.infraexpert.com
- 対向ピアのIP:
200.1.1.1（本社の固定IP） - 認証方式: Pre-Shared Key
- 認証パスワード:
cisco - フェーズ1交換モード: Aggressiveモード
- ISAKMP SAパラメータ: 3DES、SHA-1、DHグループ2、ライフタイムはデフォルト
- IPsec SAパラメータ: ESP、3DES、HMAC-SHA1、PFSなし、トンネルモード、ライフタイムはデフォルト