From owner-freebsd-net@FreeBSD.ORG Fri Jan 30 00:25:36 2009 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 E97C6106566C for ; Fri, 30 Jan 2009 00:25:36 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id AE3998FC1A for ; Fri, 30 Jan 2009 00:25:36 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 89899 invoked by uid 89); 30 Jan 2009 00:40:34 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 30 Jan 2009 00:40:34 -0000 Message-ID: <498248F6.2080806@ibctech.ca> Date: Thu, 29 Jan 2009 19:25:26 -0500 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Certain traffic not being routed as expected 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: Fri, 30 Jan 2009 00:25:37 -0000 Hi everyone, I have a strange issue, and am hoping that I am just missing something simple. I apologize for the length, but I'm at a complete loss. I learn the IPv4 BOGON from Cymru via BGP, and here is one route currently in my routing table: 192.168.0.0/16 192.168.222.1 UG1 0 408084 disc0 I've been trying to clean up certain leaky private IP space, so to find out if things are being dropped accordingly on the router, I implemented a few counts in IPFW. For the most part, they work ok: Jan 29 18:59:35 lanx kernel: ipfw: 30 Count UDP 208.70.107.130:138 10.0.3.12:138 in via em6 Jan 29 18:59:35 lanx kernel: ipfw: 32 Count UDP 208.70.107.130:138 10.0.3.12:138 out via disc0 However, I have a couple of stubborn prefixes that march their way right through (in one physical interface, and out another): Jan 29 18:59:59 lanx kernel: ipfw: 34 Count TCP 192.168.100.21:3720 208.70.106.58:25 in via em0 Jan 29 18:59:59 lanx kernel: ipfw: 36 Count TCP 192.168.100.21:3720 208.70.106.58:25 out via em4 I can verify that the space is routed properly (via Quagga): lanx# sh ip route 192.168.100.21 Routing entry for 192.168.0.0/16 Known via "bgp", distance 20, metric 0, best Last update 01w3d10h ago * 192.168.222.1, via disc0 ...and if I ping it from my workstation (NAT'd via office gateway, attached to em1 on the router), it is null-routed properly: C:\Documents and Settings\steve>ping 192.168.100.21 Pinging 192.168.100.21 with 32 bytes of data: Control-C ^C Jan 29 19:19:17 lanx-eagle-noc kernel: ipfw: 30 Count ICMP:8.0 208.70.104.100 192.168.100.21 in via em1 Jan 29 19:19:17 lanx-eagle-noc kernel: ipfw: 32 Count ICMP:8.0 208.70.104.100 192.168.100.21 out via disc0 Does anyone have any idea why certain packets with private IP space are not being routed to null correctly? Could this be some form of evasive technique to avoid hitting the kernel route? Steve