NVR500 L2TP/IPsecの最大VPN回線速度計測 #2

「NVR500 L2TP/IPsecの最大VPN回線速度計測」でNVR500のL2TP/IPsec最大VPN回線速度が「175Mbps」と測定したが、「RTX810 <-> Debian9+StrongSwan5.5.1のL2TP/IPsecスループット」と計測差があった事。その後の計測で175Mbpsが計測出来ないため検討してみた。
計測時の構成は、下記のように「Macbook pro」でインターネットアクセスが出来るよう、WiFi接続のOn/Offを行なっていた。


差異要因を推定
１）VPN端末からのiperf3計測パケットが送受異なった経路で計測された
WiFi接続でiperf3計測が行われた後、VPN接続でWiFi接続時のIPアドレスが配布され送受の経路が異なった。「iperf3」クライアント接続では、受信は「ack」だけなのでスループット増加は、微増程度。

２）VPNを経由せずWiFi経由で計測
WiFiは、「AirMac Time Capsule」2.4GHz 802.11n（転送レート約200Mbps。接続時の自動チャンネル選択により約100Mbps程度の時もある）/5Ghz 802.11ac（転送レート約1000Mbps）で距離約1-2m。802.11nでスループットを計ると約130Mbps程度なので、無線環境条件により175Mbpsのスループット計測可能性がある（150Mbps程度の計測値が行えたが、175Mbps程度の計測値を再現できていない）。

175Mbpsのスループット計測値を再現できないので、計測をやり直すことにした。

再計測条件
「NVR500 L2TP/IPsecの最大VPN回線速度計測」からの変更点

１）iperf3サーバのOSを変更
CPU=Intel Core i7-2600 @ 3.40GHz, Memory=8Gbytes
Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+debian10u2(2019-08-08) X86_64 GNU/Linux

２）計測時WiFiオフ

３）MTU
NVR500 L2TP/IPsecの初期値MTU=1258とmacOSのL2TP/IPsecのMTU=1280で計測
pp select anonymousで「ip pp mtu 1258」「ip pp mtu 1280」の2条件で計測

４）iperf3でサーバ側からの送信時のスループット計測

計測値

１−１）NAPT=off/Filter=off/MTU=1258（クライアント送信）

iperf3のMSS=1206は、MTU(1258)-IP(20)-TCP(20)-TCPオプション(12)

１ー２）NAPT=off/Filter=off/MTU=1258（サーバー送信）


２−１）NAPT=off/Filter=off/MTU=1280（クライアント送信）

iperf3のMSS=1228は、MTU(1280)-IP(20)-TCP(20)-TCPオプション(12)

２−２）NAPT=off/Filter=off/MTU=1280（サーバー送信）


３−１）NAPT=on/Filter=off/MTU=1280（クライアント送信）


３−２）NAPT=on/Filter=off/MTU=1280（サーバー送信）


４−１）NAPT=on/Filter=on/MTU=1280（クライアント送信）


４−２）NAPT=on/Filter=on/MTU=1280（サーバー送信）


計測結果
「RTX810 <-> Debian9+StrongSwan5.5.1のL2TP/IPsecスループット」と同等のスループット測定結果となった。

「Send」と「Receive」でスループットが1.5倍異なる原因を探ってみた。
IN側とOUT側ポートを同時にミラー設定してwiresharkでキャプチャした。
NVR500のポートは、GBT。mirrorポートに100BTのPanasonic CF-W4を接続してwiresharkでキャプチャしたところNVR500接続ポートも100BTに制限された。原因を掴むのに時間を要してしまった。当然と言えば当然。
GBTポートを持ったDynaBook SS RX2に変更して測定した。タイミングによりIN側とOUT側同時にパケットが発生しmirrorポートでキャプチャデータが破棄される事象が観られた。実環境と手持ち機器での評価は、難しい。。。
「Send」では、VPN端末からの暗号化されたESPパケットからDecryptが行われiperf3サーバーに早出する時間を計測。
「Receive」では、iperf3サーバからのパケットを暗号化しESPとしてVPN端末へ早出する時間を計測した。
計測対象は、TCPの同一Sequence番号を持つパケットの時間から計算した。
「Send」時のDecryption時間と「Receive」時のEncryption時間に有意な差があった。iperf3の10秒間計測中データから1秒後あたりと5秒後あたりで5ポイント程度でEncryption/Decryption時間比較してみた。1秒後で3.5msec/3msec、5秒後で7.4msec/3.5msecと差異が大きいがEncryptionに時間が掛かる結果と推定される。

NVR500のL2TP/IPsecでデフォルト設定されるMTUは、MTU=1258。IPv4パケットが効率よく（ESP　Trailerに挿入されるPadがゼロ）なる値が選択されているようだ。IPv6パケットの最小MTUは、MTU=1280とされているため、macOSでは、MTU=1280がデフォルト。Win10は、理由が推測出来ないがMTU=1400がデフォルト。

現時点（2019/11/27）でNVR500もNVR510もIPv6未対応となっているためMTU=1258で良いのだが、IPv6化を目指すためVPNのMTUをMTU=1280で統一設定する事にした。

------------
NVR500 L2TP/IPsecの最大VPN回線速度計測 #3
NVR500 L2TP/IPsecの最大VPN回線速度計測 #2
NVR500 L2TP/IPsecの最大VPN回線速度計測

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

「Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて」でNVR500 L2TP/IPsec VPNサーバにWindows L2TP/IPsec接続すると「NAT/NAPT」が介在していなくても「NAT/NAPT」を誤検出する原因をWiresharkで調べてみた。



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

設定変更後、再起動が必要。

２）NVR500の暗号キーが正しく出力される条件に変更
「Win10 VPN接続時のNVR500 L2TP/IPsec ISAKMP復号鍵が壊れて表示」されるため、Windows L2TP/IPsec　VPNの暗号化キーを「ISAKMP=AES256/SHA256/PFS2048/Group14」「ESP=AES128/SHA1」に変更する

--- powershell command ---
設定変更
Powershell -Command Set-VpnConnectionIPsecConfiguration -AuthenticationTransformConstants SHA1 -CipherTransformConstants AES128 -ConnectionName 'test L2TP ipsec' -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048

設定内容を確認
Powershell -Command (Get-VpnConnection -Name 'test L2TP ipsec').IPSecCustomPolicy


初期値に戻す
Powershell -Command Set-VpnConnectionIPsecConfiguration -ConnectionName 'test L2TP ipsec' -RevertToDefault
----------------

NVR500の暗号化キーも変更する

ipsec sa policy policy_id gateway_id esp aes-cbc sha-hmac

３）Wiresharkで解析
「ヤマハNVR500のL2TP/IPsec VPNパケットをWiresharkで解析」の「Wiresharkでキャプチャ作業」を実施。

Initiator（Windows端末側）からNAT-Dの対応方式を提示


Responder（NVR500側）が方式を決定（RFC 3947 Negotiation of NAT-Traversal in the IKE）


InitiatorとResponderで接続時のIPアドレスとポート番号をNAT-Dで相互に通知し、NAT/NAPTの存在を確認する
RFC3947によれば、IPアドレスとポート番号をinitiatorSPIとresponderSPIと共にISAKMPで合意したSHA256でhash化し、NAT/NAPTの有無を検出する。
hash値=HASH( CKY-I | CKY-R | IP | Port )
1番目に相手側のNAT-D情報。２番目以降に自端末側のNAT-D情報を通知する。自端末に複数アドレスが設定されている場合は、それぞれのNAT-D情報を3番目以降に通知しても良い。

InitiatorでResponderのIPアドレスとポート番号のNAT-D情報


正しく通知されているかhash情報を確認してみる。
Wiresharkの「Packet Details」表示で
「Internet Security Association and Key Management Protocol」セクションの「Initiator SPI」「Responder SPI」をそれぞれ選択し、「Export Packet Bytes...」で「iSPI.bin」「rSPI.bin」としてファイル化する。

「Internet Protocol Version 4, Src: 172.24.1.80, Dst: 172.24.1.2」セクションで「Source 」からInitiatorアドレス「172-24-1-80.bin」、「Destination」からResponderアドレス「172-24-1-2.bin」をファイル化する。

