Hello,
On Tue, Jan 26, 2021 at 12:33:25PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > > 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.
> >
> > are you saying i should skip pf_test for all dup-to generated packets?
>
> I am not sure.
>
> When we have an in dup-to rule, the incoming packets in request
> direction are dupped and tested with the out ruleset. The reply
> packets for this state are also dupped, but not tested when they
> leave the dup interface.
>
> This is inconsistent and cannot work statefully. Stateful filtering
> with dupped packets does not make sense anyway. The only working
> config is "pass out on dup-interface no state".
>
> Do we think this rule should be required?
>
> 1. No packet should leave an interface without a rule.
>
> if (pd->dir == PF_IN || s->rt == PF_DUPTO) {
> if (pf_test(AF_INET, PF_OUT, ifp, &m0) != PF_PASS)
>
> 2. The config says we want a monitor port. We risk that the
> original packet and the dupped packet match the same rule.
> Stateful filtering cannot work, we do not expect reply packets
> for the dups.
>
> if (pd->dir == PF_IN && s->rt != PF_DUPTO) {
> if (pf_test(AF_INET, PF_OUT, ifp, &m0) != PF_PASS)
>
> 3. Some sort of problem was there before, but different. Don't
> address it now.
>
another option would be to mark duped packet as GENERATED
to short circuit pf_test() here:
6871
6872 if ((*m0)->m_pkthdr.pf.flags & PF_TAG_GENERATED)
6873 return (PF_PASS);
6874
perhaps excluding those changes from current diff is good.
this seems to be separate issue anyway.
thanks and
regards
sashan
