SoftEther VPN User Forum

いつもお世話になります。

接続拠点に Softether Bridgeのカスケード接続をおこない、L2レベルでのVPNを構成しています。（添付図）

拠点側LANはIPv4/IPv6デュアルスタックです。

通常のIPv4インターネット経由でカスケード接続した場合に、支点ローカルブリッジに接続したPCには、拠点DHCPからIPv4アドレス、ゲートウエイ、DNSが取得できます。同様にIPv6もグローバルIP、ゲートウエイ等が取得できており、支点から拠点経由でIPv6インターネットにも接続可能です。

ところが、NGN網内折り返し通信を用いてカスケード接続した場合には、支点ローカルブリッジに接続したPCには、拠点DHCPからIPv4アドレス、ゲートウエイ、DNSが取得できますが、IPv6はアドレスは割り当てられているようですが、ゲートウエイ等が取得できておりらず、支点から拠点経由でIPv6インターネットに接続不可能です。（もちろん支点ローカルブリッジ側は別NICですので、NGNから網内IPv6等などは振られていません。）

接続経由が異なりますが、いずれも拠点と支点はL2で同一LANとなっていることから、挙動は異ならないように思うのですが、NGN経由の場合はどうして、IPv6アドレスが取得できないのでしょうか？

直感的には、接続に成功しているのであればNGN経由であることが原因ではないように思われます。
ただ、NGNによる接続でパケットのロストが起きている可能性は否定できません。
ping などでロス率を確認してみて下さい。

ありがとうございます。

NGN経由は通信はきわめて安定し、拠点ルータへのping は5ms程度でパケットロスはありません。
拠点内LANサーバにも十分なスピードでIPv4通信できています。
接続自体はIPv4,NGN IPv6どちらも全く問題ないようです。
どちらも完全にL2で接続されているのになぜ挙動が違うのか理解に苦しみます。

ちなみに支点からbridgeを利用せず、Clientで接続しても同様の結果となりました。

パケットキャプチャしてみます。

IPv4 インターネット経由でカスケード接続した場合の支点ローカルブリッジ側 icmpv6 のパケットキャプチャです。

接続から1.5秒後（715）から取得できた IPv6 Global IP にて通信が出来ているのがわかります。

IPv6 NGN 経由でカスケード接続した場合の支点ローカルブリッジ側 icmpv6 のパケットキャプチャです。

IPv6 Global IP からの通信がいつまでたっても始まりません。

このキャプチャは支部側の LAN 上の PC で取得したもの、という認識で正しいでしょうか。
キャプチャでは、ルーターからの広告や応答は正常に行われているようなので、クライアント PC の設定の問題ではないかと思われます。

ありがとうございます。

ご指摘の通り支部側のPCのキャプチャです。

クライアントPCのIPアドレス取得は、IPv4,IPv6経由いずれの場合もすべて自動で全く触っていないのです。

単にVPN bridgeがインストールされている別のミニサーバ(Rasoberry Pi)の接続先を変えただけですので、クライアントPCの設定の問題とは考えにくいのですが・・・

クライアントPCが、何らかの経路で別のIPv6接続を見つけてしまっている、ということはないでしょうか

Raspberry Pi の eth1 に直結ですので無いと思いますが、eth0のカスケードを切ってみてキャプチャしてみます。

いろいろ見てみましたがそのようなことがないようです。

IPV6経由では、RAによりGlobal IPv6 の生成には成功していますが、GW、DNSは取得出来ていません。

どうしてでしょうか・・・・

クライアントPCのルーティングテーブルでは、ルーターは検出されているでしょうか。

GWアドレスが取得出来ていないために、ルーティングテーブルにルータは表示されていません。

IPv6では、グローバルIPアドレスはルータから受け取るため、ゲートウェイに関する情報を受け取れていないとは考えにくいと思われます。
ゲートウェイの情報を受け取っていて、かつ、それよりも優先されるゲートウェイの情報を認識しているのではないかと疑っているのですが、そういったものはルーティングテーブル上(または、ネットワーク接続の状態表示)にないでしょうか。

こんな感じです。

IPv6 ルート テーブル
=========================================
アクティブ ルート:
If メトリック ネットワーク宛先 ゲートウェイ
1 306 ::1/128 リンク上
12 58 2001::/32 リンク上
12 306 2001:0:4137:XXXX:XXXXXXXXXX/128
リンク上
10 28 240b:250:82e0:4a00::/64 リンク上
10 276 240b:250:82e0:4a00::XXXX:XXXXXXXXXX/128
リンク上
10 276 240b:250:82e0:4a00::XXXX:XXXXXXXXXXf/128
リンク上
10 276 fe80::/64 リンク上
12 306 fe80::/64 リンク上
12 306 fe80::20bb:19ee:3f57:f54c/128
リンク上
10 276 fe80::e0bb:200d:64f4:bef7/128
リンク上
1 306 ff00::/8 リンク上
12 306 ff00::/8 リンク上
10 276 ff00::/8 リンク上
=================================================

