rabbit51

it's since Nov.30 2005
May.29 2014, transferred from broach

Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて

2019-09-15 13:00:00 | NVR500
「Windows L2TP/IPSec VPN接続」で検索すると「AssumeUDPEncapsulationContextOnSendRule」を設定する情報に出会う。ヤマハのNVR500にL2TP/IPSec機能が追加され(2017年10月)設定を行ったWindows10でL2TP/IPSec接続時にNVR500に記録される「ISAKMP複合鍵」確認時に「AssumeUDPEncapsulationContextOnSendRule」を設定しなくても接続できる事を確認していた。
Windows OSとNVR500のL2TP/IPSec VPN接続スループットを確認していた時に「NAT」を使用していないのに「AssumeUDPEncapsulationContextOnSendRule」設定で接続可能となったので記録しておく。


NVR500 L2TP/IPsecの最大VPN回線速度計測」と同様の構成で「172.24.0.0/16のGBT回線」に接続したWindows OS機からNVR500のL2TP/IPSec VPNに接続してスループット計測を試みた。「Windows10(Ver. 1809/OS build 17763.737)on Parallels Desktop 14 for Mac(ver. 14.1.3(45485)) on macOS Mojave(10.14.6)」構成でCore i7 - 4850HQの「4Core/16Gメモリ」から「2Core/2Gメモリ」をWindowsに割当てある。
Windows10にIPv4アドレス「172.24.1.80/16」を設定し、L2TP/IPsec接続したところエラーで接続出来なくなった。

原因を探るため「Dynabook SS RX2/T7H(Core 2 Duo - U9300@1.2Ghz/3Gメモリ)Windows7 32bit(ver. 6.1.7601)」で調査した。

「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」を確認



「172.24.1.90/16」を静的に設定し、Default Gateway「172.24.1.2」でNVR500から「DS-Lite」経由でインターネットアクセスが出来るよう設定


ぷららIPv4 over PPPoEで公開しているL2TP/IPsec VPNサーバ「AAAAAAAA.BBN.netvolante.jp」にL2TP/IPsecでVPN接続させる。問題なく接続できる。このVPN接続名を「L2TP-IPsec-Internet」としている。


VPN接続端末には、「192.168.11.16」がアサインされる。

Windows10でも同じ。

VPNサーバアドレスを「172.24.1.2」としたVPN接続名「L2TP-IPsec-local」を設定して接続する。
Windows10と同様にエラーで接続出来ない。


「L2TP-IPsec-Internet」では、NVR500からIPv4 over IPv6でtransix「DS-Lite」へtunnel転送され、AFTRで「NAPT」変換され、ぷららのIPv4 over PPPoEで公開しているNVR500のL2TP/IPSec VPNサーバに接続する。NVR500では、ぷららのグローバルIPv4アドレスから「NAPT」でイントラネット内のプライベートIPv4アドレスに変換され接続する。NAT-Traversal(ポート4500)が使われている。

「L2TP-IPsec-local」では、NVR500のL2TP/IPSec VPNサーバに直接ローカルアドレスで接続し「NAPT」を介さない。全てのポート及びプロトコルが利用できるようフィルタも設定していない。

万策尽きて「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」を設定してみた


「L2TP-IPsec-local」もVPN接続できるようになった。。。


VPN接続端末には、「192.168.11.16」がアサインされる


debian10サーバを「192.168.11.0/24」にDHCP接続(192.168.11.16を取得)し「iperf3 -s」で起動。L2TP/IPsecが取得していた「192.168.11.16」が取られてしまった。NVR500のL2TP/IPsec接続端末へのIP設定は、DHCPプールから設定されるよう設計しているのだが、一度使われたIPが直ぐに再利用されて「192.168.11.17」が設定された。不思議。。。
接続後、ipref3サーバを使いスループット測定。


「Windows10 on Parallels Desktop on macOS Mojave」でも同様に「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」でローカル接続が出来るようになった。

「NVR500側の問題」なのか「Windows側」の問題なのか不明。パケットキャプチャすれば少し判るかも。。。
「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」の時、NVR500側で受信側SAが複数生成されるので、Windows側から複数回のリトライが行われている。NVR500のdebug logでは、経路中にNATの存在を検出している(構成図の通り経路中にNATは存在しない)。

-------- NVR500 system.log(debug on) --------
2019/09/14 23:03:10: [IKE] respond ISAKMP phase to 172.24.1.90
2019/09/14 23:03:10: [IKE] add ISAKMP context [2516] dd4d9aec1830541e 00000000
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 20
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 19
2019/09/14 23:03:11: [IKE] NAT Traversal: NAT box detected, start keepalive timer
2019/09/14 23:03:11: [IKE] calculate Diffie-Hellman value
--------

回避策
経路中にNATが無くてもWIndows OS側で
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule = (DWORD)0x2
とする

------ 2019/10/30 追記
NVR500が原因かWindowsが原因かWiresharkを使ってパケット解析し原因を探ってみた。
Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて#2

コメント    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« IKEv2 VPNの暗号化方式(AES-... | トップ | 日本国はいつからヨーロッパ... »
最新の画像もっと見る

コメントを投稿

ブログ作成者から承認されるまでコメントは反映されません。

NVR500」カテゴリの最新記事