A small query about 104
-
Normally, when a packet comes from the WAN side, you see that it is rule 1000000103 that takes care of this. As shown 37.44.238.148:58698 is trying to reach port 161 via my WAN IP. I understand that scenario well.
Today I see in the log a rule 1000000104 used, I don't see 104 anywhere in my setup. In addition to the above, it looks like an external IP 108.128.239.197:443 is directly trying to reach the LAN IP to my Samsung TV, on port 50218.
Can someone explain to me what is going on here, because I just can't understand it.
And where can I most easily see where rule 104 comes from, and belongs to?
I'm trying my best to learn, hope this isn't a very stupid question. ;o)
-
@felix-4 Shell in and run pfctl -sr to list your rules with identifiers. On my rig, that rule 104 is:
block drop out log inet all label "Default deny rule IPv4" ridentifier 1000000104
Btw you don't need to obscure private IP space in your image since you can't route to it from outside your LAN.
-
@kom said in A small query about 104:
1000000104
Thanks for reply.
I have run the command you refer to, and get a long list of information. I copied that list into a document and searched for 1000000104, but get no info on that number, so it's strange.
There are records of 101 0g 107 0g 108 but not what I'm looking for.
This is for information -
@felix-4 not sure what you did, but that rule is on every pfsense. Simple enough to find with a grep
[22.05-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep 104 block drop out inet all label "Default deny rule IPv4" ridentifier 1000000104 [22.05-RELEASE][admin@sg4860.local.lan]/root:
Maybe easier for you to read would be a cat of /tmp/rules.debug
You will then see that rule here
#--------------------------------------------------------------------------- # default deny rules #--------------------------------------------------------------------------- block in inet all ridentifier 1000000103 label "Default deny rule IPv4" block out inet all ridentifier 1000000104 label "Default deny rule IPv4" block in inet6 all ridentifier 1000000105 label "Default deny rule IPv6" block out inet6 all ridentifier 1000000106 label "Default deny rule IPv6"
Here is all the ways to view all the rules on pfsense.
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset
It is a bit odd seeing those, those look to be out of state see the FA (fin,ack) and outbound on lan.. So not exactly sure the actual scenario that would log that..
-
@johnpoz said in A small query about 104:
It is a bit odd seeing those, those look to be out of state see the FA (fin,ack) and outbound on lan.. So not exactly sure the actual scenario that would log that..
Thanks for reply,
It is precisely the last thing you write that particularly interests me, also the arrow I have marked in red in the attached photo.
It's only today that I've seen it in the log file, it's strange to see a WAN IP pointing directly to a LAN IP, but maybe someone will come by who knows a little about it. I feel the best about being able to understand everything that is going on on my Pfsense -
@felix-4 Nothing weird about it. It's simply telling you about traffic between two hosts. Out of state traffic is being blocked by default. When one side considers the conversation over, any replies from the other end will be dropped as the existing state has been closed. These can usually be ignored unless they're a symptom of a larger problem you're having.
-
@kom yeah while I agree out of state are not all that uncommon to see. But seems odd that they our blocked on the outbound, they shouldn't of been even allowed into the wan if the state was gone.
And those are answers to the client that created the connection.. see the source is from 443 (https)..
Maybe it was pfsense closing the state when it saw the client sending the FA, but the answer was blocked? I normally do not log default blocks, so haven't seen stuff like that before. I only block syn blocks, and common udp ports. So what pfsense blocks by default other than syn I don't care to see in my logs. Unless troubleshooting something - and have had no issues to trouble shoot lately ;) So logging of default is just turned off.