「User Datagram Protocol, Src Port: 500, Dst Port: 500」セクションの「Source Port」からInitiatorポート「iPort.bin」、「Destination Port」からResponderポート「rPort.bin」をファイル化する。

hash化するため、「iSPI.bin」「rSPI.bin」「172-24-1-2.bin」「rPort.bin」のバイナリーファイルを結合し「 irSPI-172-24-1-2-rPort.bin」とする。

--- macOS ---
cat iSPI.bin rSPI.bin 172-24-1-2.bin rPort.bin > irSPI-172-24-1-2-rPort.bin
--- windows ---
copy /b iSPI.bin+rSPI.bin+172-24-1-2.bin+rPort.bin irSPI-172-24-1-2-rPort.bin
------

結合した「 irSPI-172-24-1-2-rPort.bin」ファイルからsha256でhash値を生成する

--- macOS ---
shasum -a 256 irSPI-172-24-1-2-rPort.bin
95a5f628e3662bedf1e22cd29091c3355979a16d2a996fea85e5a9fa30ff9c51  irSPI-172-24-1-2-rPort.bin
--- windows ---
CertUtil -hashfile irSPI-172-24-1-2-rPort.bin sha256
SHA256 ハッシュ (対象 irSPI-172-24-1-2-rPort.bin):
95a5f628e3662bedf1e22cd29091c3355979a16d2a996fea85e5a9fa30ff9c51
CertUtil: -hashfile コマンドは正常に完了しました。
------

Initiator側（Windows端末）で生成されたNAT-D hash値と一致。

InitiatorでInitiatorのIPアドレスとポート番号のNAT-D情報


hash化するため、「iSPI.bin」「rSPI.bin」「172-24-1-80.bin」「iPort.bin」のバイナリーファイルを結合し、「 irSPI-172-24-1-80-iPort.bin」とする。

--- macOS ---
cat iSPI.bin rSPI.bin 172-24-1-80.bin iPort.bin > irSPI-172-24-1-80-iPort.bin
--- windows ---
copy /b iSPI.bin+rSPI.bin+172-24-1-80.bin+iPort.bin irSPI-172-24-1-80-iPort.bin
------

hash値を生成する

--- macOS ---
shasum -a 256 irSPI-172-24-1-80-iPort.bin
0a06ad91ca88bdf3814c4f2e1e8c01d8ecdedc6100a99bba7a0f049459b97ab4  irSPI-172-24-1-80-iPort.bin
--- windows ---
CertUtil -hashfile irSPI-172-24-1-80-iPort.bin sha256
SHA256 ハッシュ (対象 irSPI-172-24-1-80-iPort.bin):
0a06ad91ca88bdf3814c4f2e1e8c01d8ecdedc6100a99bba7a0f049459b97ab4
CertUtil: -hashfile コマンドは正常に完了しました。
------

Initiator側（Windows端末）で生成されたNAT-D hash値と一致。

Responder（NVR500）側で生成されるNAT-D情報を確認する

ResponderでInitiatorのIPアドレスとポート番号のNAT-D情報

「Internet Protocol Version 4, Src: 172.24.1.2, Dst: 172.24.1.80」セクションからInitiatorアドレスは、「Destination」値を「172-24-1-80.bin」名でファイル化。
「User Datagram Protocol, Src Port: 500, Dst Port: 500」セクションからInitiatorポート番号は、「Destination Port」値を「iPort.bin」名でファイル化。結合して「irSPI-172-24-1-80-iPort.bin」とする。

hash値を生成する

--- macOS ---
shasum -a 256 irSPI-172-24-1-80-iPort.bin
0a06ad91ca88bdf3814c4f2e1e8c01d8ecdedc6100a99bba7a0f049459b97ab4  irSPI-172-24-1-80-iPort.bin
--- windows ---
CertUtil -hashfile irSPI-172-24-1-80-iPort.bin sha256
SHA256 ハッシュ (対象 irSPI-172-24-1-80-iPort.bin):
0a06ad91ca88bdf3814c4f2e1e8c01d8ecdedc6100a99bba7a0f049459b97ab4
CertUtil: -hashfile コマンドは正常に完了しました。
------

