[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: interface improvements - help needed!



Damien Miller wrote:

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