Question Regarding Default Deny Rules
-
@djtech2k run a pcap file and inspect it for what is occurring. isolate and identify.
-
Working on that now. Its hard to match up IP's from the capture to the log. So far I grabbed 1 IP that I saw and the only thing I see in the capture is 1 entry connecting to a "furbo" FQDN, so that must be device on my called a Furbo. It is a camera device that has an app to use to view video/sound, among other things. It seems to have a lot of comms in the pcap. I have no idea what the traffic is for but it must be for the streaming aspect. So I have no idea why any of that traffic would get blocked by the default block rule.
I am going to keep looking, but so far I see a lot of packets but nothing that I can see that should be blocked.
-
Since I typed the last message, I see 8 consecutive blocks on the LAN interface from an IP that is assigned to an Active Directory Domain Controller. The Source IP is its LAN IP, the source port ranged in the 52700's and the destination IP is about 3 different IP's, all going to port 443.
I did a quick ip lookup on 1 IP and it says its owned by Microsoft. So I would assume the traffic is normal, but pfsense is blocking it with the default rule.
-
I have grabbed a few different pcap's and been looking thru the fw logs and various different IP's. Another example is Roku devices getting packets blocked outbound. I do not see a pattern on the traffic so I do not understand why I am seeing all of the default deny rule blocks. It would be helpful to know what the Default Deny Rule does so I would know why its being blocked.
-
@djtech2k you said your running pfblocking? If so can you cross reference the block logs with similar time stamps ?
-
Yes, I have pfblockerNG installed and running.
Which logs are you talking about cross referencing? I am new to pfblocker so I don't know a lot about the logs yet but I am not seeing much in the logs section. The ip_block.log shows a few lines but I see nothing that seems to correspond to the packets I mentioned before. There are a total of 5 entries in that log for today whereas there are tons of entries in the firewall logs like I mentioned.
-
@djtech2k if everything is working and nothing in the pcap file is causing you issues I would just ignore it. You said you have web traffic, that is port 443 so that is working, DoH is over 443 and if you have blocked that in pfSense pfblocking that might be what is occurring and or a tcp connection has an inconsistent flag set and or window and the firewall is blocking it. Default rules are anything that wants out from the inside is approved and anything trying to get in is blocked, unless you changed your access control lists, I would inspect the pcap files to trace down the blocks and times. I do not use pfblocking, I am a customized Squid user myself. Again lots of other users can help you with pfblocking. You could try to disable it for a bit and see if the logs go away also.
-
@djtech2k said in Question Regarding Default Deny Rules:
The Source IP is its LAN IP, the source port ranged in the 52700's and the destination IP is about 3 different IP's, all going to port 443.
the default lan rule is any any - there should be nothing blocked by the default lan rule.. What does it show in the log - can you post it showing your lan IP and some random IP on the internet owned by MS wouldn't be giving anything away.
What your lan rules exactly - can you post them, is it just the default any any..
pfblocker blocks wouldn't show up as the default deny.. unless your not allowing them.
Rules are evaluated top down, first rule to trigger - so if you do not allow where your lan IP is trying to go - then yes it would be blocked by the default deny.. please post up your lan interface rules.
here are mine for example
-
@djtech2k can you also post the log entry? Might be https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
-
@djtech2k Assuming TCP, check the protocol flags -- the blocks may be showing up because the state has expired. It's rather common. When you see blocks on with flags of TCP:FPA, TCP:FA, TCP:RA, etc. it generally means that the block occurred because the connection state has expired because the other end has already closed the connection.
If you see TCP:S or TCP:SA, that's a real block.
-
@dennypage that is very likely it the multiple ones he saw in a row to the MS IP could be the retrans.
We would know for sure if he posted the actual log of what he is seeing.
-
@dennypage I thought the same thing because he said he has web traffic
-
It could just be LAN side devices trying to use closed states.
-
@stephenw10 I see this with Squid all the time too, same closed tcp syc ack
-
Thanks all. Just catching up here. Here are some details.
Firewall Logs: Here are some examples of what I am seeing. There are many more so this is just a few scraped from the top of the log when I opened it today.
This example is showing 3 consecutive identical packets, but it is not always like this. There's plenty that are different on each line.
Now that I have the whole network going thru pfsense, I am seeing a ton of repetitive traffic like this coming from Roku devices. As a matter of fact, when I scroll thru the last 750 lines of FW log, I would say the majority of it is traffic like that picture and all on the various Roku devices I have. This was not the case when I started seeing the logs, but I guess the Roku devices have a lot of traffic being blocked for some reason. When I first started, Roku was not dominating the block logs.
Here are my LAN port rules. There is not a lot here yet as I am rolling into it slowly. I have the 2 block rules from pfblockerNG. I have 2 rules that I added to get pfsense to connect to an upstream VPN for IP's that are a member of a group. Then there are the default allow rules.
With all of this, I do not notice a functional problem but I do want to better understand why I see things being blocked when I see no rules or reasons it is being blocked. I know the logs image is just a small example, but its many, many lines of logs. For reference, from 10:56:24am to 12:49:12pm today, there are over 750 FW log lines. Maybe thats not considered high volume and IDK if this is on pace or in a lull of some sort, but thats just a reference I see now.
-
@djtech2k these are all out of state blocks
Are all of your blocks with say FA or just A? or maybe RA
fin,ack - is that device saying hey done with this connection.
Seeing those is normal when state was closed say on the first fin and client didn't get a response that it was expecting and so retrans
If you don't like seeing such noise, you prob want to just turn off default deny logging and setup your own log rules.
A syn (S) block would mean that traffic was not allowed because you had no rule to allow it. A syn,ack (SA) would mean that the S was never seen by pfsense to open the state in the first place - this can point to asymmetrical traffic flow.
But that FA, with P (push flag) set is nothing but noise.
-
Looking at the top 750 log entries, it looks like LAN interface lines are all/most some combination of FA, PA, FPA, etc. There are very few with S in them and those are hit by the pfblockerNG rules.
I do see some IPV6 TCP:S blocks on the default rule. I do nothing with IPv6 so I have not configured one thing for it up to this point.
I am still baffled by this "default deny rule" that I cannot see. How could I tune the logging to maybe not log those entries but not turn it all off wholesale? Or is that even possible? I have not yet found the ability to change the logging on the invisible "default deny" rule.
-
@djtech2k said in Question Regarding Default Deny Rules:
change the logging on the invisible "default deny" rule.
-
Just a punt in the dark here. That 45.xxx ip comes back to netflix.
Is it possible the default block is due to IP options not being set in the advanced firewall rule for allow all?
@stephenw10 @johnpoz How would one monitor if this is indeed the case? What tcpdump option or other method to observe blocked packet?
IP Options¶ Checking this box will allow packets with defined IP options to pass. By default, pf blocks all packets that have IP options set in order to deter OS fingerprinting, among other reasons. Check this box to pass IGMP or other multicast traffic containing IP options. -
@GPz1100 why would his client sending TCP with a fin,ack have ip options set????
Now if it was a SYN packet that was being blocked and he had rules to allow it, then you might have to get creative to see why that was happening.. But a FA being blocked is because there is no state.
