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
This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C144D9.BF7459F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_004D_01C144D9.BF7459F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5jCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwAgMFgUcwCQYFKw4DAhoFAKCCAWUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwOTI0MTcxNzM1WjAjBgkqhkiG9w0BCQQxFgQUyNf6yo++ okC6/ar5IoQgdmR5FocwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZI hvcNAQEBBQAEgYC6lxkzcIcEG4L5W23g/fAdkWeODVehmxN2LwD717/Fd1WuLCo1RyTemnsyEN+q pOAP+RFNlZ9kFfvy4y9QNagaHFAN+QWb1rgRQKrB+b1QRTIk4/LU/8EvDv0xday6eUQkRtGlBGrz TMK2lfsIDWEfqOuCRDOHMeg88QPoUcEb3AAAAAAAAA== ------=_NextPart_000_004D_01C144D9.BF7459F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?PCELJJEJJMODEMKEBLLBIEDHCAAA.larse>