Thanks to Archie and Brian, I now have a working PPTP tunnel up. Here's
what I changed from the example vpn configuration included in the mpd
package in /usr/local/etc/mpd/mpd.conf, I thought I'd document this in
case someone else runs accross the same problem:
1. Remove the "set iface addrs" line, addresses are assigned during
negotiation.
2. Change the "set iface route" to whatever you'd like to route through
the tunnel. I only route everything destined to my work subnet there.
3. Change the "set bundle authname" and "set bundle password" lines.
Obviously.
4. Change "set link yes chap" to "set link allow chap". Both Archie and
Brian suggested this; with the change, mpd will allow negotiation with
remote peers that do not want to CHAP-authenticate themselves (like my
remote VPN servers, it seems).
5. Change the local end range in the "set ipcp ranges" line to 0.0.0.0/0,
to accept any tunnel endpoint address the server assigns us. Change the
server address range to something meaningful (my server picks its virtual
address out of a single class C, for example).
6. Uncomment all the lines below the commment about MPPE encryption.
7. Change the "mpd.links" file to point to the correct remote VPN server.
Bingo! Connection established.
The only remaining problem is that a few RAS servers (e.g., some Cisco box
we're evaluating) seem to propose their own physical address as a virtual
tunnel address. This causes an encapsulation loop resulting in a kernel
panic. The Windows PPTP client avoids this problem; I wonder if a simple
check in mpd that would reject physical addresses proposed as tunnel ends
during negotiation may do the trick? Other servers, however, work fine
with the above configuration.
Thanks again to Brian and Archie,
Lars
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
