Fwd: Fwd: Dual-feed: PF setup troubles

[Sergey Lapin]

---------- Forwarded message ----------
From: Dmitry Andrianov <dimas at dataart.com>
Date: Aug 15, 2005 7:31 PM
Subject: RE: Fwd: Dual-feed: PF setup troubles
To: Sergey Lapin <slapinid at gmail.com>, Max Laier <max at love2party.net>,
Daniel Hartmeier <daniel at benzedrine.cx>


Hi.

> You can try turning of the IFF_SIMPLEX flag on the interface
> (unsure about the entire effects of that), or simply exclude those
> broadcast packets from getting routed by pf (which isn't really
intentional, is it?), like
>
>  -              ... from ... to any ...
>  +              ... from ... to !255.255.255.255 ...

Well, these are not packets to 255.255.255.255 which cause dead box. As
we previously note, ANY packet with broadcast destination MAC and
destination IP outside of directly connected networks does that. Which
means we can not just block it at Layer 3 level - we need some sort of
MAC (Layer 2) filtering which pf does not have (I suppose).

After all, I do not see how this ruleset

pass in quick on $dmz_if route-to ($ext_if1 $ext_gw1) tagged DMZ_TO_EXT1
keep state
pass in quick on $dmz_if route-to ($ext_if2 $ext_gw2) tagged DMZ_TO_EXT2
keep state
pass out quick on $ext_if1 route-to ($ext_if2 $ext_gw2) tagged
DMZ_TO_EXT2 keep state
pass out quick on $ext_if2 route-to ($ext_if1 $ext_gw1) tagged
DMZ_TO_EXT1 keep state

Causes loop. Even if packet re-enters ext_if1 input queue, it should not
be affected by these rules because
1. first two applies only to packets coming to DMZ interfact
2. second two applies only when packet with wrong source is on the
interface output queue...

Regards,
Dmitry Andrianov



-----Original Message-----
From: Sergey Lapin [mailto:slapinid at gmail.com]
Sent: Monday, August 15, 2005 6:51 PM
To: Dmitry Andrianov; Max Laier
Subject: Fwd: Fwd: Dual-feed: PF setup troubles

---------- Forwarded message ----------
From: Daniel Hartmeier <daniel at benzedrine.cx>
Date: Aug 15, 2005 6:34 PM
Subject: Re: Fwd: Dual-feed: PF setup troubles
To: Sergey Lapin <slapinid at gmail.com>
Cc: freebsd-pf at freebsd.org


I suspect the loop occurs through sys/net/if_ethersubr.c ether_output()

        /*
         * If a simplex interface, and the packet is being sent to our
         * Ethernet address or a broadcast address, loopback a copy.
         * XXX To make a simplex device behave exactly like a duplex
         * device, we should copy in the case of sending to our own
         * ethernet address (thus letting the original actually appear
         * on the wire). However, we don't do that here for security
         * reasons and compatibility with the original behavior.
         */
        if ((ifp->if_flags & IFF_SIMPLEX) && (loop_copy != -1)) {
                int csum_flags = 0;

                if (m->m_pkthdr.csum_flags & CSUM_IP)
                        csum_flags |= (CSUM_IP_CHECKED|CSUM_IP_VALID);
                if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA)
                        csum_flags |= (CSUM_DATA_VALID|CSUM_PSEUDO_HDR);

                if ((m->m_flags & M_BCAST) || (loop_copy > 0)) {
                        struct mbuf *n;

                        if ((n = m_copy(m, 0, (int)M_COPYALL)) != NULL)
{
                                n->m_pkthdr.csum_flags |= csum_flags;
                                if (csum_flags & CSUM_DATA_VALID)
                                        n->m_pkthdr.csum_data = 0xffff;
                                (void)if_simloop(ifp, n, dst->sa_family,
hlen);
                        } else
                                ifp->if_iqdrops++;
                } else if (bcmp(eh->ether_dhost, eh->ether_shost,
                                ETHER_ADDR_LEN) == 0) {
                        m->m_pkthdr.csum_flags |= csum_flags;
                        if (csum_flags & CSUM_DATA_VALID)
                                m->m_pkthdr.csum_data = 0xffff;
                        (void) if_simloop(ifp, m, dst->sa_family, hlen);
                        return (0);     /* XXX */
                }
        }

You route-to the broadcast packet, pf will call ether_output() to send
it out through the new interface, and this piece of code in there will
send it right back in through that interface again. If your ruleset then
routes that resent packet again, you get a tight endless loop, locking
up the kernel, like you describe.

OpenBSD doesn't have this piece in ether_output(), I'm not sure in what
cases people want outgoing broadcasts on an interface reflected back at
them by the stack.

You can try turning of the IFF_SIMPLEX flag on the interface (unsure
about the entire effects of that), or simply exclude those broadcast
packets from getting routed by pf (which isn't really intentional, is
it?), like

  -              ... from ... to any ...
  +              ... from ... to !255.255.255.255 ...

Or find the person familiar/responsible for this loop_copy code, and ask
whether we can bypass it, for instance when the PF_ROUTED mbuf tag is
present, or such.

I'm not entirely sure this is the loop, but you can confirm by adding
simple printf()s along that code path, you'll see them printed endlessly
when the lockup occurs.

Daniel