Responder（NVR500）側で生成されたNAT-D hash値と一致。

ResponderでResponderのIPアドレスとポート番号のNAT-D情報

「Internet Protocol Version 4, Src: 172.24.1.2, Dst: 172.24.1.80」セクションからResponderアドレスは、「Source」値を「172-24-1-2.bin」名でファイル化。
「User Datagram Protocol, Src Port: 500, Dst Port: 500」セクションからResponderポート番号は、「Source Port」値を「rPort.bin」名でファイル化。結合して「irSPI-172-24-1-2-rPort.bin」とする。

hash値を生成する

--- macOS ---
shasum -a 256 irSPI-172-24-1-2-rPort.bin
95a5f628e3662bedf1e22cd29091c3355979a16d2a996fea85e5a9fa30ff9c51  irSPI-172-24-1-2-rPort.bin
--- windows ---
CertUtil -hashfile irSPI-172-24-1-2-rPort.bin sha256
SHA256 ハッシュ (対象 irSPI-172-24-1-2-rPort.bin):
95a5f628e3662bedf1e22cd29091c3355979a16d2a996fea85e5a9fa30ff9c51
CertUtil: -hashfile コマンドは正常に完了しました。
------

Responder（NVR500）側で生成されたNAT-D hash値と一致しない。

NVR500は、Responderアドレス及びポートが「172.24.1.2」及び「500」と認識していない？。
間違える可能性は、「Secondary address」と「Primary address」を取り違えた。
可能性を検証するため「Primary address」でhash値を生成してみた。
「Primary address」は、DHCPで「192.168.1.51」が設定されている。バイナリーでファイル化し「192-168-1-51.bin」として生成。
「iSPI.bin」「rSPI.bin」「192-168-1-51.bin」「iPort.bin」を結合し「irSPI-192-168-1-51-iPort.bin」とする。

hash値を生成

--- macOS ---
shasum -a 256 irSPI-192-168-1-51-iPort.bin
e0bccdcaae9fc4898f8236e171340df82cee7fcff4fa3e69d980709f23ae7146  irSPI-192-168-1-51-iPort.bin
--- windows ---
CertUtil -hashfile irSPI-192-168-1-51-iPort.bin sha256
SHA256 ハッシュ (対象 irSPI-192-168-1-51-iPort.bin):
e0bccdcaae9fc4898f8236e171340df82cee7fcff4fa3e69d980709f23ae7146
CertUtil: -hashfile コマンドは正常に完了しました。
------

Responder（NVR500）側で生成されたNAT-D hash値と一致する。
「Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて」の「NVR500 system.log(debug on)」で「2019/09/14 23:03:11: [IKE] NAT Traversal: NAT box detected, start keepalive timer」となる原因と思われる。

NVR500の間違ったNAT-D(20)による接続断の理由を検討する


ISAKMPのパケット#3から#8までNAT-Traversal関連情報を「RFC3947」と「Traveling a NAT」を参考にまとめてみた

パケット#3,4のNAT-DとSource/Destination IPアドレスとポートからサーバ側にアドレス変換NATの存在が判断される。
パケット#5,6でポート4500/udpへの切替（ここから暗号化）。パケット#7,8で「UDP-Encapsulation-Transport」が選択される。
Initiator（win10）側は、「AssumeUDPEncapsulationContextOnSendRule=0」なので「サーバのNAT背後を許可しない」。結果接続に失敗する。

「AssumeUDPEncapsulationContextOnSendRule=1」の場合
「サーバのNAT背後を許可」

接続される

「AssumeUDPEncapsulationContextOnSendRule=2」の場合
「サーバ及びクライアントのNAT背後を許可」

接続される

「AssumeUDPEncapsulationContextOnSendRule=0」でNATが存在している場合

win10(172.24.1.80) <-> NVR500（IPv4 over IPv6）<-> Transix DS-Lite（217.178.25.161:12554）<-> Plala IPv4 PPPoE <-> NVR500 L2TP/IPsec VPNサーバ（114.183.167.149:500）


