From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 21:04:31 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 E5DB137B401 for ; Fri, 18 Apr 2003 21:04:30 -0700 (PDT) Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E35843FE3 for ; Fri, 18 Apr 2003 21:04:30 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: from chrisy by vorbis.noc.easynet.net with local (Exim 4.10) id 196jaU-000Dd9-00; Sat, 19 Apr 2003 05:04:26 +0100 Date: Sat, 19 Apr 2003 05:04:26 +0100 From: Chris Luke To: Brett Glass Message-ID: <20030419040426.GA36720@flirble.org> Mail-Followup-To: Chris Luke , Brett Glass , Chris Luke , Sten Daniel =?unknown-8bit?Q?S=F8rsdal?= , freebsd-net@freebsd.org References: <4.3.2.7.2.20030418111623.02819bd0@localhost> <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal.net> <4.3.2.7.2.20030418111623.02819bd0@localhost> <4.3.2.7.2.20030418163428.02bf6480@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030418163428.02bf6480@localhost> User-Agent: Mutt/1.4i Organization: The Flirble Organisation X-URL: http://www.flirble.org/ X-FTP: ftp://ftp.flirble.org/ Sender: Chris Luke cc: freebsd-net@freebsd.org cc: Chris Luke 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: Sat, 19 Apr 2003 04:04:31 -0000 Brett Glass wrote (on Apr 18): > Even assuming that you don't need ARP (and SOMEONE has to do > ARP if you're going to get to other addresses on the LAN you're > tunneling into), there are many applications that do need > to send out a broadcast. HP JetDirect and LapLink are two which > I know these folks to be using. The broadcast address should > be the correct one for the LAN into which you're tunneling, or > these products won't work. You only use ARP if there's an ethernet physically on your end, or some other layer 2 media that needs it (ATM LANE has an equivalent, for instance). If you have a /24 of a remote LAN (or whatever) via the tunnel, your machine needs no ARP to find out what it already knows - it already has a route and there's no media-specific addressing required. Tunnels generally have only two ends. This end and the other. Since you know which layer 3 addresses exist at this end, all others within any subnet masks at this end must exist at the other. Any data to the last adddress in the subnet (often known as the broadcast address) will either get dropped (as is the way with older IP implementations, or sometimes done deliberately if the source address is outside the subnet range, to avoid DoS attacks - "directed broadcast" in Cisco terms) or forwarded like traffic to any other address. The far end, however, if it has an ethernet, if configured to, will maintain an entry in its ARP table statically of the PPTP client address that it publishes (ie, responds to queries for) if it's in the same subnet as a lan it's connected to. No ARP on your, the PPTP client, end is required. If you're using IP addresses from a LAN at the far end, the far end does, however, need to proxy-arp those addresses. Whether Windows PPTP forwards addresses to the last address in a subnet, I don't know. It *should* treat it like any other address, and then the machine at the far end should then forward it, and the ethernet interface should then decide it's a broadcast address and forward it to the hard-coded ethernet broadcast address. However, I wouldn't bet on it. If the Windows PPTP client appears to be classfull, then it likely treats the first address (network address) and the last address (broadcast) in any given subnet as special and may do special things with them. YMMV. It was CIDRisaition that removed this special treatment, though in general the world was/is slow to actually adopt this particular facet of the previously mentioned RFCs. As for software that relies on the broadcast domain, there are generally better ways (at least I think so) of organising the network that work better in the long run. Running your jetdirects via a printer queue on some machine - windows or otherwise - is the most obvious, for instance. Chris. -- == chrisy@flirble.org