Question Regarding Default Deny Rules
-
@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.
-
@djtech2k where did you create the rule - the allow isn't the problem, its the deny when there is no state.
Create a block rule on the end with your rokus ip(s) in it and don't log it.
Logging default deny is always going to create log spam - normally quite bit of it.. I don't have mine enabled.. I create specific rules that log for stuff I want to see in the log.
edit: @stephenw10 creating an allow rule that doesn't care about state is not the way to do it, why would you even bring it up to someone that doesn't understand how a stateful firewall works? Then they will think that is normal practice.
And true as you state it will just be blocked by the end point.. Endpoint isn't going to do anything with a Fin,Ack.
-
Ok. I had created a pass rule because I didn't think I needed to block that traffic. So you are saying that if its a block rule with logging disabled then the default deny rule would not match it anymore?
The allow rule I have in place now is just below the allow for admin panel and the 2 deny rules for pfblocker.
-
@djtech2k you have an allow rule - its not an allow rule thing.. Allow rules only allow SYN..
If I don't want to log deny from say 192.168.9.100 I would create a rule like this
All traffic not allowed by your any any rule would fall thru, the deny would say oh the source is 192.168.9.100 - don't log this.. If say 192.168.9.200 fell through the allow because there is no state, then it would be logged by the default deny.
Rule are evaluated top down, first rule to trigger wins, no other rules are evaluated.. Currently anything not allowed by your allow rule(s) end up hitting the default deny before they match.. So they are logged, if you place a deny rule that would match their traffic that doesn't log then that noise wouldn't be logged.
-
Ok. So in order for this to work, it has to be a deny rule. So is there no way possible to allow the traffic? I mean I don't care about this instance that much but I am just trying to understand just as much for the future. I guess I don't get why it cannot be allowed if I really wanted it to be.
-
@djtech2k why would you want to allow traffic that is NOT going to do anything - your just sending packets out your internet connection for ZERO anything other then using up your bandwidth and throwing your noise out to the internet.
-
Now that I think about this, I don't think I would want to create a deny rule on all traffic going to port 443 for the Roku devices. I am sure they would stop working. There are too many destination IP's to list them all at this point.
-
@johnpoz Fair enough, I do not care about the traffic that is not useful. I am really more so trying to understand how to deal with theses kinds of circumstances moving forward.
-
@djtech2k what part do you not understand about this any any rule you have????
The 2nd one is pointless to be honest.. Since your first one would match anything.. And sending it out the specific wan via a gateway policy is only going to prevent you from talking to some other local network you might have?
