Re: pf beginner: my firewall passes tcp but not icmp
I'm an idiot. I was pinging with some ip-options set (route tracking) and pf was dropping packets with such options. Not the rules at all. Thanks for the help! -- Cameron Simpson <[EMAIL PROTECTED]> DoD#743 http://www.cskk.ezoshosting.com/cs/ alt.skunks A newsgroup for enthusiasts of skunks and other mustelidae.
Re: pf beginner: my firewall passes tcp but not icmp
On Fri, Nov 04, 2005 at 07:22:33PM +1100, Cameron Simpson wrote: > 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? Yes. > 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? Maybe. The replies could also be happening, but be dropped by pf. You can look at 'netstat -sp icmp' to see if they're getting beyond pf and what the kernel is doing with them. bpf (and thus tcpdump) happens before pf incoming, and after pf outgoing: wire -> interface -> bpf -> pf -> routing -> pf -> bpf -> interface -> wire
Re: pf beginner: my firewall passes tcp but not icmp
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]>
Re: pf beginner: my firewall passes tcp but not icmp
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 have also tried "pass quick proto icmp all" with no useful effect.) With the simple ruleset above, or something more complicated? This should work (as should the above without the direction) > 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 > 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. > 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.
pf beginner: my firewall passes tcp but not icmp
I'm setting up an OpenBSD 3.7 firewall for the first time.
I've been flailing at this all afternoon and have exhausted my ideas.
My ruleset looks like this (from "pfctl -s rules"):
[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
It was more complex, but this is as simple as I can get it and demo the problem.
(I have also tried "pass quick proto icmp all" with no useful effect.)
With these rules in place and enabled, existing ssh sessions continue thanks
to their kept state, and new ssh connections work also.
However my pings, which work fine with pf disabled, get nothing back when I
enable pf ("pfctl -e") and of course spring back into life with "pfctl -d".
Does anyone have any idea what I'm doing wrong here?
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.
I'm loading up the rules like this:
pfctl -F rules -v && pfctl -xm -f /etc/pf.conf -v && echo YES
What else can I do to further debug this?
--
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
What the hell, it's only 4 month's grant - I can live in a cardboard box, and
catch pigeons for food. After all, I've got raytracing to do!
- [EMAIL PROTECTED]
