From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 05:58:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49A17D33 for ; Tue, 4 Mar 2014 05:58:15 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125422CA for ; Tue, 4 Mar 2014 05:58:15 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so8117958oag.27 for ; Mon, 03 Mar 2014 21:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=olHVIiMI29mXbf6QUVkdERS1H+9Q+NL6Dm/dGJxN0Bw=; b=upjYUqc8yLsv4uiIqN5Uc2hJCs3a1CtCZ5LBNe2sOU1SfLQiZB9PVqqDlwgDifXFQu 5tPU6GBGPjZOdX+1dtYWQbKQtWFcvJOcuz3N7UxpA/7pK3kDkuLTIfT6QJckeuvfs8g+ SBUbvL/kQ7StO4UtDvLYwd48IiyLLti5CVghXZvgiiNuROzqLVHO/wz+Gd9vuwcSF6Bt cdodYCmfcKl3KwAwbVq/ViNQcSujUi+FF+ewcZkBj+TCFdtg9i/GYB0LfRv66Awh8XH6 jhmN63g/XqHXNMnlytH3rtE5T1gYS8LDYZ/qyv/xBY0lHRpr0OGQbuSsQjQoW98Ib9be ZhLg== MIME-Version: 1.0 X-Received: by 10.182.233.228 with SMTP id tz4mr138030obc.56.1393912694377; Mon, 03 Mar 2014 21:58:14 -0800 (PST) Received: by 10.76.144.10 with HTTP; Mon, 3 Mar 2014 21:58:14 -0800 (PST) Date: Tue, 4 Mar 2014 06:58:14 +0100 Message-ID: Subject: ipfw / routing issue on 9.2-RELEASE From: Andreas Nilsson To: 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: Tue, 04 Mar 2014 05:58:15 -0000 Hello, I'm having a strange problem with ipfw and/or routing. I've only tested this on 9.2-RELEASE-p3, amd64. The machine is sort of acting as router. The ruleset is like (ipfw defaults to accept): $cmd="ipfw -fq " $cmd add 1 skipto 65534 log all from "table(1)" to any in recv "table(8)" ... $cmd add 65534 fwd tablearg all from "table(12)" to any Table 1 contains prefixes that should skip the normal rules and just pass through the box. Table 8 contains interface names. Table 12 is empty (so far). What happens is that packets that trigger the first rule never get to their destination. After looking at /var/log/security is see that packets trigger the rule, "never to be seen again". There is a route (ie not default) for the destination, but a tcpdump on the corresponding interface shows nothing. On changing the ruleset to $cmd="ipfw -fq " $cmd add 1 skipto 65533 log all from "table(1)" to any in recv "table(8)" ... $cmd add 65533 fwd x.y.z.w ip from "table(1)" to any in recv "table(8)" $cmd add 65534 fwd tablearg all from "table(12)" to any packets get to where they should. Why do I need the explict fwd rule? As far as I can see the ipfw man page says nothing about skipto changing the packets, and since the 65533 rule in the second ruleset triggers on the same thing as the skipto rule it would seem like packets are "intact". Why does the kernel not forward those packets? Best regards Andreas Nilsson