mpd.links
pptp2:
set link type pptp
set pptp mode passive
set pptp enable incoming
set pptp disable originate
pptp3:
set link type pptp
set pptp mode passive
set pptp enable incoming
set pptp disable originate
mpd.conf
pptp2:
new -i ng2 pptp2 pptp2
set ipcp ranges サーバの社内側IP/32 クライアント側IP1/32
load pptp_standard
pptp3:
new -i ng3 pptp3 pptp3
set ipcp ranges サーバの社内側IP/32 クライアント側IP2/32
load pptp_standard
pptp_standard:
set iface disable on-demand
set iface enable proxy-arp
set iface idle 600
set bundle no multilink
set link yes acfcomp protocomp
set link no pap chap
set link enable pap
set link enable chap
set link mtu 1280
set link mru 1280
set link keep-alive 10 60
set ipcp yes vjcomp
set ipcp dns 社内DNSサーバのIP
set ipcp nbns 社内WINSサーバのIP
set bundle enable compression
set bundle yes crypt-reqd
set ccp yes mppc
set ccp no mpp-compress
set ccp yes mpp-e128
set ccp yes mpp-stateless
ハマリポイントは複数の暗号化方式を要求すると失敗するというところ。
接続に失敗していた時に syslogでdaemon facilityのログを取るようにして調査すると、 CHAPはSUCCESSで通過しているのが確認でき、 CCPやIPCP関係でnakやらrejをくらっていたので、そのへんに焦点を絞って調べを進めた。 最終的な解決にはFreeBSD-users のメールが参考になった。
昨日のサイトの例だと mpp-e40 と mpp-e128 がyesで並んでいるのはマズい感じなんだけど、 どうなんだろうか。 別の例 では mpp-e40 と mpp-e128 をaccept(=受け入れるけど要求はしない)で記述してある。
ちなみにPPP的にはCCP:圧縮レイヤーで暗号化をしているけど、 それとは別にEncryption Layerがあって全然関係ないのがまぎらわしい。