DNSサーバーは取得できているのにデフォルトゲートウェイが見えないのは不思議です。

同じvpn bridgeで、接続経路を変えるだけでこの現象が起きるでしょうか。
また、vpn bridgeではtapへのローカルブリッジを使っているでしょうか？

＞同じvpn bridgeで、接続経路を変えるだけでこの現象が起きるでしょうか。
はい。そのとおりです。

＞また、vpn bridgeではtapへのローカルブリッジを使っているでしょうか？
USB-LANで物理NIC(eth1)を増設し、こちらへのローカルブリッジです。

設定や構成には問題なさそうに思われます。

dhcpv6でipアドレスを取得し、RAの受信に失敗すると、DNSサーバーのアドレスだけ構成されて、デフォルトゲートウェイが空欄になることはあり得るようです。
ただ、パケットキャプチャではRAのパケットも見えていたので、なぜアドレスを取得できなかったのかは分かりません。

pingにロスはないということですが、ロングパケットが消えたり、数分単位でのタイミングによる消失はないでしょうか。
UDPによる接続が不安定な場合、そういった現象が起きることがあります。

いろいろ試してみましたが、セッションは安定して接続しています。

ファイルコピーなどのスループットも、NGN経由の場合は80Mbps程度で安定しており、VPN BridgeをインストールしているRaspberry Pi 2 の性能Maxに近いものと思います。クライアント側のIPv6 GWが取得出来ないこと以外は何の問題もありません。

ちなみにVPN BridgeをインストールしたRaspberry Pi 2 経由でなく、WindowsPCにClientをインストールして、NGN経由で直接接続してみても同様に仮想NICにはIPv6 GWが空欄で取得が出来ませんでした。

という感じでお手上げです。

同じ Windows PC の VPN Client で、IPv4 経由で接続した場合には IPv6 アドレスの取得は成功するでしょうか。

はい、取得出来ます。

そのIPv4での接続のときには、NGNのセグメントは切り離されているでしょうか。
もし、NGN の存在自体が影響を与えているのであれば、NGN のIPv6にも接続した状態でIPv4で接続したときにどういった挙動となるかで切り分けができるのではないかという気がします。

こちらの環境は

１）IPv4 のみでIPv6が振られていない回線
２）IPv4がなく、NGN IPV6 のみの回線

の二種類ですので、IPv4のときはNGN IPv6からは切り離されています。

一本の回線で　Internet IPv4 + NGN only IPv6 ハイブリッドの環境を用意しました。

今まで同じ結果となり、NGN IPv6 経由の場合は、IPv6 GW が取得出来ませんでした。

IPv4 経由、IPv6経由の違いのみで挙動が異なることがわかりました。

NGN 網に接続している事自体が影響しているのかもしれないと考えていたのですが、関係なかったようです。

接続中の VPN セッションの状態には IPv4 と IPv6 の場合で異なる点はあるでしょうか。
(TCP/UDP の違いや、UDP 高速化の有無など)

とくに違いは無いようです。

これはどうにも不可解ですね。
これはもう根拠はあまりないのですが、4.0で追加されたUDP関連機能を疑ってみて、NAT-T無効とUDP高速化の無効化を設定してみるとどうなるでしょうか。

無効化してみましたが、変化ありませんでした。

ルータから降りてくるRAのパケットの中身を解析してみると、１点だけ違いがありました。

GWがとれないIPv6経由では、Router Lifetime が 0 となっているのに対して、

IPv4経由では 9000 sec がセットされていました。

何らかの原因で、IPv6経由でVPN接続すると、ルータから降りてくるRAに上記違いが生じるため、GWが表示されないようです。

Router Lifetime が 0 の RA は、そのIPアドレス情報がインターネット接続に適していないという意味になるようなので、デフォルトゲートウェイが設定されないという挙動については納得できます。
ルーターのアドレス情報が更新された場合などに過去のRA情報を破棄させるために Lifetime が 0 の RA を配信することがあるようです。
http://www.atmarkit.co.jp/ait/articles/ ... ws001.html

また、Windows 7 には、Router Lifetime が ０ の RA を受信すると、その後で正しい Lifetime の RA を受け取ってもデフォルトゲートウェイとして使用しなくなってしまうというバグがあるという情報も見つかりました。
https://support.microsoft.com/ja-jp/help/2551235

Macでも同様の挙動ですので、Windowsの問題ではないようです。
IPv6経由の場合は複数のRAパケットの Router Lifetime はすべて 0 になっています。
IPv4経由の場合は複数のRAパケットの Router Lifetime には3桁以上の数字がすべて入っています。

