0

I have (amongst others) these rules in my pf setup:

block drop in log (user) proto udp from any to any port = 137
block drop in log (user) proto udp from any to any port = 138
block drop in log (user) proto udp from any to any port = 139
block drop in log (user) proto udp from any to any port = 445
block drop in log (user) proto tcp from any to any port = 137
block drop in log (user) proto tcp from any to any port = 138
block drop in log (user) proto tcp from any to any port = 139
block drop in log (user) proto tcp from any to any port = 445
pass in proto udp from <192.168-net> to any port = 137 keep state
pass in proto udp from <192.168-net> to any port = 138 keep state
pass in proto udp from <192.168-net> to any port = 139 keep state
pass in proto udp from <192.168-net> to any port = 445 keep state
pass in proto tcp from <192.168-net> to any port = 137 flags S/SA keep state
pass in proto tcp from <192.168-net> to any port = 138 flags S/SA keep state
pass in proto tcp from <192.168-net> to any port = 139 flags S/SA keep state
pass in proto tcp from <192.168-net> to any port = 445 flags S/SA keep state
pass in proto udp from <ipv6-local-nets> to any port = 137 keep state
pass in proto udp from <ipv6-local-nets> to any port = 138 keep state
pass in proto udp from <ipv6-local-nets> to any port = 139 keep state
pass in proto udp from <ipv6-local-nets> to any port = 445 keep state
pass in proto tcp from <ipv6-local-nets> to any port = 137 flags S/SA keep state
pass in proto tcp from <ipv6-local-nets> to any port = 138 flags S/SA keep state
pass in proto tcp from <ipv6-local-nets> to any port = 139 flags S/SA keep state
pass in proto tcp from <ipv6-local-nets> to any port = 445 flags S/SA keep state

From logging I see that

block drop in log (user) proto tcp from any to any port = 445

is triggered from 192.168.2.91. How is that possible given

pass in proto tcp from <192.168-net> to any port = 445 flags S/SA keep state

The same happens with one other client regularly with another ruleset (for the submission port). Both connect over Wifi. Services do not seem to be affected, so I'm just curious how it is possible these log messages of blocked packets are possible. I suspect something to do with the flags, but I do not quite understand how that could happen. Something with damaged packets maybe?

I am running macOS Mojave on both clients and server.

gctwnl
  • 171
  • 11
  • "From logging I see that" — don't you think if you ask such a question it might be quite reasonable to show what you see then? – poige Jan 27 '20 at 07:34
  • Normally, of course. I see logging through a GUI (Murus) that doesn't allow me to copy text, so I can only make a screen shot. That tells you which rule is triggered. (So something like ` [source:] 192.168.2.91 port [target:] 192.168.2.66 port 45 [rule:] ` No mistake possible. – gctwnl Jan 28 '20 at 11:12
  • That’s close to none of info compared to original `pflog` output. That’s another reason I don’t use no GUI tools for firewalls. – poige Jan 28 '20 at 11:48
  • I have a possible explanation. I've noticed that this also happens when a client goes to sleep and wakes. So it is an `S/SA keep state` thing in combination with interrupted traffic maybe? How bad is it to just drop the `S/SA keep state` thing? – gctwnl Jan 28 '20 at 12:33
  • 1
    Yes, most likely it's due to `Pf`'s state table becoming not in-sync (obsolete info, etc) with real state of traffic flow. `S/SA keep state` are defaults of `Pf` even if it's not explicitly given (see `man pf.conf`). Before dropping it you'd better understand (as is the general case typically) what you're doing and it's far beyond the scope of this comment field, some people write _books_ about firewalls and `Pf` in particular. – poige Jan 28 '20 at 13:08
  • Thank you. I've set up a tcpdump on the flog device, so I can now follow exactly what is going on. Do you turn your 'most likely' comment into an answer? – gctwnl Jan 28 '20 at 15:34

0 Answers0