hello,
</snip>
>
> > +pf_route(struct pf_pdesc *pd, struct pf_state *s)
> ...
> > + if (pd->dir == PF_IN) {
> > if (pf_test(AF_INET, PF_OUT, ifp, &m0) != PF_PASS)
>
> Yes, this is the correct logic. When the packet comes in, pf
> overrides forwarding, tests the out rules, and sends it. For
> outgoing packets on out route-to rules we have already tested the
> rules. It also works for reply-to the other way around.
the change above changes the behavior from 'do pf_test() when packet
crosses interface' to 'call pf_test() at most two times'. the change
essentially breaks the behavior I've mentioned earlier.
table <hops> { 10.10.10.10, 172.16.1.1 }
pass out on em0 from 192.168.1.0/24 to any route-to <hops>
pass out on em1 from 192.168.1.0 to any nat-to (em1)
pass out on em2 all
the story goes as follows:
destination/next-hop 10.10.10.10 is reached via em1
destination/next-hop 172.16.1.1 is reached via em2
for arbitrary reason we have to do NAT on em1 interface.
with current PF things do work. trading current 'if (...)'
for 'if (pd->dir == PF_IN)' breaks it. The NAT won't happen.
I think this can be solved by using 'match ... route-to ...' rule suggested by
David. However... I actually start to wonder does it hurt us to keep current
behavior? Why do we want to change it? I'm getting worried this particular
tid-bit will bring more harm than good. It also does not help much pfsync(4),
if I understand things right.
>
> But what about dup-to? The packet is duplicated for both directions.
> I guess the main use case for dup-to is implementing a monitor port.
> There you have to pass packets stateless, otherwise it would not
> work anyway. The strange semantics is not related to this diff.
this is a good point.
thanks and
regards
sahan
