|
OpenBSD Security Functionally paranoid! |
|
Thread Tools | Display Modes |
|
|||
pf block rule matches, but doesn't match if changed to pass
I am seeing some behavior from pf that I do not understand.
I have a very simple ruleset: Code:
block all block quick log on vmx7 proto icmp Code:
Aug 07 16:18:03.188621 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply Code:
block all pass quick log on vmx7 proto icmp How can this be? What am I missing? I distilled down to this example because traffic did not seem to be passing as I understand that it should with my full ruleset. |
|
|||
I also don't understand how this is possible.But I don't think it is the complete rule set
The simplest way to find out what gets blocked is to use something like block log (all) pf.conf(5) describes the other options for logging: Code:
log (all | matches | to interface | user) The keywords all, matches, to, and user are optional and can be combined using commas, but must be enclosed in parentheses if given. Use all to force logging of all packets for a connection. This is not necessary when no state is explicitly specified. If matches is specified, it logs the packet on all subsequent matching rules. It is often combined with to interface to avoid adding noise to the default log file. The keyword user logs the UID and PID of the socket on the local host used to send or receive a packet, in addition to the normal information.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Quote:
In this case, I see my ICMP packets matched by the second rule when it is a block and the first rule (the "block log") when I change the second rule to a pass. |
|
|||
See sample output:
Code:
fw0# cat pf.conf-show-bug block all block quick log on vmx7 proto icmp fw0# pfctl -f pf.conf-show-bug fw0# tcpdump -nettt -i pflog0 tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Aug 07 17:12:45.132261 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply Aug 07 17:12:46.132197 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply Aug 07 17:12:47.132325 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply Aug 07 17:12:48.132275 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply ^C 4 packets received by filter 0 packets dropped by kernel fw0# nano pf.conf-show-bug fw0# cat pf.conf-show-bug block all pass quick log on vmx7 proto icmp fw0# pfctl -f pf.conf-show-bug fw0# tcpdump -nettt -i pflog0 tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG ^C 0 packets received by filter 0 packets dropped by kernel fw0# pfctl -f pf.conf |
|
|||
Code:
$ doas pfctl -vvf show-bug Loaded 714 passive OS fingerprints @0 block drop all @1 pass log (all) quick on egress inet proto icmp all icmp-type echoreq $ ping -c2 192.168.222.10 PING 192.168.222.10 (192.168.222.10): 56 data bytes 64 bytes from 192.168.222.10: icmp_seq=0 ttl=255 time=0.382 ms 64 bytes from 192.168.222.10: icmp_seq=1 ttl=255 time=0.302 ms --- 192.168.222.10 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss Code:
$ doas tcpdump -eni pflog0 tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG 00:52:48.840082 rule 1/(match) pass out on bge0: 192.168.222.242 > 192.168.222.10: icmp: echo request 00:52:48.840430 rule 1/(match) pass in on bge0: 192.168.222.10 > 192.168.222.242: icmp: echo reply 00:52:49.848824 rule 1/(match) pass out on bge0: 192.168.222.242 > 192.168.222.10: icmp: echo request 00:52:49.849088 rule 1/(match) pass in on bge0: 192.168.222.10 > 192.168.222.242: icmp: echo reply
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump Last edited by J65nko; 8th August 2022 at 02:34 AM. |
|
|||
Under the heading STATEFUL FILTERING pf.conf(5) states:
Code:
Furthermore, correct handling of ICMP error messages is critical to many protocols, particularly TCP. pf(4) matches ICMP error messages to the correct connection, checks them against connection parameters, and passes them if appropriate. For example if an ICMP source quench message referring to a stateful TCP connection arrives, it will be matched to the state and get passed.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
Quote:
I will say that the behavior I was seeing is extremely unintuitive... |
|
|||
For testing you can generate manual or scripted TCP traffic with:
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
4.7 pf rule to block traffic from guest network | mikesg | OpenBSD Security | 5 | 16th August 2015 11:04 AM |
PF gets block rules not any pass | Arenio | OpenBSD Security | 1 | 10th April 2014 11:44 PM |
match vs pass (changes in 4.7), and inet vs inet proto | mikesg | OpenBSD Security | 4 | 12th June 2010 02:35 AM |
first match vs last match ruleset design (pf vs iptables) | zelut | FreeBSD Security | 5 | 12th July 2009 08:13 AM |
PF can't match on TOS? | ivanatora | FreeBSD General | 1 | 15th February 2009 10:34 AM |