On 04Nov2005 07:52, Ryan McBride <[EMAIL PROTECTED]> wrote: | On Fri, Nov 04, 2005 at 05:16:22PM +1100, Cameron Simpson wrote: | > [var/[EMAIL PROTECTED]> pfctl -s rules | > block return all | > pass quick proto tcp from any to any port = ssh flags S/SA keep state | > pass in quick proto icmp all keep state | ^^ | How are the packets supposed to get OUT of the firewall? You have to | think of the traffic crossing both interfaces.
I was imagining the keep state stuff handled that. So - for my mental model - a packet being forwarded traverses the rules twice: once on the way in and once on the way out? My original attempt was stateless - I just wanted echoreq and echoreply to have free passage, and so it had no directions or state. | > (I have also tried "pass quick proto icmp all" with no useful effect.) | | With the simple ruleset above, or something more complicated? The latter. I'll try some more systematic experiments now. | This should work (as should the above without the direction) Ok. | > Also, I have seen elsewhere in list archives debug output showing what rules | > got applied. I have not found out how to produce such debugging myself. | | Add the 'log' keyword to at least your block rule, and maybe your pass | rules as well. Then do: | | # tcpdump -vvvpleni pflog0 -s 1518 Ah. I'd been trying without the -s and getting data format complaints. | > I'm loading up the rules like this: | > pfctl -F rules -v && pfctl -xm -f /etc/pf.conf -v && echo YES | | Don't explicitly flush the ruleset like this, pf does that for you and | with such a command you're running without any ruleset at all for at | least a moment, more if your new ruleset is buggy and fails to load. Indeed. The "pf -F" was again my growing paranoia. The pfctl man page seemed to suggest the flush was automatic, since there were options to not flush things, but wasn't explicit in the positive. So I was just trying to ensure I really was discarding the old set of rules entirely. Glad to know it's wasteful and dangerous. | > What else can I do to further debug this? | | tcpdump on the pflog interface is probably the most powerful tool; you | can also look at pfctl -si to see if packets are being dropped for some | other reason than ruleset evaluation, and perhaps do tcpdump on the | physical interfaces you think the traffic should be crossing, to see if | it's maybe actually coming out on the other side but being dropped | elsewhere on your network. Well I'd reduced my test to pinging the firewall itself. An earlier tcpdump was showing pings coming in and no replies. Would that imply pings arriving and being dropped, and thus no replies attempted by the OS? Anyway, I'll proceed not with better debugging and return with a diagnosis or at least more data:-( Thanks! -- Cameron Simpson <[EMAIL PROTECTED]> DoD#743 http://www.cskk.ezoshosting.com/cs/ Hello, my name is Yog-Sothoth, and I'll be your eldritch horror today. - Heather Keith <[EMAIL PROTECTED]>
