Date: Mon, 24 Sep 2001 09:17:35 -0800 From: "Lars Eggert" <larse@ISI.EDU> To: "Brian Somers" <brian@freebsd-services.com> Cc: <net@FreeBSD.ORG>, <archie@FreeBSD.ORG> Subject: Solution (RE: VPN client with mpd) Message-ID: <PCELJJEJJMODEMKEBLLBIEDHCAAA.larse@isi.edu> In-Reply-To: <200109222035.f8MKZkR34433@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California [-- Attachment #2 --] 0 *H 01 0 + 0 *H 00 G0 *H 01 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.300 010824164000Z 020824164000Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 |\Pw v~~ FDooӦA\- Cˀ4.)&{肋 ,z (ܷر߈T7_'txGH^tt/ҹB8%t<#ֲN V0T0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 *H aJPMՒ ]cѭC+kS+wZ1gY",YT41 j 6:~℩ D~Kؚl=u(ՎM?cF7@}T0)0 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 000830000000Z 020829235959Z01 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.3000 *H 0 32c %E>nx'gڈD)c5*mp<ܮto034qmOe KaU5u'rװ |CBPQ<9TIf - ki N0L0)U "0 0 10UPrivateLabel1-2970U 0 0 U 0 *H so&e4KYbDI j&*b ct mSK8P:l4撜n# KrgPo.X PW Ո9[9}4%MjÑ/<RbH10001 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.30G0 + e0 *H 1 *H 0 *H 1 010924171735Z0# *H 1ʏ@" vdy0X *H 1K0I0 *H 0*H 0+0 *H (0+0 *H 0 +71001 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.30G0 *H 3p[m g Wv/ wU,*5G$ޚ{2ߪMd/P5 P ָ@PE2$/1uyD$FѥjL¶ a D31<Q
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?PCELJJEJJMODEMKEBLLBIEDHCAAA.larse>