From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:58:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 625BD16A4CE for ; Mon, 30 Aug 2004 15:58:03 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98BF543D49 for ; Mon, 30 Aug 2004 15:58:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79364 invoked from network); 30 Aug 2004 15:56:08 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Aug 2004 15:56:08 -0000 Message-ID: <41334E8F.377FFD80@freebsd.org> Date: Mon, 30 Aug 2004 17:58:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Oliver Brandmueller References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> <20040830103216.GA51110@e-Gitt.NET> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 15:58:03 -0000 Oliver Brandmueller wrote: > > Hello. > > On Fri, Aug 27, 2004 at 05:28:07PM +0200, Andre Oppermann wrote: > > It detects a missing dummynet because it has to pass on configuration > > options to dummynet and it can only do that if dummynet is loaded. For > > FORWARD this is not the case. Here the ipfw code just tags the packet > > for later treatment. And that later treatment is scattered through a > > few places where we have to inspect each packet it carries this tag. > > > > >- How to enable it? > > > > Put "option IPFIREWALL_FORWARD" into your kernel configuration file and > > recompile. > > I do now have IPFIREWALL and IPFIREWALL_FORWARD in the kernel and am not > loading it as a module anymore. The dmesg now states: > > ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled > > OK, fine. But do still have a problem: > > The rule is loaded an matched. Instead of just dropping the packet (as > before, when rule based forwarding was disabled) the pakets are now > accepted, but the forwarding does not work: > > 00200 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 > > Is still see this on em0 (the public interface in the destination > network metioned in rule 200): > > 12:26:09.674295 IP 192.168.25.5.smtp > 213.XXX.XXX.XXX.41424: S > 3583621218:3583621218(0) ack 3993419222 win 65535 > > # ipfw show > 00200 2694 118536 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 > > packets are accepted, but not forwarded. Can anyone else reproduce this? Ok, it seems you suffer from a small logic change I made when redoing the ipfw fwd option. This was supposed to prevent foot-shooting but also prevents your setup from working. Try the attached patch (probably white- space mangled). -- Andre Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.229 diff -u -p -r1.229 ip_output.c --- ip_output.c 27 Aug 2004 15:39:34 -0000 1.229 +++ ip_output.c 30 Aug 2004 15:55:42 -0000 @@ -710,7 +710,7 @@ spd_done: /* Or forward to some other address? */ fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); if (fwd_tag) { - if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { + if (!in_localip(ip->ip_src)) { dst = (struct sockaddr_in *)&ro->ro_dst; bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); m->m_flags |= M_SKIP_FIREWALL;