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.
Question regarding pf rules: block in on em0: ...
Hi All,
I just noticed that "simple-scan" no longer discovers my scanner.
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 [ttl 1]
...
192.168.178.11 is my OpenBSD desktop.
I don't understand what I'm seeing here ...
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?
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 ...
Grateful for any advice!
Yours,
Puzzled in PF-Land
FYI:
This is with a 7.3 snapshot: 7.3 GENERIC.MP#1268 amd64
Output of ifconfig:
4.07 11:23:51 # ifconfig em0
em0:
flags=a48843
mtu 1492
lladdr 94:c6:91:aa:16:67
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::96c6:91ff:feaa:1667%em0 prefixlen 64 scopeid 0x1
inet 192.168.178.11 netmask 0xff00 broadcast 192.168.178.255
inet6 2003:ee:1718:b100:39e3:3c67:bd3c:44f4 prefixlen 64 deprecated
autoconf pltime 0 vltime 5213
inet6 2003:ee:1718:b100:3470:4349:f8d0:e1d2 prefixlen 64 deprecated
autoconf temporary pltime 0 vltime 5213
Not sure what that "deprecated" means here.
Rule @2 is the "classic" block all rule ...
The contents of pf.conf:
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
set block-policy return
set debug warning
# By default, do not permit remote connections to X11
#block return in log on ! lo0 proto tcp to port 6000:6010
block log on ! lo0 all # Begin by blocking everything
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
# Allow all outbound
pass out quick modulate state
# Local subnet ...
local_subnet_v4="{ 192.168.178.0/24 }"
local_subnet_v6="{ fe80::/10 }"
# TODO: Correct ???
# Local systems that I might trust ...
trusted_clients_v4="{ 192.168.178.10, 192.168.178.12, 192.168.178.13,
192.168.178.14 }"
# Allow ssh in
pass in log inet proto tcp from $trusted_clients_v4 to (egress) port ssh
modulate state
# Scanner discovery? Allow traffic from Canon pixma TR8550
#scanner_ports="{ 8610, 8612 }"
#passlog inet proto udp from 192.168.178.85 port $scanner_ports
pass in log inet proto udp from 192.168.178.85 port 8610
pass in log inet proto udp from 192.168.178.85 port 8612
#
# Allow avahi? See: /usr/local/share/doc/pkg-readmes/avahi
pass in log inet proto udp from any to 224.0.0.251 port mdns allow-opts
pass in log inet6 proto udp from any to ff02::fb port mdns allow-opts
# and for SSDP:
pass in log inet proto udp from any to 239.255.255.250 port ssdp allow-opts
pass in log inet6 proto udp from any to { ff02::c, ff05::c, ff08::c } port ssdp
allow-opts
#
# OK, then try allowing multicast in general ...
pass log inet proto igmp from any allow-opts
# NFS: Allow access to local NFS server
nfs_ports="{ sunrpc, nfsd, 881 }"
#
# But is UDP really still necessary?
#pass in proto udp from $trusted_clients to (egress) port $nfs_ports keep state
#pass out proto udp from (egress) to $trusted_clients port $nfs_ports keep state
#
pass in proto tcp from $trusted_clients_v4 to (egress) port $nfs_ports modulate
state
pass in proto tcp from (egress) to $trusted_clients_v4 port $nfs_ports modulate
state
# ICMP: Limit ICMP to allowed types: echorep, unreach, squench, echoreq, timex:
icmp_types = "{ echoreq, echorep, unreach, squench, timex }"
# See also: "man 4 icmp"
pass in log inet proto icmp to (egress) icmp-type $icmp_types label "rule $nr:
pass: $proto: $icmp_type"
# HTTP: Running http-file-server:
# PORT= bin/http-file-server -u ~/Public/
# 2020/07/13 16:11:35 serving local path "/space/home/robb/Public" on "/Public/"
# 2020/07/13 16:11:35 redirecting to "/Public/" from "/"
# 2020/07/13 16:11:35 http-file-server listening on ":"
fs_port="{ }"
pass in proto tcp from $trusted_clients_v4 to (egress)