Router　(ASUS AC-3200）のIPv6の設定を変更（Passthrough→Native:DHCPv6-PD）などに変えてみましたが、Router Lifetimeの値は変わるものの挙動は一緒でした。ルータの問題のような気がしますが、なぜL2-VPNの経路により挙動が異なるのかわかりません。

別件ですが、設定変更やVPN server (Windows10）の再起動などを繰り返していると、 IPv6 DDNSに表示されるIPv6アドレスが、一時IPv6になってしまい、通常のGlobal IPv6で登録されなくなってしまいました。元に戻す方法ありますでしょうか？サーバをインストールし直したりしたのですが直りませんでした。

実験中に VPN サーバーも Lifetime が 0 の RA パケットを受け取ったために、正常な IPv6 のデフォルトゲートウェイの設定を失ってしまっているのではないかと思います。
ルーターを再起動してみてはいかがでしょうか。

VPN接続支点側のRAパケットとローカルLAN側でのRAパケットを比べてみているのですが、

ルータからマルチキャストアドレス FF02::1 へのRAパケットは、どちらも同じはずなのに

VPN側のみ Router Lifetimeが0になっており、ローカルLAN側では600となっています。

同じマルチキャストされたパケットを見ているはずですが、そんなことがあるのでしょうか？？

IPv6 softether VPN経由となったときに、上記が書き換わるなんてことがあるのでしょうか？？


PS　一時IPv6の件はは直らないのでWindowsの方で一時IPv6を無効にして対処しました。なお、上記よりローカルLAN側でのRAパケットにはLifetimeは０のものはないので関係ないかもしれません。

拠点ローカルLAN VPNサーバ側のRAパケットを見てみました。

ローカルLANにブリッジされているNICのパケットキャプチャではマルチキャストされたRAのRouter Lifetimeは600秒がセットされていました。

ローカルLAN側でのRAはすべてRouter Lifetimeは600秒がセットされていました。

NGN IPv6 L2-VPNを経由すると、RAのRouter Lifetimeはすべて0になっています。

SOftether VPNはイーサーフレームをカプセルかしているので中身の書き換えは起こらないと思うのですが、現象的にはIPV6経由のVPNを通過すると、マルチキャストされたRAのRouter Lifetimeが書き換わっているように見えます。

拠点側と支点側を同時にパケットキャプチャをおこない、同じパケットと思われるものを表示します。
これはマルチキャストされたRAではなく、支点側クライアントPC（Mac）からの
router solicitationに応答した、Mac宛てのルーターからのRAです。（つまりおそらく同じパケット）

下記にてわかりますように

Router lifetime (s): 600　　→　　　 Router lifetime (s): 0

　ソースデータも 0x02858 →　0x0000 となっています。

拠点側パケット

Frame 141: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits) on interface 0
Ethernet II, Src: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0), Dst: Apple_77:dc:3c (3c:07:54:77:dc:3c)
Destination: Apple_77:dc:3c (3c:07:54:77:dc:3c)
Source: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0)
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::fa32:e4ff:fea7:78f0, Dst: fe80::10d6:4653:d1be:d15d
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000
Payload length: 88
Next header: ICMPv6 (58)
Hop limit: 255
Source: fe80::fa32:e4ff:fea7:78f0
[Source SA MAC: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0)]
Destination: fe80::10d6:4653:d1be:d15d
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x3af0 [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x40
Router lifetime (s): 600
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 240b:250:82e0:4af0::/64)
ICMPv6 Option (MTU : 1500)
ICMPv6 Option (Source link-layer address : f8:32:e4:a7:78:f0)
ICMPv6 Option (Recursive DNS Server 240b:250:82e0:4af0::1)


支点側パケット

Frame 41: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits) on interface 0
Ethernet II, Src: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0), Dst: Apple_77:dc:3c (3c:07:54:77:dc:3c)
Destination: Apple_77:dc:3c (3c:07:54:77:dc:3c)
Address: Apple_77:dc:3c (3c:07:54:77:dc:3c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0)
Address: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::fa32:e4ff:fea7:78f0, Dst: fe80::10d6:4653:d1be:d15d
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000
Payload length: 88
Next header: ICMPv6 (58)
Hop limit: 255
Source: fe80::fa32:e4ff:fea7:78f0
[Source SA MAC: AsustekC_a7:78:f0 (f8:32:e4:a7:78:f0)]
Destination: fe80::10d6:4653:d1be:d15d
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x3d48 [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x40
Router lifetime (s): 0
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 240b:250:82e0:4af0::/64)
ICMPv6 Option (MTU : 1500)
ICMPv6 Option (Source link-layer address : f8:32:e4:a7:78:f0)
ICMPv6 Option (Recursive DNS Server 240b:250:82e0:4af0::1)

原因と思われるものが判明しました。

仮想HUB拡張オプションの「NoIPv6DefaultRouterInRAWhenIPv6」が1に設定されていないでしょうか。

ありがとうございます。

まさのその通りで、0に設定することにより IPv6 GWが取得出来ました。

説明文も、今回の動作通りの記載でした。

仮想HUBオプションを疑うべきでした。

ありがとうございました。