パケット#3,4でクライアント側がNAT背後にある事が判る。パケット#5,6でポート4500/udpに変更し接続（暗号化）。サーバがNAT（1:1）で接続されていることが推定される。パケット#7,8で「UDP-Encapsulation-Transport」が選択される。サーバがNAT背後に無いので、「AssumeUDPEncapsulationContextOnSendRule=0」でも接続される。

４）結果

NVR500のL2TP/IPsec VPN接続でSecondary IP addressがVPNサーバアドレスに設定されているとNAT-Discoveryでhash値計算対象がPrimary IP addressを使用してしまい、サーバ側にNATが存在しなくても、サーバがNAT背後に設置されている状態となる。静的NATが設定されている場合は、未確認。

Windows L2TP/IPsec VPNでは、「AssumeUDPEncapsulationContextOnSendRule=0」（デフォルト）のため接続出来ない。
「0x1」または「0x2」に設定する必要がある。

macOS（10.14.6）Mojaveでは、接続出来る。

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

「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」

NVR500 L2TP/IPsecの最大VPN回線速度計測

2011年9月にNVR500を導入して約8年が経過しようとしている。VPN（L2TP/IPsec）が2017年10月に追加されたが「IPv6未対応」であった。後継機NVR510も調べてみたが、VPN（L2TP/IPsec）は「IPv6」未対応で「L2TPv3」「IPsec」にも未対応であった。ひかり電話対応で「L2TPv3」「IPsec」対応機は、NVR700Wしか無い。。。NVR700W（¥100,500-）>=NVR510（¥37,000 ~ ¥38,800-）+RTX830（¥48,000- ）の市場価格（2019年8月現在）。
どうしたものか考慮中にRTX810のスループット測定を見つけた。イントラネット内のスループット計測をしてみた。

ネットワーク構成は、ひかり電話用のホームゲートウェイ（PR-S300SE）配下にNVR500+GS116E（L2スイッチ）とWZR-HP-G300NHにOpenWrt（18.06.1）+StrongSwan（5.6.3-3）をインストールしたIKEv2 VPNサーバー。L2TP/IPsecとIKEv2のスループットを計測するため「172.24.0.0/16」のネットワークをNVR500のLAN2へsecondary addressを設定してVPN端末接続用GBT回線を設定した（192.168.1.0/24と共用NWとなるが、今回の測定に影響なしと推定した）。スループットは、IPv4だけ測定するため、IKEv2 over IPv6は、「2409:10:XXXX:YY00::/64」から「2409:10:XXXX:YY20::12:1/64」へ接続し、IPv4 over IKEv2 over IPv6のスループットを計測した。
スループットは、「iperf」を使用し、サーバとクライアント間で計測する。各計測機器用のバイナリーを使用した。
サーバは、CPU=Intel Core i7-2600 @ 3.40GHz, Memory=8Gbytes, Windows7Professional 64bitOS
クライアントは、Macbook pro（CPU=Intel Core i7-2.3GHz, Memory=16Gbytes, macOS Mojave）で計測した。
計測対象のネットワーク機器のMTUは「ぷららIPv6 IPoE環境のMTU確認」。

サーバのNWインターフェースを含まないスループット

クライアントのNWインターフェースを含まないスループット


（１）GS116Eポート間スループット
Macbook proをGS116Eポートに接続し、ポート間スループットを計測


（２）GS116Eポート - NVR500-LAN1 - NVR500-LAN2間スループット
L2スイッチに加えNVR500のルーティングが加わったスループット


定時的（5分間隔）に動作しているspeed-testと重なると２ポート同時に接続するためスループットが落ちる


ds-216jからnvr500を経由してTransix DS-Lite（IPv4 over IPv6）のスループット計測


（３）GS116Eポート - NVR500 - OpenWrt 間スループット
GS116EポートからNVR500とOpenWrtのルーティングでWZR-HP-G300NHのLANポート間のスループット

NVR500のスループットが「913Mbps」程なのでWZR-HP-G300NHのルーティング・スループットと言える。

WZR-HP-G300NH（OpenWrt）単独ルーティングのスループット


