From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 11:27:40 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 E688137B404 for ; Thu, 17 Apr 2003 11:27:40 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE5B643F75 for ; Thu, 17 Apr 2003 11:27:39 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id MAA23532; Thu, 17 Apr 2003 12:27:19 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417122205.02aed700@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 12:27:08 -0600 To: Sten Daniel Sørsdal , From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 18:27:41 -0000 At 12:18 PM 4/17/2003, Sten Daniel Sørsdal wrote: >This is a known issue with the Microsoft PPTP client. It adds the natural >netmask and not the specified one. I don't understand. Why is /24 more "natural" than /16? >In case of 192.168.x.x/16 that is a >255.255.255.0 netmask and with for example 80.80.80.0/24 is 80.0.0.0/8. Even more confusion. How does it come up with that? >The only known workarounds AFAIK are requiring the client to default route >Through the tunnel Which causes slowdowns and a huge extra drain on the office's Internet feed >- or - setup a (persistent?) route on the windows box. I suppose we could try a script. >Say if client gets 192.168.1.2 when client connects, you 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. Is there a way to fire off a script automatically after connecting? >Microsoft doesnt seem to be interested in fixing this problem as the problem >persist even on Windows XP and has been known since Windows 98(??). Figures. --Brett