[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem changing target interface with reply-to



Hi Daniel,
The problem of how to set absolute limits on recursion aside:
The change that was made to address PR3736 significantly alters the
behaviour of reply-to and dup-to, in that it makes them unable to
move/copy a packet onto another interface.  I tried -current as suggested,
however it appears no different in this respect to 3.5-stable
The path for dup-to now can no longer duplicate a mbuf onto another
interface, as pf_route tags with PACKET_TAG_PF_ROUTED and then immediately
returns without sending the duplicate.  Similarly, the path for reply-to
breaks when the target interface is changed from the default, as the mbuf
got tagged when we tried to send the packet out the first interface and
recursively called ourself when the packet was forwarded on the second
interface.
At http://www.itee.uq.edu.au/~chrisp/OpenBSD/pf.c-noloop.diff is a patch
that makes pf_route behave like pre PR3736-patch for non-recursive rules
(one interface change permitted per packet), and like post PR3736-patch
(drop packet on recursive rules) for recursive rules.
I've been using this locally now on our production firewall for 48 hours,
so it's been tested with all the paths I regularly use and a bunch of
imaginery examples that broke with the patch.  I've also removed
recursivity checks from gif, created some deliberately recursive rules,
and confirmed that it breaks the recursion in this case.
I'd appreciate any comments/testing anyone else using dup-to/reply-to can
do, so that the cross-interface functionality can be restored to the main
trees.
Regards,
Chris
P.S. As an aside, in 3.5 release (at least) the "pass out route-to lo0"
case is non-recursive, so the rule generated in PF3736 should not have
caused any stack overflows.  For the loopback interface, we reenqueue the
packet for lo0 to receive return from pf_test - the packet is received
later on by the next ipintr() and we are protected from being called again
before we have returned by splsoftnet().  However, problems did exist with
"pass in on lo0 fastroute" and would do with route-to on any encapsulation
interface that didn't perform its own recursivity tests.
-- 
Christopher Pascoe
IT Infrastructure Manager
School of Information Technology and Electrical Engineering
The University of Queensland   Brisbane  QLD  4072  Australia
Web: http://www.itee.uq.edu.au/~chrisp      Email: [email protected]