pf: don't route broadcast or multicast traffic

[rcm]

Summary

pf_route() and pf_route6() forward broadcast and multicast traffic
when a route-to rule matches, without any check against the output
interface's broadcast domain. Apply the classification idiom used
elsewhere in the stack (M_BCAST/M_MCAST flags, IN_MULTICAST,
in_ifnet_broadcast, etc.) to guard against such leaks.

Sponsored by: Rubicon Communications, LLC ("Netgate")

[glebius]

I always assumed "policy routing" by packet filters a tool that allows to shoot into ones leg. I can imagine some weird scenarios where people would use pf to actually inject packets where it won't be routed by the normal stack.

[rcm]

In D56559#1294663, @glebius wrote:

I always assumed "policy routing" by packet filters a tool that allows to shoot into ones leg. I can imagine some weird scenarios where people would use pf to actually inject packets where it won't be routed by the normal stack.

That's fair. Though, currently, an operator who uses pf route-to without realizing it can emit L2 broadcasts across broadcast domains is foot-shooting themselves unknowingly. :)

[eugen_grosbein.net]

In D56559#1294664, @rcm wrote:

In D56559#1294663, @glebius wrote:

I always assumed "policy routing" by packet filters a tool that allows to shoot into ones leg. I can imagine some weird scenarios where people would use pf to actually inject packets where it won't be routed by the normal stack.

That's fair. Though, currently, an operator who uses pf route-to without realizing it can emit L2 broadcasts across broadcast domains is foot-shooting themselves unknowingly. :)

We do not prevent a superuser from foot-shooting and we do not assume that superuser is stupid. A warning should be enough.

[rcm]

In D56559#1294669, @eugen_grosbein.net wrote:

In D56559#1294664, @rcm wrote:

In D56559#1294663, @glebius wrote:

I always assumed "policy routing" by packet filters a tool that allows to shoot into ones leg. I can imagine some weird scenarios where people would use pf to actually inject packets where it won't be routed by the normal stack.

That's fair. Though, currently, an operator who uses pf route-to without realizing it can emit L2 broadcasts across broadcast domains is foot-shooting themselves unknowingly. :)

We do not prevent a superuser from foot-shooting and we do not assume that superuser is stupid. A warning should be enough.

Another potential solution to this that came up in discussion with kp was using block out quick rule(s) to plug up any problematic leaks.

So I think the question is really: are we okay with pf_route
forwarding broadcasts when ip_forward (nominally) doesn't? If yes, then I do agree at least a few lines in the man page be introduced that calls out this difference, and maybe prescribes example rules that can be used to plug any undesirable leaks.

[lytboris_gmail.com]

sys/netpfil/pf/pf.c

9810

To cope with concerns mentioned by @glebius I'd put here a deprecated-upon-creation sysctl to revert packet processing to the previous behavior. This sysctl should be set to "drop, not forward" value by default.

10170

Same as above