This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
IPsec L2TP VPN サーバ
多くのオペレーティングシステムは、L2TP/IPSec による VPN 機能を実装しています。L2TP/IPSec は、IPsec (インターネットプロトコル セキュリティ) による機密保持および認証サービス、レイヤ2トンネルプロトコル(L2TP)によるネットワークトンネリング、pppdを通したユーザ認証を組み合わせたものです。管理者は、複数の異なるシステムをまたいでVPNネットワークを設定可能です。Android、Windows、GNU/Linux、macOSなどのオペレーティングシステム間で、商用ソフトウェアを一切追加することなしに、VPNを設定可能です。
はじめに
IPsec/L2TPは、Windowsなどのオペレーティングシステムで一般的に使用されているVPNプロトコルです。VPN クライアント側としては、Windows では 2000 以降のすべてのバージョンに組み込まれており、（OpenVPN などと異なり）外部クライアントを要せずとても便利です。他方のサーバ側の Linux については、IPsec、L2TP および PPP の少なくとも3つのレイヤが関わってしまいますので、設定がずっと難しいです。
- IPsecの設定は、ネットワーク通信の機密性およびクライアント（システム）の認証を提供します
- L2TP でトンネルを設定することで、VPN トラフィックが透過的に IPsec を通過します
- PPP（ポイント・トゥ・ポイント プロトコル）の設定は、ユーザー認証を管理します
このガイドでは、DHCP や RADIUS、Samba、公開鍵インフラ（PKI）の設定を記載していません。Linuxをクライアントにする際の設定方法を記載していません（実際には、このガイドを読めば容易に判るはずですが）。そもそも、クライアント側の Windows の設定について記載しているのも、サーバ設定のトラブルシューティングに使うことを想定しているからにすぎません。
想定および設定例
このガイドでは、以下の状況を想定した設定例を記載しています（そのため実際の設定は、状況に応じて読み替えて行ってください）:
- ドメイン名は example.com
- サーバ名は vpn.example.com
- CA(認証局) ファイル名は ca.crt
- サーバ側の認証ファイル名は vpn.example.com.crt
- サーバ側の鍵ファイル名は vpn.example.com.key
- クライアント側の認証ファイル名は client.example.com.crt
- クライアント側の鍵ファイル名は client.example.com.key
IPsec
最初にセットアップするレイヤ（しかも最難関）が IPsec です。IPsec はピア・トゥ・ピア（1対1）なので、IPsec 用語としてはクライアントをイニシエータ、サーバをレスポンダと呼びます。
Windows は IKEv1 をその処理に用います。Portage にある IPsec の実装には、ipsec-tools (racoon)と LibreSwan、strongswan の3種類の選択肢があります。
次のセクションでは、それぞれ異なる設定が説明されています。それぞれの選択肢について以下を記載しています
- どうやって認証に PSK を用いるか
- どうやって認証に証明書を用いるか
PSK か証明書か、いずれか一つを選んでください。また、証明書による認証については、必要な証明書が既に用意されていることを前提にしています。
選択肢 1: ipsec-tools (racoon)
net-firewall/ipsec-tools は、NAT 裏にサーバがある場合や、NAT 裏のクライアントに対応する場合には、
nat USE フラグを有効にしてコンパイルされていなければなりません。ipsec-tools は、最小限の機能で構成されていますが、BSD 系由来のものと比べると親しみやすくなっています。しかし、BSD 系と異なり、Linux は IPsec について別途のインターフェイスをもっていません。
ipsec-tools をインストールしたあとは、いくつかのファイルを作成せねばなりません。まず、これらファイルを置くディレクトリを作成します:
root #mkdir /etc/racoon/certs
root #mkdir /etc/racoon/scripts
ipsec-tool における、PSK 方式でのセットアップ
まず、事前共有鍵(PSK)ファイルを作成します。このファイルは、ピア間の認証に用いる固有の鍵です。
user $dd if=/dev/random count=24 bs=1 2>/dev/null | hexdump -e '24/1 "%02x" "\n"'PSK ファイルの各項目は、ID と鍵で構成されています。Windows では 完全ドメイン名(FQDN)を ID にしています。鍵は、文字列もしくは（ 0x で始まる）16進数で表記されます。いずれにしても、内容（鍵そのもの）は、管理者のみが読み出します:
/etc/racoon/psk.txtclient.example.com 0x87839cfdab5f74bc211de156d2902d128bec3243
racoon.conf ファイルの中身では、path pre_shared_key の設定項目でこの PSK ファイルを参照します。
/etc/racoon/racoon.confPSK で racoon を使うpath certificate "/etc/racoon/certs";
path pre_shared_key "/etc/racoon/psk.txt";
path script "/etc/racoon/scripts";
remote anonymous {
exchange_mode main;
my_identifier fqdn "vpn.example.com";
passive on;
generate_policy on;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 14;
}
}
sainfo anonymous {
encryption_algorithm aes, 3des;
authentication_algorithm hmac_sha1, hmac_md5;
compression_algorithm deflate;
}
ipsec-tools における、証明書方式でのセットアップ
ca.crt とvpn.example.com.crt とvpn.example.com.key を、 /etc/racoon/certs にコピーします。 vpn.example.com.key ファイルは、一般ユーザが読み書き不可能な属性にしてください。
つぎに、racoon.conf ファイル内の remote anonymous セクションでこれらのファイルを参照します:
/etc/racoon/racoon.confracoon に証明書を使うpath certificate "/etc/racoon/certs";
path pre_shared_key "/etc/racoon/psk.txt";
path script "/etc/racoon/scripts";
remote anonymous {
exchange_mode main;
my_identifier fqdn "vpn.example.com";
certificate_type x509 "vpn.example.com.crt" "vpn.example.com.key";
ca_type x509 "ca.crt";
passive on;
generate_policy on;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 14;
}
}
sainfo anonymous {
encryption_algorithm aes, 3des;
authentication_algorithm hmac_sha1, hmac_md5;
compression_algorithm deflate;
}
ipsec-tools のトラブルシューティング
もしも支障が起こったら、このセクションが参考になる解決手段を指し示しているかもしれません。
セキュリティポリシーと NAT の作成
generate_policy on; という設定で、適切なセキュリティポリシーが生成されます。しかし、NAT がある（少なくとも、サーバが NAT 裏にある）と、期待するようなポリシーが生成されません。したがって、もしもトンネル内をトラフィックが通らないようならば、ポリシーをマニュアルで定義しなければなりません。
/etc/ipsec-tools.conf にポリシーを作成します:
/etc/ipsec-tools.conf#!/usr/sbin/setkey -f
flush;
spdflush;
spdadd vpn.example.com[l2tp] 0.0.0.0/0 udp -P out ipsec
esp/transport//require;
spdadd 0.0.0.0/0 vpn.example.com[l2tp] udp -P in ipsec
esp/transport//require;
このポリシーでは、防護されるべきサーバとの L2TP トラフィックのすべてを通過させています。そのため、追加のセキュリティの関連付けなしにはトラフィックが全く防護されず、（認証や暗号化なしの）一般的な通信でインターネットを通過してしまいます。セキュリティの関連付けがないため拒否されることがありませんので注意してください。
選択肢 2: LibreSwan
LibreSwan は （FreeS/WAN のフォークである）OpenSwan のフォークです。実際には、もともとの OpenSwan の制作者達によるフォークですが、彼らが Xelerance を辞めたあとに "Openswan" の名称をめぐって紛争になり訴訟に至りました。その結果として、LibreSwan という名称が採用されました。
それぞれの VPN 設定ごとにファイルを分けるのであれば、/etc/ipsec.conf の最終行のコメントを外せば可能です:
/etc/ipsec.conf# Configuration (.conf) files can also be placed in the "/etc/ipsec.d/" directory # by uncommenting this line #include /etc/ipsec.d/*.conf
LibreSwan の設定ファイルでは、NAT トラバーサルがデフォルトで有効になっていますので、特別な設定作業は不要です。
LibreSwan における、PSK 方式でのセットアップ
共通鍵を作成せねばなりません。鍵は、引用符で括られた文字列か、16進数字です。次の例では、PUT_VPN_SERVER_IP を実際のサーバの IP アドレスに置き換えてください。ドメイン名を用いることも可能ですが、LibreSwan の制作者達は推奨していません。%any という設定は、この PSK を用いるあらゆるクライアントを許可します。
/etc/ipsec.d/vpn.example.com.secretPUT_VPN_SERVER_IP %any : PSK 0x87839cfdab5f74bc211de156d2902d128bec3243 # もしくは、16進数字の代わりに平文テキストを使用: # PUT_VPN_SERVER_IP %any : PSK "password_pass"
そして、/etc/ipsec.d/vpn.example.com.conf を作成します:
/etc/ipsec.d/vpn.example.com.confconn vpnserver
type=transport
authby=secret
pfs=no
rekey=no
keyingtries=1
left=%defaultroute
leftprotoport=udp/l2tp
leftid=@vpn.example.com
right=%any
rightprotoport=udp/%any
auto=add
LibreSwan における、証明書方式でのセットアップ
LibreSwan のためには、Network Security Services (NSS) を要し、適切に設定されていなければならず、証明書の管理に用います。容易にするためには、PKCS#12 バンドルには、サーバの秘密鍵と証明書、認証局(CA)の証明書がまとめておくべきです。
user $openssl pkcs12 -export -certfile ca.crt -inkey vpn.example.com.key -in vpn.example.com.crt -out /etc/ipsec.d/vpn.example.com.p12このバンドルを、NSS データベースにインポートします:
root #cd /etc/ipsec.d
root #pk12util -i somewhere/vpn.example.com.p12 -d .LibreSwan の設定ファイルは、インポートされた内容物をニックネームで参照します。certutil -L -d . や certutil -K -d . を用いればニックネームがわかります。
/etc/ipsec.d/vpn.example.com.secrets: RSA "vpn.example.com"
上記の例では、vpn.example.com がニックネームとして用いられており、certutil -K -d . コマンドで判ります。
/etc/ipsec.d/vpn.example.com.confconn vpnserver
type=transport
authby=rsasig
pfs=no
rekey=no
keyingtries=1
left=%defaultroute
leftprotoport=udp/l2tp
leftcert=vpn.example.com
leftid=@vpn.example.com
right=%any
rightprotoport=udp/%any
rightrsasigkey=%cert
auto=add
ここでは、vpn.example.com はcertutil -L -d . コマンドで判るニックネームです。
選択肢 3: strongSwan
strongSwan は、FreeS/WAN のフォークの一つです。（多くのコードが書き換えられていますが。）
strongSwan 5.0 以降では、NAT トラバーサルは自動になり、設定不要になりました。
strongSwan では ipsec.secrets が作成されませんから、自ら作成する必要があります:
root #touch /etc/ipsec.secrets && chmod 664 /etc/ipsec.secretsstrongSwan における、PSK 方式でのセットアップ
共通鍵を作成せねばなりません。共通鍵は引用符で括られた文字列か、16進数字です。つぎの例は、PUT_VPN_SERVER_IP をサーバの IP アドレスに置き換えてください。%any は、あらゆるクライアントセレクタが、指定されている PSK で認証可能であることを意味します。
/etc/ipsec.secretsPUT_VPN_SERVER_IP %any : PSK 0x87839cfdab5f74bc211de156d2902d128bec3243 # もしくは、16進数字の代わりに平文テキストの PSK を使用: # PUT_VPN_SERVER_IP %any : PSK "password_pass"
つぎに /etc/ipsec.conf を下記の通り編集します:
/etc/ipsec.confconn vpnserver
type=transport
authby=secret
pfs=no
rekey=no
keyingtries=1
left=%any
leftprotoport=udp/l2tp
leftid=@vpn.example.com
right=%any
rightprotoport=udp/%any
auto=add
left と right がともに %any に設定されていると、strongSwan は local マシンを left であると認識します。
strongSwan における、証明書方式でのセットアップ
証明書と鍵は適切なディレクトリにコピーされねばなりません:
root #cp ca.crt /etc/ipsec.d/cacerts
root #cp vpn.example.com.crt /etc/ipsec.d/certs
root #cp vpn.example.com.key /etc/ipsec.d/private
root #chown -R ipsec: /etc/ipsec.dstrongSwan に対して、公開鍵を認証に用いるように伝えます:
/etc/ipsec.secrets: RSA vpn.example.com.key
そして、/etc/ipsec.conf を下記の通り更新します:
/etc/ipsec.confconn vpnserver
type=transport
authby=rsasig
pfs=no
rekey=no
keyingtries=1
left=%defaultroute
leftprotoport=udp/l2tp
leftcert=server.crt
leftid=@vpn.example.com
right=%any
rightprotoport=udp/%any
rightrsasigkey=%cert
auto=add
前記と同様で、left と right がともに %any だと、strongSwan は local マシンを left であると認識します。
strongSwan のトラブルシューティング
IPsec パススルー / 壊れた NAT
以前のバージョンの strongSwan では、IPsec パススルーは使えませんでした。「接続不明のため IPsec SA 要求に応答不可能」あるいは（設定ファイルの編集のしすぎで）INVALID_HASH_INFORMATION エラーが起こりました。これは、strongSwan 5.0 以降では起こりません。
IPsec 一般のトラブルシューティング
IPsec は、取扱がそれほど平易ではありません。このセクションでは、一般的に起こる支障やエラーについて指し示しておきます。
NAT 裏のサーバ
サーバが NAT (Network Address Translation)裏にある場合、つまり多くはホームルータの裏にサーバがホスティングされている場合ですが、IPsec 接続を確実に動作させるには、特別な注意点があります。
ポートを開く
2つのポートを開く必要があります:
- UDP ポート 500 (ISAKMP)
- UDP ポート 4500 (NAT トラバーサル)
VPN サーバに転送することも忘れないでください。
さらに、（ポートではなく）以下のインターネットプロトコルを許可する必要があります:
- 50 (ESP)
- 51 (AH)
こうした設定は、ルータがプロトコル別に設定されている（およそスルーでない）際に必要になることがあります。
IPsec パススルー / 壊れた NAT
多くのルータは「IPsec パススルー」の設定が可能ですが、この意味は2種類あります:
- IPsec パケットを、IPsec NAT トラバーサルと異なる手法で加工する
- IPsec パケットを、ルータを通過させ加工しない
(1) は、IPsec パススルーが無効という意味。(2)は、IPsec パススルーが有効という意味です。
残念ながら、ポートフォワーディングを指定したときでさえも IPsec トラフィックをすべて棄て、上記 (1) しか不可能なルータもあります。こうしたルータにはつぎの3つの対処方法があります:
- ファームウェアを更新する。新バージョンでは正しく動作させられる
- ルータの設計についてバグ・欠陥報告を出す（サポート終了していなければ）
- 別のルータを求めましょう。Linksys や D-link のルータは正しく動作するといわれています
このチュートリアルははじめ、そのようなルータ (Zyxel P-330W) のために書かれました。- そして (3) の選択肢しかありません。
Windows Vista/Server 2008 クライアント
こういう OS は NAT 裏の IPsec/L2TP サーバには自動的に対応しないのです。KB926179 を参照のうえ、レジストリを編集して対応させてください。
事前共有鍵 (PSK) の限界
IPsec プロトコルにおいて、PSK をやりとりする手段はありません。通信元と通信先の IP アドレスに基づいてどの鍵を選ぶかという情報が得られるのみです。多くの状況では、応答者は要求者の IP アドレスをあらかじめ知り得ないため、誰もが同じ事前共有鍵を使用するほかありません。よって、単一の接続しかない場合でさえも、事前共有鍵(PSK)方式よりも証明書(PKI)方式が推奨されます。しかし、証明書や PKI（公開鍵インフラストラクチャ）を作成するのは比較的複雑な作業ですので、この記事の対応範囲外です。
L2TP
2つ目の層である、第2層トンネリングプロトコル(L2TP)は、セットアップがずっと容易です。L2TP は IPsec と同様にピアツーピア（2端点間）プロトコルです。クライアント側は「L2TP アクセス集線装置」(L2TP Acccess Concentrator) すなわち LAC と呼ばれ、サーバ側は「L2TP ネットワークサーバ」(L2TP Network Server) すなわち LNS と呼ばれます。
L2TP はまったく秘匿されていませんから、IPsec 接続の外ではアクセス可能にすべきではありません
iptables を使っているならば、IPsec レイヤ外の L2TP 接続をブロックするつぎのようなルールを用いましょう:
root #iptables -t filter -A INPUT -p udp -m policy --dir in --pol ipsec -m udp --dport l2tp -j ACCEPT
root #iptables -t filter -A INPUT -p udp -m udp --dport l2tp -j REJECT --reject-with icmp-port-unreachable
root #iptables -t filter -A OUTPUT -p udp -m policy --dir out --pol ipsec -m udp --sport l2tp -j ACCEPT
root #iptables -t filter -A OUTPUT -p udp -m udp --sport l2tp -j REJECT --reject-with icmp-port-unreachable
ローカルのファイアウォールが ufw だったら、ufw に対して、IPsec の認証に必要な ESP プロトコルの接続を双方向に許可し、IPsec 層以外の L2TP 接続をブロックしましょう。以下のようなファイルを用いて実現可能です:
/etc/ufw/before.rules# IPsec を通してのみ L2TP を許可 -A ufw-before-input -m policy --dir in --pol ipsec -p udp --dport l2tp -j ACCEPT -A ufw-before-input -p udp -m udp --dport l2tp -j REJECT --reject-with icmp-port-unreachable -A ufw-before-output -m policy --dir out --pol ipsec -p udp --sport l2tp -j ACCEPT -A ufw-before-output -p udp -m udp --sport l2tp -j REJECT --reject-with icmp-port-unreachable # IPsec の認証に ESP プロトコルを用いる -A ufw-before-input -p esp -j ACCEPT -A ufw-before-output -p esp -j ACCEPT
xl2tpd を用いる
ほかの L2TP サーバと異なり、xl2tpd は、DHCP や RADIUS のサーバを用いなくとも、IP アドレスプールの管理が可能です。こうした機能はネットワーク階層構造を逸脱していますが、簡易なセットアップ時には極めて便利です:
/etc/xl2tpd/xl2tpd.conf[global] port = 1701 access control = no [lns default] ip range = 172.21.118.2-172.21.118.254 local ip = 172.21.118.1 require authentication = yes name = LinuxVPN pppoptfile = /etc/ppp/options.xl2tpd
他方で RADIUS や DHCP のサーバを用いるならば、ip range と local ip の箇所は空欄にしてください。もしも接続が不安定ならば、lns default のセクションに length bit = yes を追加してみてください。もしも PPP 認証を行わないのであれば、require authentication = yes を refuse authentication = yes に変更しましょう。
オプション用のファイルもつくります:
/etc/ppp/options.xl2tpdnoccp auth crtscts mtu 1410 mru 1410 nodefaultroute lock proxyarp silent
rp-l2tp を用いる
rp-l2tp の設定は簡素です:
/etc/rp-l2tp/rp-l2tpd.conf# グローバルモード（デフォルト） global # ハンドラのロード load-handler "sync-pppd.so" load-handler "cmd.so" # アドレスのバインド listen-port 1701 section peer peer 0.0.0.0 mask 0 lns-handler sync-pppd lns-pppd-opts "noccp auth crtscts mtu 1410 mru 1410 nodefaultroute lock proxyarp silent"
lns-pppd-opts と、サーバの IP アドレスを指定します。また、pppd のセットアップの際に、DHCP か RADIUS を通じて IP アドレスプールを利用させることも忘れずに。
PPP
最後の層は、ポイント・トゥ・ポイント プロトコル(PPP)層です。インストールすべきパッケージは net-dialup/pptpd です。
root #emerge --ask net-dialup/pptpd認証
PPP は認証に用いられます。PSK 認証による証明書と異なり、PPP 層は、エンドユーザが VPN にアクセスするのに必要な認証や権限付与のためにより多くのことを要します。
無認証
最も容易な pppd のセットアップ方法は、無認証にすることです。そのためには、"noauth" を指定せねばなりません。無認証はテスト運用には至便ですが、それ以外の状況では奨められません。とりわけ、PSK 方式を利用しているときにはそうです。PKI 方式のときにはこのような設定が妥当なこともあります、例えば、
- 全てのクライアントマシンが信頼可能で制御下にある
- 全てのユーザが信頼可能で、鍵がユーザ自身以外のマシン上のどのユーザにもアクセス不可能である
- 全ての接続が無人処理である（複数のサイトに接続する手法として用いている）
chap.secrets を通じた認証
小規模のユーザ（典型的には、ホームネットワークから外部に接続したいような状況）には、chap.secrets ファイルを用いた認証で達せられます:
/etc/ppp/chap-secrets# CHAP を用いた認証 # クライアント サーバ 合言葉 IP アドレス avatar * unontanium *
ドメインで認証を行うときには、クライアント名は適切に切り出されていなければなりません。たとえばこの場合は
EXAMPLE\\avatar/etc/ppp/chap-secrets 内のパスワードは暗号化されていませんから、root のみ読み書き可能な属性にしなければなりません
Samba を通じた認証
マシンが MS ドメインや AD（アクティブディレクトリ）フォレストの一部である（あるいはこれらをホスティングしている）のならば、クライアントは winbind を用いることも可能です。つまり、Samba を認証に用いることが可能です。plugin winbind.so を ppp オプションに追加しましょう。なお、そのための Samba と pppd のセットアップに関しては、この記事の対応範囲外です。
RADIUS を通じた認証
RADIUS サーバが同じマシンで稼働しているならば、pppd は RADIUS を利用可能です。radius USE フラグを有効にして net-dialup/ppp をインストールしましょう。PPP オプションに plugin radius.so を追加します。なお、RADIUS と pppd のセットアップに関しては、この記事の対応範囲外です。
EAP-TLS を通じた認証
（マシンにではなく）ユーザ個人が証明書を保有していたら、pppd の認証に EAP-TLS を用いることも可能です。ユーザ認証が、スマートカードや RSA secureID で可能な場合には奨められます。eap-tls USE フラグを有効にして net-dialup/ppp をインストールしてください。RADIUS のセットアップも要します（上述）。require-eap も、PPP のオプションファイルに追加する必要があるかもしれません。このような pppd のセットアップ方法に関しては、この記事の対応範囲外です。
クライアントに関するトラブルシューティング
Windows: 証明書の適切なインストール (PKI の場合)
証明書は PKCS12 にパッケージングされていなければなりません。この処理は openssl か gnutls で行えます:
user $openssl pkcs12 -export -certfile ca.crt -inkey client.example.com.key -in client.example.com.crt -out client.example.p12user $certtool --load-ca-certificate ca.crt --load-certificate client.example.com.crt --load-privkey client.example.com.key --to-p12 --outfile client.example.com.p12Once a .p12 file is created, import it into Windows. However, the method is not obvious. Do not double-click the key and follow the instructions, that won't work. That imports the key into a personal certificate store, but in Windows, it is the local computer that needs to do the authentication, so the certificate needs to be added to the local computer's key store. To do that, use the Microsoft Management Console (mmc). Administrator privileges are needed for this to work.
Start -> Run -> mmc File -> Add/Remove Snap-in -> Certificates -> Add Computer Account -> Local Computer -> Finish -> OK.
Expand the Certificates. Choose any folder (doesn't matter which), right-click, choose "All Tasks", then "Import". Only now follow the wizard, but on the last step, make sure to choose "Automatically select the certificate store based on the type of certificate".
Windows: RAS ネットワーキングエラー
Error 766: A certificate could not be found
If this error occurs, then this means the certificate was not imported correctly. Make sure to import it though MMC, and not by double-clicking the file.
Error 810: VPN connection not complete
When using ipsec-tools (racoon) the following message might occur in the system log:
ERROR: ignore information because ISAKMP-SAhas not been established yet.
This means the certificate was not imported correctly, or the p12 bundle is missing in the CA certificate. Make sure to import the key through MMC, and make sure to select "Automatically select the certificate store based on the type of certificate" at the end of the import process.
XP SP2 and above: Error 809: Server not responding (Server behind NAT)
Windows XP SP2 and Vista not, by default, connect to server behind a NAT. A registry hack is required. Separate fixes are required for Windows XP and Windows Vista.
Vista: Error 835 Could not authenticate
This one occurs only when using PKI. It means the subjectAltName does not match the server that the client is connecting to. This often occurs when using dynamic DNS - the certificate has the internal name rather than the external name. Either add the external name to the certificate, or disable "Verify the Name and Usage attributes of the server's certificate" in the connection definition, under Security -> Networking -> IPsec.
Error 741: The local computer does not support required encryption type
Windows will try to negotiate MPPE, a (weak) encryption. When
- the system is not using PPP authentication, or
- the system does not have a pppd with MPPE support, or
- MPPE is supported but not compiled into the kernel (or a module)
then this error occurs.
If PPP authentication is used, it is recommended to fix the pppd or kernel (which are minimal configuration changes) even though there's no point to have double encryption. If the system does not use PPP authentication, or the double encryption is definitely not wanted, then disable it by unchecking "Require data encryption" on the Security tab.
The connection is still protected by IPsec encryption either way, this just disable the requirement for MPPE.
Mac OS X
Mac OS X clients appear to be picky on the proposals they will negotiate with. In particular:
- dh_group must be
modp1024. - my_identifier must be an address, not a fully qualified domain name (address is the default, so just leave that line out from racoon.conf).
Mac OS X won't connect if subjectAltName does not match the server the client is connecting to. Unlike Vista this check cannot be disabled.
Also, Mac OS X won't connect if the server certificate contains any "Extended Key Usage" (EKU) fields (except for the deprecated ikeIntermediate one). In particular, when using certificates from the OpenVPN easy-rsa utility, it adds the "TLS WWW Server" or "TLS WWW Client" EKU, so such certificates will not work. However, such certificates can still be used on the Mac OS X client, as it doesn't care what is on the client certificate - only the server.
外部の情報
- a Linux L2TP/IPsec VPN server Jacco de Leeuw による記事