8) States can be bound to the specific interface that created them or to a group of interfaces for example:
- pass all keep state (if-bound) - pass all keep state (group-bound) - pass all keep state (floating)
Could you elaborate on this change and its uses a little? Especially the "group-bound" thing?
Ok. "floating" is the default, and is what PF has been doing all the time. That mean that if you've a rule like:
pass in on fxp0 keep state
Once the state is created, PF will match that state with packets having the same characteristics (source/dest IP, same port for UDP/TCP, ...) coming in/out *any* interface. So, if a state is created for IKE traffic coming in on one interface, then any IKE packet with spoofed IP will be able to enter the firewall from any other interface, regardless of PF rules on that interface.
On the other hand, if you specify:
pass in on fxp0 keep state (if-bound)
The state created by a packet entering on fxp0 will only match packets coming in/out of fxp0, and not any other interface. This is more secure, but can be a problem if the firewall is in a dynamic routing environment, where valid connections can migrate from one interface to the other.
"group-bound" is a middle way between "floating" and "if-bound", so if you specify:
pass in on fxp0 keep state (group-bound)
Then the state initially created on fxp0 will match packets coming in/out of all fxp# interfaces, but not on ppp0 for example. This could be useful if you've a bank of ppp modems and have routing changing between the different modems. Same thing if you use markus suggestion of using GIF devices for your VPN: if one gif tunnel goes down, packets for a remote location could coulde be routed from another peer, so it would make sense to have states "group-bound" on gif interfaces.
One situation where you absolutely need either group-bound or if-bound is when you put more than one bridge on the same box (bridge0 and bridge1 for example). In that environment, having states floating brings all kind of strange behaviour.
When you use group-bound or if-bound states, it is possible to have two states with the same source/dest addresses and port that live in PF. There is not completely wrong, but will break ftp-proxy and other similar stuff that uses the NATLOOK ioctl. So for proxy stuff, if you're running in a dynamic routing environment, don't use if-bound states.
Does that makes sense? Cedric
