On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote: > Hi, > > Some personal thoughts. I am happy when pf route-to gets simpler. > Especially I have never understood what this address@interface > syntax is used for.
even after staring at it for so long, i still don't get it. i do think it was a reimplementation of an ipfilter thing, but i don't think it makes a lot of sense in ipfilter either. > I cannot estimate what configuration is used by our cutomers in > many installations. Simple syntax change address@interface -> > address of next hob should be no problem. Slight semantic changes > have to be dealt with. Current packet flow is complicated and may > be inspired by old NAT behavior. As long it becomes more sane and > easier to understand, we should change it. route-to $destination, not $next_hop... the biggest change we have to agree on at the moment is whether we're changing the semantic of "pf runs when a packet goes over an interface" to "pf runs when a packet goes in or out of the stack". this affects whether pf_test runs again when route-to changes the interface. > But I don't like artificial restrictions. We don't know all use > cases. reply-to and route-to could be used for both in and out > rules. I have used them for strange divert-to on bridge setups. > It should stay that way. i don't think it's complicated to support route-to and reply-to on both in and out rules. we've already found that there's use cases for reply-to on inbound rules, doing things on bridges just adds to that. it could be used on tpmr(4) too... > It would be nice to keep state-less route-to. I have found a special > case with that in the code of our product. But it looks like dead > code, so I would not object to remove state-less route-to for now. ok. thank you. > bluhm
