PF Dynamic PF?

How does everyone handle PF with changing network interfaces and DHCP addresses?

I'm thinking I need to create my own meta pf file scripting format or generate it with a scripting language and trigger it with devd every time there is a change.

Things that change?

DHCP IP's can change when they renew.
You could plug or unplug the cable to your external internet connection.
Plug and play network adapters such as USB network adapters. Or a laptop base station.
Jails with epair adapters that are started and stopped.
OPENVPN or other style VPN's that are started and stopped.

Just wondering how other people handle these things for their situations.
 
DHCP IP's can change when they renew.
You could plug or unplug the cable to your external internet connection.

pf.conf(5)

Code:
           Host name resolution and interface to address translation are done
           at ruleset load-time.  When the address of an interface (or host
           name) changes (under DHCP or PPP, for instance), the ruleset must
           be reloaded for the change to be reflected in the kernel.
           Surrounding the interface name (and optional modifiers) in
           parentheses changes this behaviour.  When the interface name is
           surrounded by parentheses, the rule is automatically updated
           whenever the interface changes its address.  The ruleset does not
           need to be reloaded.  This is especially useful with nat.

Plug and play network adapters such as USB network adapters. Or a laptop base station.
Jails with epair adapters that are started and stopped.
OPENVPN or other style VPN's that are started and stopped.
For all of those cases you can either simply use the interfaces group (automatic/default groups like e.g. 'egress' or custom defined) for rulesets if you really need interface-based rules (hint: you usually don't), or especially for jails you usually use distinct, local jail subnets which can be used for PF rules (e.g. for NATing traffic from jails). Jail interfaces are also usually connected to a bridge, so you can simlpy apply the rules to the bridge or the "host-facing" interface that is attached to that bridge if you really think you need to make those rules interface-based.


There's absolutely no need to write any "dynamic" scripts, let alone "meta pf file scripting" (whatever that should be...) - PF already brings everything needed to *reliably* handle such events.
 
Does using the "egress" group in the PF config file actually work, out of the box? I know it works in OpenBSD (used to use it there).

I tried it a while ago (perhaps a year, probably in FreeBSD 12.x), and it didn't work. Don't remember the details. A quick search finds the following open feature request to actually implement it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237973. It seems that the current status is: install a port called egress-monitor. There is also discussion in this thread: https://forums.freebsd.org/threads/fundamentals-of-packet-filtering-with-pf.78739/
 
Does using the "egress" group in the PF config file actually work, out of the box? I know it works in OpenBSD (used to use it there).
Don't know if it's the same mechanism as on OpenBSD, where an interface that is associated with a default route is automatically added to the group 'egress', but I don't have an interface group 'egress' on any of the FreeBSD hosts I checked.

So I guess it's not working on FreeBSD...
 
Back
Top