From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:49:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1572137B401 for ; Thu, 17 Apr 2003 12:49:16 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id A766943FCB for ; Thu, 17 Apr 2003 12:49:14 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 21:49:03 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F1F3CEB@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFDwFyQmbFPzDlQWGFRwWYpT9mbgACsZeA From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:49:16 -0000 > At 12:18 PM 4/17/2003, Sten Daniel S=F8rsdal wrote: >=20 > >This is a known issue with the Microsoft PPTP client. It=20 > adds the natural > >netmask and not the specified one.=20 >=20 > I don't understand. Why is /24 more "natural" than /16? It's how the entire IP block is arranged I assume. I don't know=20 exactly what benefits there are from such a arrangement. >=20 > >In case of 192.168.x.x/16 that is a=20 > >255.255.255.0 netmask and with for example 80.80.80.0/24 is=20 > 80.0.0.0/8. >=20 > Even more confusion. How does it come up with that? IP Baggage from times before subnet masks? >=20 > >The only known workarounds AFAIK are requiring the client to=20 > default route > >Through the tunnel=20 >=20 > Which causes slowdowns and a huge extra drain on the office's > Internet feed Yes, for most configurations this is true. >=20 > >- or - setup a (persistent?) route on the windows box. >=20 > I suppose we could try a script. >=20 > >Say if client gets 192.168.1.2 when client connects, you=20 > need to manually > >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 > >On the windows client before connecting. >=20 > Is there a way to fire off a script automatically after connecting? Persistent routes are routes that are reinstalled during bootup. It will just mark them inactive until needed and deactive when no longer = needed. It's a setup that works. '-p' is the persistent flag. >=20 > >Microsoft doesnt seem to be interested in fixing this=20 > problem as the problem > >persist even on Windows XP and has been known since Windows 98(??).=20 >=20 > Figures. >=20 > --Brett >=20 - Sten