計測上スループットが逆転している。WZR-HP-G300NHのスループットがおおよそ最大「250Mbps」程で、WZR-HP-G300NHの計測以外の通信とNVR500の計測以外の通信が重なり発生していると思われる。実環境でのスループット計測が原因。
それにしても、WZR-HP-G300NHのルーティング能力が低い。。。Buffaloのファームウェアだともっとスループットが高いのかな？？？
Buffalo特徴で「光回線が活かせる高速ルータ」という売りで「PPPoEスループット 約131Mbps」「FTPスループット 約151Mbps」としていたので妥当なルーティング・スループットかもしれない。この頃（2009年3月発売）は、まだ「ギガ・ファミリー（2014年7月開始）」が無かった頃なので妥当な仕様か。。。

（４）OpenWrt - SWポート間スループット
WZR-HP-G300NHのLAN1-4ポート間のスループット（L2スイッチ間のスループット）



（５）NVR500 L2TP/IPsecスループット
Macbook proを「172.24.0.0/16」のネットワークへ接続し、手動設定で「172.24.1.50/255.255.0.0」のIPを設定。ルーター（デフォルトルート）は、無指定とする。


NVR500に設定したsecondary address「172.24.1.2/16」をL2TP/IPsecのVPNサーバとして接続するよう設定


VPN接続（192.168.11.25として接続された）


VPN接続を確認


「192.168.1.56」のiperf3サーバとのスループット（171Mbps - IN/OUT@LAN2）


「192.168.11.23」のiperf3サーバとのスループット（174Mbps - IN@LAN2/OUT@LAN1）


「192.168.12.155」のiperf3サーバとのスループット（166Mbps - IN/OUT@LAN2 and OpenWrt）


「RTX810 <-> Debian9+StrongSwan5.5.1のスループット（MTU=1350）」事例より若干良い値となった。計測した機器のMTUは、Macbook pro及びNVR500共に1280（インターフェースMTU-40がiperf3のデフォルトMSS）。RTX810とNVR500は、CPU・クロック共に同じ（ARM/450Mhz）、メモリ容量が異なる。NVR500のESP暗号化設定は、AES-CBC/SHA1-HMACなので条件は一緒。RTX1210のL2TP/IPsecのスループットを参考にするとmacOS MojaveのL2TP/IPsecの最大スループットもこれ以上と推定される。
--- 2019/9/3追記 「macOS MojaveのIKEv2 IPsec VPN最大回線速度計測」 ---

NVR500のL2TP/IPsecのスループット実力値が約174Mbpsと思われる。
--- 2019/8/19追記 ---
「NAPT」「Security Filter」が入っていなかった事が「差異」となった可能性がある。
「NAPT」を追加して確認

ip lan2 nat descriptor 10
nat descriptor type 10 masquerade
nat descriptor address outer 10 secondary
nat descriptor masquerade static 10 1 192.168.11.250 udp 500
nat descriptor masquerade static 10 2 192.168.11.250 esp
nat descriptor masquerade static 10 3 192.168.11.250 udp 4500

「NAPT+Filter」を追加して確認

ip lan2 secure filter in 100 101 102 103 104
ip lan2 secure filter out 110 111 112

ip filter 100 pass 172.24.1.50 192.168.11.250 udp * 500
ip filter 101 pass 172.24.1.50 192.168.11.250 esp * *
ip filter 102 pass 172.24.1.50 192.168.11.250 udp * 4500
ip filter 103 reject 172.24.0.0/16 * * * *
ip filter 104 pass * * * * *
ip filter 110 pass 192.168.11.250 172.24.1.50 * * *
ip filter 111 reject 192.168.11.250 172.24.0.0/16 * * *
ip filter 112 pass * * * * *

スループット「175Mbps」で変化なし。。。
約1.1~1.5倍の差異は何が原因。。。
---

（６）OpenWrt + StrongSwan IKEv2 スループット

15Mbps。
こんなスループットなんだ。。。


------------
NVR500 L2TP/IPsecの最大VPN回線速度計測 #3
NVR500 L2TP/IPsecの最大VPN回線速度計測 #2
NVR500 L2TP/IPsecの最大VPN回線速度計測

Win10でNVR500 L2TP/IPsec VPNへ接続した時のMTUを確認

