Daniel Hartmeier wrote: > I guess it got lost. Since then, we added the 'set skip on lo' feature > (which is part of the example pf.conf), which resolves this issue, and > others. > > Instead of going into the gory details of how loopback filtering breaks > synproxy in this case, I think it would be better to simply recommend > skipping filtering on loopback, in general. The cases where it's > actually useful are equally technical. > > The man page in 3.8 contains this part > > set skip on <ifspec> > List interfaces for which packets should not be filtered. Packets > passing in or out on such interfaces are passed as if pf was dis- > abled, i.e. pf does not process them in any way. This can be use- > ful on loopback and other virtual interfaces, when packet filtering > is not desired and can have unexpected effects. For example: > > set skip on lo0 > > You either didn't spot it at this location or the 'can have unexpected > effects' part was not enough of a warning. Where would you relocate it to > or how would you reword it to make it clearer? > > Daniel
I actually thought i had that covered by my 'pass quick on lo0 all' rule, but apparently i hadn't quite understood the difference between passing everything and not filtering at all. :) How about adding something like "For synproxy to protect local daemons, disabling filtering on the loopback interface is recommended unless the if-bound state policy is used." directly above or below the "Rules with synproxy will not work if pf(4) operates on a bridge(4)." line?
