Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Dec 2004 00:53:52 +0300 (MSK)
From:      Maxim Konovalov <maxim@macomnet.ru>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        net@freebsd.org
Subject:   Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5
Message-ID:  <20041205005101.H44692@mp2.macomnet.net>
In-Reply-To: <41B2200F.FB46E28A@freebsd.org>
References:  <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 4 Dec 2004, 21:37+0100, Andre Oppermann wrote:

[...]
> > Investigating pre-PFIL_HOOKS ipfw I have not found any analog of
> > this check. These checks do break some useful functionality:
> >
> > 1) policy routing of hosts from connected networks
> > 2) policy routing of locally originated traffic
> >
> > The second one is used very widely. When you have lines to two
> > ISPs and run natd for both of them, you policy route nated packets
> > to them.
>
> I know.  On the other hand having these checks avoids breaking responses
> from the host doing the policy routing towards hosts on connected networks.
>
> In my case I had a problem where the MTU of the policy-routing target
> interface was lower than 1500 but the ICMP fragmentation needed packets
> never made it back to the real host; they were forwarded to the policy
> destination.
>
> This is how I came to this check.  It is more correct but indeed breaks
> forwarding packets that were targeted at an IP address configured on a
> local interface.  This is an unintended side effect but I haven't found
> a nice solution to work around that.  I'm not entirely sure what the
> best way is to handle this and it's also the reason why I haven't changed
> it so far.
>
> If you have suggestions I'm all ears.  But think through all cases at least
> twice, there are some nice traps.  Fixing one end without breaking another
> one is hard.

IMHO restoring the historic behaviour (even broken in some respects)
is the best thing we can do at the moment.

> > P.S. kern/73129, kern/73910, kern/71910

-- 
Maxim Konovalov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041205005101.H44692>