Windows10でNVR500へL2TP/IPsec VPN接続しWIresharkでパケット解析が出来るようになった。pingパケットを解析中に「Don't fragment」フラグをセットしているのに経路中の最小MTUを超えた長さでも応答があった。
確認してみる。

（１）準備
Windows10（Version 1803/OS build 17134.648）のL2TP/IPsec接続パラメータ

NVR500（Rev 11.00.38）
「ipsec sa policy 2 2 esp aes-cbc sha-hmac」「syslog debug on」

VPN接続後、「show ipsec sa」で接続を確認（シリアルコンソール）


「show ipsec sa gateway 2 detail」で暗号鍵を確認（シリアルコンソール）


ログからIPSAKMPのIKEv1鍵とESP鍵を抽出（シリアルコンソール）


鍵をセットして復号したパケットを確認

プロトコル「L2TP」は、「ESP」から復号されたパケット。

（２）pingで経路のmtuを確認する
NVR500のL2TP/IPsec（「ip pp mtu 1258」）のMTUは、MTU=1258バイト。IPsecの
MTUは、MTU=1280バイト。aes-cbc/sha-hmacのESPに必要なMTUは、MTU=1344バイトとなる。

VPN接続後Windowsコマンドから「ping -4 -f -n 5 -l 1230 192.168.12.1」でL2TP/ipsecの疎通を確認。

NVR500のLAN2（PR-S300SEとの接続インターフェース）でパケットをキャプチャ。Win10（192.168.11.6）から192.168.12.1へのICMPパケットを含むL2TP/IPsecパケットがPPPoE上でキャプチャされ復号状態で表示。

パケット#7423「Etherヘッダー14バイト+PPPoEヘッダー6バイト+PPPヘッダー2バイト+VLANタグ4バイト+IPv4 ESPパケット1344バイト=1370バイト（FCSは、Wiresharkでカウントされない）」は、パケット#7424「Etherヘッダー14バイト+復号されたICMPパケット1258バイト=1272バイト」のIPv4パケットで、192.168.1.1ゲートウェイを経由して192.168.12.1へ転送される。
192.168.12.1からのreplyパケット#7425（1276バイト VLANタグ4バイトを含む）は、NVR500のPPインターフェースからL2TP/IPsec1344バイトに変換され、PPPoEパケット#7426（1366バイト VLANタグなし）でWin10へ転送される。フラグメントされていない事が確認出来る。

L2TPのパケット長を「+1（1231バイト）」してフラグメントが発生するか確認する。
IPsec（ESP）パケットのPayloadは、16の倍数となるよう「Pad(n)」が挿入されるため、IPsec Payload=1296バイト、IPsec ESPに必要なMTUは、MTU=1360バイトとなる。

「ping -4 -f -n 5 -l 1231 192.168.12.1」でフラグメントするか確認した。「-f」でフラグメントしない指定をしたが、応答がある。
ヤマハL2TP/IPsecの解説には、「送信する物理インターフェースのMTUに従い、必要に応じてフラグメントして送信」とある。L2TP中のIPv4 icmpパケットは、「Don't fragment」だが、L2TP/IPsecのESPパケットは、「fragment」でNVR500に到達している。

Win10からの16バイト増加したL2TP/IPsecパケット#8113（1386バイト）を受け、IPv4 ICMP（Don't fragment）#8114（1273バイト）でMTU=1500バイトのインターフェースに転送されるのが記録される。

192.168.12.1からreplyパケットは、NVR500のPPPインターフェースに設定された「ip pp mtu 1258」に従い、#8115と#8116にフラグメントされる。IPv4のフラグメントは、送信先インターフェースのMTU内になるようIPv4 Payload部が8の倍数となるよう分割される。また、分割されたPayload部がEthernetの最小Payload長46バイト以上となるよう不足分がPad(n)として挿入されEtherフレーム長（FCSを含め）最小64バイトが確保される。
IPv4 Fragmentを下表で検証してみた。
パケット#1、#2の「targetMTU」欄は、Etherの最小フレーム長を考慮したMTU値を計算設定。Etherの最小データ長46バイト以上としている。「Wireshark Length」は、キャプチャされたFCSを含まないデータ長として計算評価した。Wiresharkのキャプチャデータ（パケット#8116）では、VLAN IDの4バイトが含まれ64バイトとなっている

