Re: [External] : pf route-to: only run pf_test when packets enter and leave the stack
Hello, > pass in on em0 from v.x.y.z/n to a.b.c.d/m \ > route-to o.p.q.r nat-to (em2) > > > then this needs to be converted to two rules: > > > > match in on em0 from v.x.y.z/n to a.b.c.d/m nat-to(em2) > > pass in on em0 from v.x.y.z/n to a.b.c.d/m route-to o.p.q.r > > > > I have not tried that yet. However I think this should work. If it does > > not work, then I'll try to fix it. > > I thought the problem was for rules like this: > > pass out on em1 from v.x.y.z/n to a.b.c.d/m \ > route-to o.p.q.r@em2 > pass out on em2 nat-to (em2) > correct, combination of NAT and route-to is problem on outbound rules. I failed to type my example right. > Only one pass out rule will win if I commit this, because the packet > will only go through the ruleset when it leaves the stack, not every > time the interface changes. If we can do match route-to rules, we could > do the following: > > match out on em1 from v.x.y.z/n to a.b.c.d/m \ > route-to o.p.q.r # o.p.q.r is reachable via em2 > pass out on em2 nat-to (em2) > my idea is to fix combined outbound rule with pair of rules. So let me retry. Let there be an outbound rule: pass out on em1 from v.x.y.z/n to a.b.c.d/m \ route-to o.p.q.r@em2 nat-to(em2) the 'route-to o.p.q.r@em2' will get changed to 'route-to o.p.q.r', assuming the o.p.q.r is reachable via em2. The nat-to action will be moved to 'match rule'. The rule above needs to be changed to pair of rules: match out on em1 from v.x.y.z/n to a.b.c.d/m nat-to(em2) pass out on em1 from v.x.y.z/n to a.b.c.d/m \ route-to o.p.q.r # o.p.q.r is reachable via em2 I believe this is something what should work already. thanks and regards sashan
Re: [External] : pf route-to: only run pf_test when packets enter and leave the stack
On Tue, Feb 02, 2021 at 11:30:12AM +0100, Alexandr Nedvedicky wrote: > Hello, > > > On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote: > > > > however, like most things relating to route-to/reply-to/dup-to, im > > pretty sure at this point it's not used a lot, so the impact is minimal. > > a lot of changes in this space have already been made, so adding another > > simplification is justifiable. if this does remove functionality that > > people need, i believe sashan@ has agreed to help me implement route-to > > on match rules to give more flexibility and composability of rules. > > > > as David says my concern is single corner case, which combines > NAT with route-to action. I think the escape plan for people, > who combine route-to with nat-to, is already there. If someone > has rule as follows: > > pass in on em0 from v.x.y.z/n to a.b.c.d/m \ > route-to o.p.q.r@em2 nat-to(em2) You can nat-to and route-to on the same rule, so this should still work if all you do is drop the @em2: pass in on em0 from v.x.y.z/n to a.b.c.d/m \ route-to o.p.q.r nat-to (em2) > then this needs to be converted to two rules: > > match in on em0 from v.x.y.z/n to a.b.c.d/m nat-to(em2) > pass in on em0 from v.x.y.z/n to a.b.c.d/m route-to o.p.q.r > > I have not tried that yet. However I think this should work. If it does > not work, then I'll try to fix it. I thought the problem was for rules like this: pass out on em1 from v.x.y.z/n to a.b.c.d/m \ route-to o.p.q.r@em2 pass out on em2 nat-to (em2) Only one pass out rule will win if I commit this, because the packet will only go through the ruleset when it leaves the stack, not every time the interface changes. If we can do match route-to rules, we could do the following: match out on em1 from v.x.y.z/n to a.b.c.d/m \ route-to o.p.q.r # o.p.q.r is reachable via em2 pass out on em2 nat-to (em2) > > i've canvassed a few people, and their responses have varied from "i > > don't care, route-to is the worst" to "i thought we did option 2 > > anyway". anyone else want to chime in? > > > > this keeps the behaviour where route-to on a packet coming into the > > stack is pushed past it and immediately forwarded to the output > > interface. the condition for that is greatly simplified now though. > > > > ok? > > given there is an escape plan, I'm fine with the change. Thank you.
Re: [External] : pf route-to: only run pf_test when packets enter and leave the stack
Hello,
On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote:
>
> however, like most things relating to route-to/reply-to/dup-to, im
> pretty sure at this point it's not used a lot, so the impact is minimal.
> a lot of changes in this space have already been made, so adding another
> simplification is justifiable. if this does remove functionality that
> people need, i believe sashan@ has agreed to help me implement route-to
> on match rules to give more flexibility and composability of rules.
>
as David says my concern is single corner case, which combines
NAT with route-to action. I think the escape plan for people,
who combine route-to with nat-to, is already there. If someone
has rule as follows:
pass in on em0 from v.x.y.z/n to a.b.c.d/m \
route-to o.p.q.r@em2 nat-to(em2)
then this needs to be converted to two rules:
match in on em0 from v.x.y.z/n to a.b.c.d/m nat-to(em2)
pass in on em0 from v.x.y.z/n to a.b.c.d/m route-to o.p.q.r
I have not tried that yet. However I think this should work. If it does
not work, then I'll try to fix it.
> i've canvassed a few people, and their responses have varied from "i
> don't care, route-to is the worst" to "i thought we did option 2
> anyway". anyone else want to chime in?
>
> this keeps the behaviour where route-to on a packet coming into the
> stack is pushed past it and immediately forwarded to the output
> interface. the condition for that is greatly simplified now though.
>
> ok?
given there is an escape plan, I'm fine with the change.
OK sashan
>
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1106
> diff -u -p -r1.1106 pf.c
> --- pf.c 1 Feb 2021 00:31:05 - 1.1106
> +++ pf.c 2 Feb 2021 03:44:51 -
> @@ -6033,7 +6033,7 @@ pf_route(struct pf_pdesc *pd, struct pf_
> (ifp->if_flags & IFF_LOOPBACK) == 0)
> ip->ip_src = ifatoia(rt->rt_ifa)->ia_addr.sin_addr;
>
> - if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
> + if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
> if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
> goto bad;
> else if (m0 == NULL)
> @@ -6178,7 +6178,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
> (ifp->if_flags & IFF_LOOPBACK) == 0)
> ip6->ip6_src = ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
>
> - if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
> + if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
> if (pf_test(AF_INET6, PF_OUT, ifp, ) != PF_PASS)
> goto bad;
> else if (m0 == NULL)
>
>
