Windows端末でEC2インスタンス上のL2TP/IPSecサーバとVPN接続する時のこと

こんにちは技術2課の紅林です。静岡出身のため、年始には毎年法多山にお参りに行って、名物のお団子を食べてくるのが恒例です。

さて、今回は、Windows端末からEC2インスタンス上に構築したL2TP/IPSecサーバにVPN接続する検証をしていた際に調べた注意事項等にご紹介します。

はじめに

複数のクライアント端末からAWS環境とVPN接続する環境の構築について、本ブログでも、Windows ServerやSoftEther VPNを用いたVPNサーバの構築をご紹介しています。

この環境の検証をしていたところ、Windows端末からVPN接続する際には、以下の注意点があると分かりました。

Windows端末での制限事項（レジストリの編集）

下記の記事で記載されている通り、VPNサーバがNAT配下にいる際は、Windows端末側でレジストリの編集が必要となります。

Windows Vista および Windows Server 2008 で、NAT-T デバイス配下にある L2TP/IPsec サーバーを構成する方法

EC2インスタンスにはEIP等によりグローバルIPアドレスを割り当てできますが、インスタンスに直接割り当てられるのではなく、NAT環境となるため、これに該当すると考えられます。実際に、Windows ServerでVPNサーバを構築し、Windows端末からのVPN接続を検証したところ、当該レジストリを編集しなければ接続できませんでした。

ただし、この検証をしていて一つ疑問が生じました。

この記事でも言及したとおり、弊社ではVPN接続環境にSoftEther VPNをEC2インスタンス上に構築しています。この環境にWindows端末からVPN接続するときには、レジストリの編集は不要です。

各VPNサーバの検証

今回、改めて検証したところ、たしかにVPNサーバにSoftEther VPNを用いる際は、レジストリの編集をすることなく、Windows端末からVPN接続できました。合わせてオープンソースのVPNサーバであるsrongSwanでも検証してみたところ、やはり、レジストリ編集しなければVPN接続出来ませんでした。

結果をまとめると以下のようになります。

VPNサーバ	レジストリ編集
Windows Server 2012 R2 標準搭載のVPNサーバ	要
SoftEtherVPN 4.0	不要
strongSwan 5.3.2	要

なぜ、SoftEther VPNではレジストリの編集が不要なのか

なぜ、SoftEther VPNの時にはレジストリ編集が不要なのか、調べてみました。

NAT装置の検出（NAT discovery）について

IPSecとNATとは相性が悪く、そのままではNATが介在するネットワーク環境では通信出来ません。これを回避するために、IPSecの拡張技術としてNATトラバーサルという仕組みが用意されており、これに対応しているデバイス同士であれば、NATが介在している環境においてもIPSec通信が可能となります。

このNATトラバーサルの一連の手順の中で、通信経路上のNAT装置の存在確認を行うために、お互いにNAT discoveryペイロードの交換が行われます。それぞれに自身のIPアドレスとポート番号等から計算したハッシュ値、相手のIPアドレスとポート番号等から計算したハッシュ値を格納します。

受信側は受信したパケットのIPアドレス/ポート番号を元に自身でハッシュ値を計算し、NAT discoveryペイロード中のハッシュ値との比較により、通信経路上にNAT装置があるか判定します（※）。

※詳細はこちら等参照

パケットキャプチャによる確認

このNAT discovery部分に着目し、SoftEther VPNとVPN接続する時の動作をパケットキャプチャにより確認します。比較のため、strongSwanについても動作を確認しました。

Windows端末側もブロードバンドルータのNAPT配下に存在しています。

strongSwan

まず、strongSwanのキャプチャ結果です。

以下、IKEフェーズ1の第3メッセージ（クライアント→VPNサーバ）です。

以下、IKEフェーズ1の第4メッセージ（VPNサーバ→クライアント）です。

まとめると以下のハッシュ値となっています。

Windows端末側、VPNサーバ側、お互いにハッシュ値が異なるため、両方の環境にNAT装置が存在していると認識します。

	1番目のペイロードのハッシュ値	2番目のペイロードのハッシュ値
第3メッセージ（クライアント→VPNサーバ）	9fc5db...	5b8cc...
第4メッセージ（VPNサーバ→クライアント）	7a411...	6c056...

SoftEther VPN

次にSoftEther VPNと接続した時を確認してみます。以下、IKEフェーズ1の第3メッセージです。

以下、IKEフェーズ1の第4メッセージです。

まとめると以下のハッシュ値となっています。

第3メッセージのハッシュ値と第4メッセージのハッシュ値が同一の値となっていることが分かります。

	1番目のペイロードのハッシュ値	2番目のペイロードのハッシュ値
第3メッセージ（クライアント→VPNサーバ）	6b39c...	f0e17...
第4メッセージ（VPNサーバ→クライアント）	35f29...	6b39c...

考察

上述より、Windows端末側で、ハッシュ値から、VPNサーバに対してお互いに同じIPアドレス/ポート番号を認識していると判断されます。したがって、NAT discoveryの結果、端末側ではサーバはNAT配下には存在していないと判断され、レジストリを編集せずとも、Windows端末からVPN接続出来たものと考えられます。

ではなぜ、VPNサーバ側からのレスポンスのハッシュ値がクライアント側で認識していたハッシュ値と同じだったのか調べてみたとこと、SoftEther VPNのソースコードIPsec_IKE.cの3392行目あたりで以下のような処理がありました。SoftEther VPNではクライアントがWindows(Microsoft)の端末と判断すると、受信したNAT Discoveryのハッシュ値と同じハッシュ値を返答する実装になっているようです。

https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Cedar/IPsec_IKE.c

if (c->IsMicrosoft == false || (your_nat_d_1 == NULL || your_nat_d_2 == NULL || your_nat_d_1->BitArray == NULL))
{
// Calculate exactly
nat_buf2 = IkeCalcNatDetectHash(ike, sa->TransformSetting.Hash,
sa->InitiatorCookie, sa->ResponderCookie, &c->ServerIP, c->ServerPort);
}
else
{
// Parrot the NAT_D payload indicating myself I got from
// the other if it has connected from a Microsoft VPN Client
nat_buf2 = CloneBuf(your_nat_d_1->BitArray);
}