Date: Sat, 04 Dec 2004 21:37:35 +0100 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 Message-ID: <41B2200F.FB46E28A@freebsd.org> References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote:
>
> Andre,
>
> what is reason for these two checks in ip_output():
>
> if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) {
> dst = (struct sockaddr_in *)&ro->ro_dst;
> bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in));
> m->m_flags |= M_SKIP_FIREWALL;
> m_tag_delete(m, fwd_tag);
> goto again;
> } else {
> m_tag_delete(m, fwd_tag);
> /* Continue. */
> }
>
> 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.
> P.S. kern/73129, kern/73910, kern/71910
--
Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41B2200F.FB46E28A>