From owner-freebsd-net@FreeBSD.ORG Fri Mar 14 15:31:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4722B3BC for ; Fri, 14 Mar 2014 15:31:53 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E4509C4 for ; Fri, 14 Mar 2014 15:31:53 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i7so2764306oag.23 for ; Fri, 14 Mar 2014 08:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wRp/WUcKzNL/f5mlbZcSOEjjtgkmGnIzkyncqu3mrLI=; b=CFN8NRzJpbVgqW87nS4yf1WO7ZEqeyOL2TR+rL9ud2R2dSJJsKPqh/FbR7HthbgfB/ 6+ez/uDBSGJc8KbDncXb4tGzHT+tR4iZKMBWi5u6RKZpxBK3RZiFQ4sY6vv0HuBch2xM 1Sjd8xQNpv4eA1IjZHT0wFUvO4rLBl28WArhIsqV7oyKGZLq0R8SVgx94JL/4CiHDBFr QFTm27AF0n1oWEaJFnQ5DAp8+t8Z1rOSqO4lOUMGRh+tenqgOODHl7QFLe1T6XPqKUyg +V6duWzeNiwteRUjCtfhs23p1IvJtWenELejPLX8pbQuWT7MubQysgMaCJVtARaeVdgg iLnA== MIME-Version: 1.0 X-Received: by 10.182.131.170 with SMTP id on10mr7420541obb.2.1394811112376; Fri, 14 Mar 2014 08:31:52 -0700 (PDT) Received: by 10.76.72.5 with HTTP; Fri, 14 Mar 2014 08:31:52 -0700 (PDT) In-Reply-To: <20140307024724.T75313@sola.nimnet.asn.au> References: <531771C8.1040207@yandex.ru> <20140306145231.Q75313@sola.nimnet.asn.au> <20140307024724.T75313@sola.nimnet.asn.au> Date: Fri, 14 Mar 2014 16:31:52 +0100 Message-ID: Subject: Re: ipfw / routing issue on 9.2-RELEASE From: Andreas Nilsson To: Ian Smith , FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Mar 2014 15:31:53 -0000 ... snip ... > Ah. Well it was good to see the rules listed anyway, always helps. > > > Was the count rules something like: > > > > 00001 901 46132 skipto 63000 ip from table(1) to any in recv > > table(8) > > > > ... same as before ... > > > > 63500 895 45844 count log logamount 100 ip from table(1) to > any in > > recv table(8) > > > > 64000 0 0 fwd tablearg ip from table(12) to any > > > > 64500 895 45844 count log logamount 100 ip from table(1) to > any in > > recv table(8) > > 65535 3849164 1234591611 allow ip from any to any > > > > So everything looks nice enough, but still no go. Interestingly enough, > > since this is a production machine I can't fool around to much ( that's > why > > it took a while to get the above results ) I tried to reproduce this on > > another machine. Lo and behold, I couldn't. There it worked with the > > skipto-version. I'll investigate this and see if I can find any > differences. > > I'm wondering what's happening on the outbound path, most of your rules > handle inbound (to kernel) and it seems that rule 65535 deals with most > outbound, except those specifically acting on both paths. > So do I :) > > Maybe try adding to the above: > ipfw add 63510 count log ip from table(1) to any out recv table(8) > and > ipfw add 64510 count log ip from table(1) to any out recv table(8) > > which should catch them on the outbound path before the default rule; > outbound packets have both receive and transmit interfaces available. > > They never get that far :( Those rules log nothing. So I see the packet coming in, triggering the skipto, triggering the count log ... in recv but not the count log ... out. > I guess you're sure that these packets are actually going out to some > external address, not a localhost or alias address (which of course are > received and not sent out anywhere)? > Yes, when the go through they go to external address, which is in the routing table. > > I guess the above new log lines should show the interface (if any) > these packets are leaving on, after routing (maybe a routing issue?) > > Good luck hunting. If in doubt, throw ever more logging at it! :) And > please let the list know if you solve it - or not! > > cheers, Ian > To make it even more interesting, it tested this on another machine, where I'm unable to reproduce this "problem". I'm thinking that a reboot might help, but this is kind of fascinating so I would like to actually find the cause. I will investigate further. Best regards Andreas