Amazing answer, thanks Claudio and Sebastian. Will alter my rules accordingly. It all makes sense now that I understand how PF routing/filtering works under the hood, at least in principle.
On Fri, Aug 21, 2020 at 5:36 PM Sebastian Benoit <[email protected]> wrote: > > Claudio Jeker([email protected]) on 2020.08.21 09:04:09 +0200: > > On Fri, Aug 21, 2020 at 08:45:36AM +0200, [email protected] wrote: > > > Hello, > > > > > > I am seeing rather strange, or maybe expected, behaviour. I utilise > > > rtables to send internal traffic towards the internet via a default > > > route in rtable 2. The traffic is punted to rtable 2 with pf. The > > > strangeness I am seeing is that unless there is a matching dummy route > > > in rtable 0 the traffic gets dropped on ingress hence the pf ruleset > > > that moves it into rtable 2 is never evalutated. > > > > > > Is this expected? The man pages for rdomain seems to suggest so but it > > > is not explicitly stated. > > > > I guess with internal traffic you mean traffic on the local LAN that is > > forwarded by the router. Not traffic local to the machine. > > > > pf(4) runs twice in your box. Once on packet reception (in rules) and once > > before sending out a packet (out rules). In between these two checkpoints > > packet forwarding happens (if forwarding is enabled and traffic is > > not for the local system). During forwarding a route lookup is made and > > based on that lookup the packet is sent out on the right interface. > > If this lookup fails the packet can't be forwarded and is dropped. Now > > the pf hook for out rules happens after this point and so a valid route is > > required to get there. > > > > In your case you either need a (default) route in rtable 0 so that traffic > > makes it to the out rule that then changes the rtable to 2 and sends out > > the packet towards the internet or you need to change the rtable on input > > (match in ... rtable 2) so that the forwarding lookup is done on rtable 2 > > (where there is a valid route to the destination). > > > > It seems most people prefer to write pf rulesets like yours with out rules > > and so a dummy default route in rtable 0 is needed but from a technical > > perspective it is better to do the rtable change on input. By doing so you > > actually save an extra route lookup (the one on rtable 0 hitting the dummy > > route). > > Even if you use the "match in ... rtable 2" solution (which you should), you > may want to add a default route to rdomain 0, because this problem can > happen in other cases as well. > > To make sure your route points packets to nowhere, but make pf work you can > do this (in one of your hostname.* files): > > !/sbin/route add -inet 0.0.0.0/0 127.0.0.1 -blackhole >