フラグメントされた2個のパケット（#8117と#8118）は、それぞれ下記のようにESPパケットに変換され、「PPPoE(6)+PPP(2)（+8バイト）」ヘッダーが追加されWin10へ転送される。#2の最小Etherパケットは、Pad(n)が取り除かれESPパケットとして転送される。



Windows10 L2TP/IPsec VPNのインターフェースMTUを調べてみる
「netsh interface ipv4 show interfaces」で確認（VPN接続状態である事が必要）

「MTU=1400バイト」となっている。

「MTU=1400バイト」でpingしてみる

replyが返って来る


「MTU=(1400+1)バイト」でpingしてみる

Win10のIPsecインターフェースでフラグメントされない（送出されない）。


「MTU=1400バイト」のL2TP/IPsecパケットをWiresharkでキャプチャ（NVR500のPPPoE接続部）してみると、パケット#4914、#4915とNVR500に到達する前にフラグメントされている。

NGNのIPv4 MTUが1454バイトなのでフラグメントが発生する。Wireshark上の#4914（Length=1478バイト）、#4915（Length=82バイト）パケット長は、VLANタグが追加されるので下表値より+4バイトの長さとなる。

フラグメントされたパケットは、NVR500で再構成と復号が行われ、IPv4パケット#4916『Eth(14)+IPv4(20)+ICMP(8)+Payload(1372)（Don't fragment）」として192.168.1.1経由で192.168.12.1へ転送される。

応答パケットは、192.168.12.1からNVR500のL2TP/IPsec用PPインターフェース「MTU=1258バイト」に合わせてフラグメントされ返送される。

Wireshark上では、VLANタグ4バイトが付加され、#4917（Length=1270バイト）、#4918（Length=186バイト）で受取り、L2TP/IPsecとしてIPv4 ESPで転送される。
#4917パケットは、L2TP/IPsec化され「PPPoE(6)+PPP(2)」ヘッダーが追加され#4919（Length=1366バイト）応答パケットとして送出される。

#4918パケットもL2TP/IPsec化され「PPPoE(6)+PPP(2)」ヘッダーが追加され#4920（Length=278バイト）応答パケットとして送出される。


NVR500のL2TP/IPsecは、送出するインターフェースのMTUに従いフラグメントされるため、ぷららのIPv4 PPPoEインターフェース「ppp lcp mru on 1454」へ送出する時にフラグメントされる事になる。しかし、L2TP生成時の「ip pp mtu 1258」で制限されるため、フラグメントは発生しない。

Windows10のL2TP/IPsecに設定されているMTU=1400バイトは、IPv4 over PPPoE on NGNでは、フラグメントされるため、下表で示すMTU=1354バイトが最適であるが、

iPhone（iOS）やmacOSのL2TP/IPsecのIPsecインターフェースMTUがMTU=1280バイトである事からWindows10 L2TP/IPsec VPNのMTUをMTU=1258バイトとする事にした。


（３）Windows10 L2TP/IPsec VPNのMTUを変更する

（a）Windows10のL2TP/IPsec VPNインターフェースのインターフェースを調べる。
L2TP/IPsec VPNを接続する（接続しないとインターフェースが表示されない。設定も出来ない。）
「netsh interface ipv4 show interfaces」
（b）「netsh interface ipv4 set interface interface="L2TP IPsec on NVR500" mtu=1258」を設定する。「interface=」には、VPNの「接続名」を設定する。


（c）レジストリー情報
「L2TP/IPsecインターフェースのGUIDが不明なため、L2TP/IPsec VPN接続後、上記（１）（２）のようにMTUを設定し、設定したMTU値をレジストリ検索する事で「GUID」を確認する。GUID特定後は、未接続状態でもレジストリのMTU値変更で設定可能。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}
MTU = (DWORD) 0 <-デフォルト値（1400）
MTU = (DWORD)0x000004ea(1258)
MTU = (DWORD)0x0000054a(1354)
MTU = (DWORD)0x00000578(1400)