From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 00:58:08 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 24680106564A for ; Tue, 19 Aug 2008 00:58:08 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from smtpout2.uunet.co.za (smtpout2.uunet.co.za [196.7.142.138]) by mx1.freebsd.org (Postfix) with ESMTP id A9FE58FC1A for ; Tue, 19 Aug 2008 00:58:07 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from nop148.nop.jnb6.za.uu.net ([196.30.158.148] helo=lap-todor.subnet.co.za) by smtp.uunet.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1KVFXx-00098n-OD for freebsd-net@freebsd.org; Tue, 19 Aug 2008 02:58:05 +0200 Message-ID: <48AA1A9D.2040607@za.verizonbusiness.com> Date: Tue, 19 Aug 2008 02:58:05 +0200 From: Todor Genov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 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 00:58:08 -0000 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 gre0: flags=9051 metric 0 mtu 1476 tunnel inet 194.31.137.70 --> 194.31.154.148 inet 192.168.254.2 --> 192.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 [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. -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543