From owner-freebsd-bugs@FreeBSD.ORG Wed Sep 1 08:10:16 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4353E16A4CE for ; Wed, 1 Sep 2004 08:10:16 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28B1643D5A for ; Wed, 1 Sep 2004 08:10:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i818AGPK016238 for ; Wed, 1 Sep 2004 08:10:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i818AGBQ016237; Wed, 1 Sep 2004 08:10:16 GMT (envelope-from gnats) Resent-Date: Wed, 1 Sep 2004 08:10:16 GMT Resent-Message-Id: <200409010810.i818AGBQ016237@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Delany Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A69F16A4CE for ; Wed, 1 Sep 2004 08:03:00 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D25443D58 for ; Wed, 1 Sep 2004 08:03:00 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i8182xDm035489 for ; Wed, 1 Sep 2004 08:02:59 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i8182xZh035488; Wed, 1 Sep 2004 08:02:59 GMT (envelope-from nobody) Message-Id: <200409010802.i8182xZh035488@www.freebsd.org> Date: Wed, 1 Sep 2004 08:02:59 GMT From: Mark Delany To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: kern/71230: ipfw fwd on 5.3 always causes EACCES on sendto() - whereas 5.2 worked just fine X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 08:10:16 -0000 >Number: 71230 >Category: kern >Synopsis: ipfw fwd on 5.3 always causes EACCES on sendto() - whereas 5.2 worked just fine >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 01 08:10:15 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Mark Delany >Release: 5.3-BETA2 >Organization: >Environment: reeBSD prefix.emu.st 5.3-BETA2 FreeBSD 5.3-BETA2 #4: Sun Aug 29 08:48:14 PDT 2004 root@prefix.emu.st:/usr/obj/usr/src/sys/prefix-523a i386 >Description: I have a firewall system with two interfaces to the internet via two ISPs. As a kindaof hack I used the ipfw fwd rules to force packets out the interface that matched their source address. In effect over-riding the default route. If interface A: has an address of 1.2.3.4 and a forwarding router of 1.2.3.1 and interface B has an address of 9.8.7.6 with a forwarding router of 9.8.7.1, and interface A has the default route, I created ipfw rules along the lines of: fwd 9.8.7.1 ip from 9.8.7.6 to any via B In effect, intercepting a packet going out the default route and fwding it via the non-default route. Sorry about the vagueness, the actually application is aiming natd at the non-default route. In any event, this crude strategy worked just fine with 5.2, but on upgrading to 5.3, all packets that hit the fwd rule are returning EACCES to the sending process. >How-To-Repeat: On a box with two interfaces, do the following: a) Configure interface A: to 10.0.0.2/24 b) Configure interface B to 10.1.0.2/24 c) Set the default route to be 10.0.0.1, ie, interface A d) ipfw fwd 10.1.0.1 ip from 10.1.0.0/24 to any via A e) Write or run a program that binds to an interface B address and send a packet to some random external address, say, 192.168.0.1 The point about e) is that you are binding to the non-default-route address. The point about d) is that you are catching default-route traffic and forwarding it down another pipe. This represents my scenario, but quite possibly any ipfw fwd rule will produce the same result. Namely that the application that does a sendto() that hits a fwd rule gets EACCES. >Fix: >Release-Note: >Audit-Trail: >Unformatted: