Re: Question regarding pf rules: block in on em0: ...
I have no idea how I could make my question any clearer: > My question is not about how to disable pf, but rather why the packets > are see as "in" when coming from my own address, and, why they are > blocked i.e. ... On Thu, Jul 06, 2023 at 11:09:27AM -0600, Zack Newman wrote: > For added clarity, this tcpdump you show is with pf disabled and all > its rules flushed. The tcpdump you showed in the initial e-mail > clearly was with active pf rules. Dude, it is _literally_ the same trace output. If you feel the need to try to help people, maybe calm down a bit and actually read the question. I'm out. Robb.
Re: Question regarding pf rules: block in on em0: ...
On 7/6/23 06:14, Why 42? The lists account. wrote:
Hi,
I see that I was not clear enough.
You were not. One of the first things in your initial e-mail was the
following:
"While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen."
Is it a pf problem or not? If it is the case your "scanner" thing
doesn't work with pf disabled and no active rules, then this entire
thread makes no sense as you are focusing on something that is not
relevant.
Next steps. Disable pf _and_ flush the rules. Confirm there are no
active rules with pfctl -s all. Run the following:
tcpdump -ntt -i em0 -w pkts.dat &
Check if your "scanner" thing works.
Case 1: it doesn't work. Reply to this thread closing it due to the
completely irrelevant nature of both its title and content since you
have an entirely separate issue you need to solve first. If you are
unable to figure it out, then start a new thread with a more relevant
title where you only focus on things that matter. The only part of that
thread that should mention pf is how you have it completely disabled,
so you know it is something else. In that thread include the contents
of the tcpdump.
Case 2: it does work. Reply to this thread retracting you false claim
that pf "doesn't seem to the the issue". In that response include the
contents of the tcpdump.
For added clarity, this tcpdump you show is with pf disabled and all
its rules flushed. The tcpdump you showed in the initial e-mail
clearly was with active pf rules.
In the event that you require some form of traffic manipulation (e.g.,
NAT), then obviously you cannot disable pf. In that situation, make
sure your pf.conf rules only contain something similar to the following:
set skip on lo
pass out quick on inet from { :network
:network ... :network } nat-to static-port
pass quick
Re: Question regarding pf rules: block in on em0: ...
On Tue, Jul 04, 2023 at 10:42:39AM -0600, Zack Newman wrote: > ... > I am guessing you didn't flush the rules after disabling pf since > clearly pf rules are still being used. Run pfctl -F all after disabling > pf. Run pfctl -s all to verify there are no active rules. Hi, I see that I was not clear enough. My question is not about how to disable pf, but rather why the packets are see as "in" when coming from my own address, and, why they are blocked i.e. I noticed these block messages being logged when I click "discover/refresh" in simple-scan: Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 255.255.255.255.3289: udp 15 [ttl 1] Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 255.255.255.255.1124: udp 37 [ttl 1] 192.168.178.11 is my OpenBSD desktop (where of is running). I don't understand what I'm seeing here ... 1. Why am I seeing traffic coming _in_ from my own address? Is that not slightly weird? Is it because it is _to_ the .255 broadcast address? 2. And why is it being blocked? Do I have explicitly allow broadcast traffic e.g. with rules to handle broadcast addresses? I don't think I ever considered doing that before ... The more I use pf, the less I seem to understand? Danke im Voraus! Robb.
Re: Question regarding pf rules: block in on em0: ...
On 7/4/23 10:36, "Why 42? The lists account.": While trying to debug the issue, it occurred to me that it could be a network / pf problem. This doesn't seem to be the issue though, even after I disable pf (pfctl -d), the scanner is still not seen. However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block messages being logged when I click "discover/refresh" in simple-scan: ... Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 255.255.255.255.3289: udp 15 [ttl 1] Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 255.255.255.255.1124: udp 37 I am guessing you didn't flush the rules after disabling pf since clearly pf rules are still being used. Run pfctl -F all after disabling pf. Run pfctl -s all to verify there are no active rules.
Re: A question on pf rules
On Tue, 2007-02-20 at 07:32 -0800, [EMAIL PROTECTED] wrote: Greetings, Does it make any difference if I group my rules like this . it can be, depending on your situation. PF rules are read top to bottom, therefore, lower rules can override rules that were previously defined. if you want rule defined and there to be no chance that a later rule can alter it, add the 'quick' keyword. later. ryanc -- Ryan Corder [EMAIL PROTECTED] Systems Engineer, NovaSys Health LLC. 501-219- ext. 646 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: A question on pf rules
On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Greetings,
Does it make any difference if I group my rules like this .
## logs smtp sessions
pass in log on $ext_if proto tcp to $mailhost port smtp keep state
## Pass all outgoing traffics
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out log on $ext_if inet proto tcp from $mailhost to any port smtp
keep state
pass out on $ext_if inet proto { icmp, udp } all keep state
Or, like this .
## logs smtp sessions
pass in log on $ext_if proto tcp to $mailhost port smtp keep state
pass out log on $ext_if inet proto tcp from $mailhost to any port smtp
keep state
## Pass all outgoing traffics
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out on $ext_if inet proto { icmp, udp } all keep state
Last matching rule wins so the second example won't do what you're
expecting.
http://www.openbsd.org/faq/pf/filter.html
Also, try to use flags S/SA on all of your stateful TCP rules unless you
have a good reason not to.
--
Kian Mohageri
