Date: Mon, 30 Aug 2004 17:58:07 +0200 From: Andre Oppermann <andre@freebsd.org> To: Oliver Brandmueller <ob@e-Gitt.NET> Cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem Message-ID: <41334E8F.377FFD80@freebsd.org> References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> <20040830103216.GA51110@e-Gitt.NET>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mss 1460> > > # 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;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41334E8F.377FFD80>