>>> On 19 July 2007 at 23:52, in message
<20070719225255.GC3317@bootes.spacehopper.org>, Stuart Henderson
<stu@spacehopper.org> wrote:
quoted text
> On 2007/07/19 15:38, Gordon Ross wrote:
>> Cutting down the pf ruleset to the bare minimum, I have:
>
> Might be below the minimum; there's no explicit "pass out".
> There's an implicit one, but I suspect it might not be keeping
> state (though the default as of 4.1 is to keep state, I suspect
> this _may_ apply only to rules configured by pfctl and not implicit
> ones). And if that's the case it won't permit the return traffic.

Made a little bit of progress..

If I change

pass in on $int_if proto tcp from 172.16.2.34 to 192.168.249.3 keep state

to:

pass proto tcp from 172.16.2.34 to 192.168.249.3 keep state

Then that works fine. Now I can half see why this does work: I've not
specified a direction or interface for the rule. For a simple two-interface
firewall, that's should be OK. My thoughts turn to when I have a firewall with
more than two interfaces: What would happen to a spoofed packet appearing on a
"wrong" interface ? As the rule no longer specifies interfaces, I could see
that PF would allow the packet through... Would the solution be to create
rules that only allow "valid" addresses to come in to interfaces ? Or am I
being paranoid ?

GTG