From owner-freebsd-bugs@FreeBSD.ORG Mon Aug 18 22:01:58 2008 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4D3106567E for ; Mon, 18 Aug 2008 22:01:58 +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 E03378FC15 for ; Mon, 18 Aug 2008 22:01:57 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from 41-195-81-47.access.uunet.co.za ([41.195.81.47] helo=lap-todor.subnet.co.za) by smtp.uunet.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1KVCW2-000Okq-Uj for freebsd-bugs@freebsd.org; Mon, 18 Aug 2008 23:43:55 +0200 Message-ID: <48A9ED16.2060201@za.verizonbusiness.com> Date: Mon, 18 Aug 2008 23:43:50 +0200 From: Todor Genov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-bugs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Possible bug - GRE tunnel routing X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 22:01:58 -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 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 194.31.137.64 194.31.137.70 UH 1 0 tun1 194.31.154.148 194.31.137.64 UGS 0 0 tun1 If I change the host route 194.31.154.148 194.31.137.64 UGS 0 0 tun1 to a subnet route 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 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