From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 01:50:49 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 A025B1065694 for ; Tue, 19 Aug 2008 01:50:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 843508FC15 for ; Tue, 19 Aug 2008 01:50:49 +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 242692374; Mon, 18 Aug 2008 18:50:49 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0419B2D604B; Mon, 18 Aug 2008 18:50:48 -0700 (PDT) Message-ID: <48AA26FD.20305@elischer.org> Date: Mon, 18 Aug 2008 18:50:53 -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> In-Reply-To: <48AA1A9D.2040607@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 01:50:49 -0000 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 > gre0: flags=9051 metric 0 mtu 1476 > tunnel inet 194.31.137.70 --> 194.31.154.148 > inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00 > > Routing table: > Destination Gateway Flags Refs Use Netif Expire > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > > GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed > via tun0 Why do you think you need -S? routing takes into account only the destination.. > > [root@fw ~]# tcpdump -ni tun0 proto gre > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes > 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP > 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, > length 64 > > > ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is > routed via tun1 > > [root@fw ~]# tcpdump -ni tun1 icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes > 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id > 10757, seq 14, length 64 > 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id > 10757, seq 14, length 64 > > > However, if I add a /24 route for the GRE endpoint subnet, instead of a > /32 to the host: > > 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 > > and then bring up the GRE tunnel, everything works as expected and GRE > traffic exits via tun1. yes.. that is as expected.. > > >