From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:09:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC2551065676 for ; Tue, 19 Aug 2008 18:09:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 22CCC8FC23 for ; Tue, 19 Aug 2008 18:09:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 38FDB2382; Tue, 19 Aug 2008 11:09:26 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B57A12D600D; Tue, 19 Aug 2008 11:09:25 -0700 (PDT) Message-ID: <48AB0C5C.8090404@elischer.org> Date: Tue, 19 Aug 2008 11:09:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Todor Genov References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> In-Reply-To: <48AA88B4.6040606@za.verizonbusiness.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 18:09:27 -0000 Todor Genov wrote: > Hi Julian, > > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi everyone, >>> >>> I may have found a routing bug relating to GRE tunnels. Could somebody >>> try and replicate this? >>> >>> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >>> should be going out via tun1, but a tcpdump shows the traffic leaving >>> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >>> goes out via tun1 as expected. >>> >>> Configuration: >>> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >>> tun0 - PPPoE connection to ISP >>> tun1 - vpn connection to office PIX (via vpnc) >>> gre0 - GRE tunnel to machine sitting behind the PIX >>> >>> tun0: flags=8051 metric 0 mtu 1492 >>> inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 >>> Opened by PID 509 >>> tun1: flags=8051 metric 0 mtu 1500 >>> inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 >>> Opened by PID 984 >> Point to point interfaces really don't have netmasks. >> Otherwise it wouldn't be "Point to Point", it would be >> "multicast" like ethernet. >> >> There is really only one address at this end or the other end. >> If you want to say that there is a network at the other end >> then you really need to set a route for it. >> but it applies equally to all three of these p2p links. >> >> so, add a route: >> >> route add 92.168.254.0/24 92.168.254.1 > > The netmask for tun0 is automatically assigned by the ISP, and for tun1 > by the VPN server. The one for gre0 is a /30 in the connect scripts - I > must have changed it to /24 somewhere along the troubleshooting process > - it makes no difference to the end result. let me rephrase that.. p2p links do not support netmasks. That's all p2p links.. ppp, slip, tun, ng, gre, etc. If you what a virtual ethernet interface you may try tap(4) but you will need to have an appropriatly capable piece of software on the other end of the link. A p2p link doesn't take any notice of what you have written as netmask and it doesn't matter what your ISP has given you, or if you type /24 or /22 or /32. The point to point interface only knows about the ONE SINGLE ADDRESS on the other end of the link. If there is a network there, which that address is a part of, then it is up to YOU to add the route that allows packets to get there. > > The routing table does include routes to the /26 on tun1 and the /24 on > gre0. I have left them out as they are not relevant to the problem. The > troublesome route is the one to 194.31.154.148/32 > > Just noticed that the PtP address for tun1 looks incorrect - with that > netmask into account .64 is the network address. I'll look into that as > a possible cause. the netmask should not be taken into account because it is ignored. >> > > >