Question Regarding Default Deny Rules
-
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.
-
Just as a quick follow up...
The most recent "pattern" seems to be the normal now. When I view the FW log, 90+% is this repeated pattern of Roku devices repeatedly trying to reach IP's on port 443. Most or all of them have TCP flags or TCP:FA, TCP:PA,, or TCP:FPA. I do see some IPv6 log entries with TCP:S, but like I said before I have done nothing with IPv6 so I have no idea what those devices are or where they're trying to reach. Those are just a few lines per 750 lines of log entries.
I am tempted to disable the logging but I'd hate to miss something worth seeing. I don't understand why these blocks are happening or if I should even care. Either way, its a lot of logging that will make it difficult to see other things I might want to see.
Just as a test, I created an Alias and added all Roku IP's to it. I then create a FW rule that allows traffic from the Roku Alias to anything on port 443 and I left the logging box unchecked. My thought is if I put this rule above the allow all rule, then it will pass the traffic but not log it. Now if this works, I am not sure if I should put in the TCP flags to be specific for that traffic or not. I looked but could not tell which ones I would use if I were to try that.
-
Ok, well that didn't work. My new FW rule seems to not have impacted the logging because the Roku log entries are still coming in. :(
-
It won't match that rule because it's still out of state TCP. A pass rule will only allow opening new connections with TCP:SYN unless you have set specific flags in the advanced section.
What you are seeing is expected. The only real issue is it spams the logs.
You could add a custom block rule at the end of the list without logging just for the Rokus as source.
You could try setting the firewall optimisation to conservative so states are not killed as quickly.
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#firewall-optimization-optionsThough for TCP states they are intentionally killed when the server sends a FIN.
-
@stephenw10
What would the custom block rule do and how would it work? Like I mentioned above, I created the pass rule with no logging specifically for the Roku's but its not matching. If its the issue of the TCP state, is there any way I can set the advanced options so it would match? -
Rather than hitting the default block rule and being logged if you add a custom block rule that will match first. That way you can block specific traffic without logging and the default block rule will still log anything unexpected.
You could also add a pass rule with the advanced TCP flags set. That will prevent it being logged but it also means the traffic will be sent back and just blocked somewhere else.
