Re: RELENG_5 ipfw problem
From: Andre Oppermann (andre_at_freebsd.org)
Date: 08/30/04
- Previous message: David Wolfskill: "Re: suggestion for /usr/src/UPDATING"
- In reply to: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Next in thread: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Reply: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 30 Aug 2004 17:58:07 +0200 To: Oliver Brandmueller <ob@e-Gitt.NET>
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;
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: David Wolfskill: "Re: suggestion for /usr/src/UPDATING"
- In reply to: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Next in thread: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Reply: Oliver Brandmueller: "Re: RELENG_5 ipfw problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
