Re: rtables and kernel routes
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 wrote: > > Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.08.21 09:04:09 +0200: > > On Fri, Aug 21, 2020 at 08:45:36AM +0200, open...@kene.nu 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 >
Re: rtables and kernel routes
Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.08.21 09:04:09 +0200: > On Fri, Aug 21, 2020 at 08:45:36AM +0200, open...@kene.nu 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
Re: rtables and kernel routes
On Fri, Aug 21, 2020 at 08:45:36AM +0200, open...@kene.nu 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). -- :wq Claudio
rtables and kernel routes
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.
