Question Regarding Default Deny Rules
-
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?
-
@djtech2k said in Question Regarding Default Deny Rules:
to deal with theses kinds of circumstances moving forward.
What blocked out of state traffic you do not want to see? Again turn off the default deny logging and you will never see any of this noise..
-
@johnpoz said in Question Regarding Default Deny Rules:
@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?
The reason that top allow rule works was specifically for my VPN. There are times that I might want specific devices to go out to the internet over a VPN service. So I have NAT rules and FW rules so that if I add a device to a certain alias, then it will use the VPN gateway, while all others will go straight to the internet. The NAT and FW rules were how I was able to get it to work.
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k said in Question Regarding Default Deny Rules:
to deal with theses kinds of circumstances moving forward.
What blocked out of state traffic you do not want to see? Again turn off the default deny logging and you will never see any of this noise..
I am not yet ready to turn off all the default deny logging because it is still so new that I want to watch some of the traffic and be able to look into connectivity issues if they happen. This is more because I am only a couple days into using it on this network. I will likely disable the default deny logging at some point, just not yet.
So if I were to create a deny rule to block the Roku logging, what would it look like? I see the traffic as coming from my roku devices with multiple destination IP's, all going on port 443. I can't just block everything on port 443. Is there another way to get a match to disable the logging?
-
@djtech2k not talking about your vpn with source IPs - I am talking specific about the any any that allows traffic and sends it out your wan_dhcp gateway.. That is more than likely going to just prevent you from talking to other networks you have local.
And a any for the source other than being lan subnets would only make sense if this interface was being used as a transit network - why would devices be sending traffic to pfsense lan IP, if they were not on your lan subnet.. And lets say they did - they wouldn't be natted, unless you specific setup a outbound nat rule.
Policy routing can be useful - but in your setup doesn't make a lot of sense to have a any any with * for source and then another allow rule with lan as subnet as source.
Again rules are evaluated top down, first 1 to trigger wins and no other rules are evaluated.. Please give a scenario of traffic where your traffic would not match the any any rule on ipv4 that you send out your gateway.. But then match your 2nd rule that is also any any but only from your lan network?
That might make sense if they were opposite where the lan source was above the * source if you were wanting to allow stuff to your other local networks, ie not send it out your wan. But have the * as source makes no sense unless it was a transit network - and putting devices ie the other stuff on lan just leads to possible asymmetrical traffic flow..
-
It would be at the end of the LAN rules list so that only traffic not already passed would ever hit it.
New connections from the Roku alias would be matched and passed by the existing rules above it.
When the Roku tries to send a TCP:FA flagged packet and pfSense has already closed the state it doesn't match any of the pass rules but will match the custom block rule. Hence it will be blocked as it is now but without logging.
And, yes, I agree with @johnpoz passing the flagged traffic is not the solution here. I blame the cold/flu meds!
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k not talking about your vpn with source IPs - I am talking specific about the any any that allows traffic and sends it out your wan_dhcp gateway.. That is more than likely going to just prevent you from talking to other networks you have local.
And a any for the source other than being lan subnets would only make sense if this interface was being used as a transit network - why would devices be sending traffic to pfsense lan IP, if they were not on your lan subnet.. And lets say they did - they wouldn't be natted, unless you specific setup a outbound nat rule.
Policy routing can be useful - but in your setup doesn't make a lot of sense to have a any any with * for source and then another allow rule with lan as subnet as source.
Again rules are evaluated top down, first 1 to trigger wins and no other rules are evaluated.. Please give a scenario of traffic where your traffic would not match the any any rule on ipv4 that you send out your gateway.. But then match your 2nd rule that is also any any but only from your lan network?
I get what you are saying. Honestly, the any/any rule is the default rule and I left it there. When I started configuring pfsense, I left it there and when I was trying to get the VPN to work as I described, I had to add the rule with the WAN gateway specified because I have an outbound NAT rule for the VPN GW. I did not intentionally leave the default allow any/any rule there fir any specific purpose other than I didn't want to disable the default rule. I suppose I could test disabling/removing one of those rules.
-
@stephenw10 said in Question Regarding Default Deny Rules:
It would be at the end of the LAN rules list so that only traffic not already passed would ever hit it.
New connections from the Roku alias would be matched and passed by the existing rules above it.
When the Roku tries to send a TCP:FA flagged packet and pfSense has already closed the state it doesn't match any of the pass rules but will match the custom block rule. Hence it will be blocked as it is now but without logging.
And, yes, I agree with @johnpoz passing the flagged traffic is not the solution here. I blame the cold/flu meds!
Ok, so if I understand you correctly, you are saying a rule that blocks the roku devices outbound on port 443 placed at the very bottom would not block the "needed" roku traffic and it would only block the TCP:FA flagged traffic, which you are saying is unneeded anyway?
-
Yes, exactly!
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k not talking about your vpn with source IPs - I am talking specific about the any any that allows traffic and sends it out your wan_dhcp gateway.. That is more than likely going to just prevent you from talking to other networks you have local.
And a any for the source other than being lan subnets would only make sense if this interface was being used as a transit network - why would devices be sending traffic to pfsense lan IP, if they were not on your lan subnet.. And lets say they did - they wouldn't be natted, unless you specific setup a outbound nat rule.
Policy routing can be useful - but in your setup doesn't make a lot of sense to have a any any with * for source and then another allow rule with lan as subnet as source.
Again rules are evaluated top down, first 1 to trigger wins and no other rules are evaluated.. Please give a scenario of traffic where your traffic would not match the any any rule on ipv4 that you send out your gateway.. But then match your 2nd rule that is also any any but only from your lan network?
That might make sense if they were opposite where the lan source was above the * source if you were wanting to allow stuff to your other local networks, ie not send it out your wan. But have the * as source makes no sense unless it was a transit network - and putting devices ie the other stuff on lan just leads to possible asymmetrical traffic flow..
Just for reference, here are my outbound NAT rules. Again, these rules and the LAN FW rules in the other pic are what I created specifically for the VPN. Maybe I did it incorrectly or could do it better but that's how I was able to get it to work. There were some docs online that talked about doing the inverse of what I wanted so I tried to implement the inverse of their solution.
