この記事はWindowsクライアントでのVPN接続についてですが、まずはOSX Serverの話を少々。
OSX Serverで寄せられるトラブルの中にWindows7～10からL2TP/IPsec VPN接続ができないというものがあるようで、アップル曰く、「WindowsがIPSec NAT Traversalを処理するデフォルトの方法に問題があります」とのことです。
参考：http://support.apple.com/kb/HT5078?viewlocale=ja_JP
ということで、Mac ServerでのVPNだけではなく、10や～7、VistaなどXP以降のWindowsクライアントから繋がらないという現象は多いようです。
NAT Traversalを制御する
VPN接続時のクライアント側でエラーもいろいろとあるとは思いますが、多いのは619・809・789あたりでしょうか。
809の場合はクライアントからの通信がVPNサーバまで行き着いていません。
クライアント機での設定の他、ルータ・ファイヤーウォール・NATなどが原因の可能性もありますので、念のためにチェックしてみましょう。
問題がなければ、レジストリよりWindows IPSec NAT Traversalの動作を変更します。
※レジストリの変更はパソコンが起動しなくなる恐れもありますので、くれぐれも注意が必要です。
「レジストリエディタ」により下記レジストリキーを追加します。
「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「services」→「PolicyAgent」を展開します。
「PolicyAgent」の中に新規で「AssumeUDPEncapsulationContextOnSendRule」をDWORD32ビット値で作成します。値は基本的には2を入力します。
パソコンを再起動します。
ちなみに値は0～2で設定でき、下記のように使い分けるようです。
0→NATトラバーサル無効
1→NATトラバーサル有効（クライアントがNAT機器の背後にある場合）
2→NATトラバーサル有効（サーバとクライアントの両方がNAT機器のにある場合）
ここまでで、619・809エラーは回避できると思います。
ローカルセキュリティポリシーの変更
789は「はじめのネゴエーションでのセキュリティエラー」でクライアント側のセキュリティ設定によるものが多いようです。
このエラーで接続できない場合は「ローカルセキュリティポリシー」にてLAN Manager認証レベルの変更が必要です。
「ローカルセキュリティポリシー」→「ネットワークセキュリティ: LAN Manager認証レベル」→ドロップダウンリストで、「LMと NTLMを送信する～ネゴシエーションの場合、NTLMv2セッション セキュリティを使う」を選択します。
また、「ネットワークセキュリティ: NTLM SSP ベース (セキュア RPCを含む) のクライアント向け最小セッション」の「128ビット暗号化が必要」のチェックボックスを解除します。
このLAN Managerの認証レベルはレジストリーで設定することもできます。
「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「Control」→「Lsa」
「LmCompatibilityLevel」レジストリキーをDWORD32ビット値で作成し、1の値を入力すると上記、GUI「ローカルセキュリティポリシー」での「LMとNTLMを送信する～ネゴシエーションの場合、NTLMv2セッション セキュリティを使う」と同じです。
※Windows Vista以降のHome Premiumの場合は基本的に「ローカルセキュリティポリシー」自体がありませんので、この方法でレジストリーを追加する必要があります。
ちなみに「LmCompatibilityLevel」では0～5の設定ができ、数字が大きいほどセキュリティレベルが高くなります。
前述のアップルの解説でも値は1にということなのですが、わたしの環境では実際に3でもOSX ServerのL2TP/IPsecに接続可能ですので、どうも環境によって異なるように思えます。
また、VPNでアクセスに限らず、ネットワーク上にはWindows以外にMac・UNIX・NASなどが混在している場合があります。
これらの機器とWindowsクライアントとは基本的にSMBというプロトコルを使って通信しますが、ここにもLAN Manager認証レベルが関わってきます。
それらのSambaバージョンによってはWindowsからアクセスできないという現象が見られ、この場合はセキュリティレベルの調整が必要となってきます。
