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. Maybe 2 has less impact for the users and is easy to understand. We should document that in the man page. > > We are reaching a state where this diff can go in. I just startet > > a regress run with it. OK bluhm@ > > hopefully i fixed the pfctl error messages up so the regress tests arent > too unhappy. pf forward and pf fragment tests pass. They include route-to and reply-to rules. I have no test for dup-to. Regress pfctl fails, but I think dlg@ has a diff for that. bluhm