Floating rule meaning of source/destination with direction any
-
A question about floating rules for WAN interface:
With direction 'out' it's clear to me that 'destination' is a remote host that I'm trying to match, and with direction 'in' the 'source' is the remote host.
But what do 'source' and 'destination' mean with direction 'any' ?
I'd like to block traffic both to and from a remote IP with only one rule. Is this possible?
-
@henderbc said in Floating rule meaning of source/destination with direction any:
with only one rule. Is this possible?
Why is that? A extra rule, or shoot 1000 of them not going to be any sort of performance or extra load on pfsense.
It would be clearer to read if you made your rules specific as possible. But if the goal is blocking with 1 rule, I would think you would have to use aliases for your source and destination that allow for both of your scenarios..
I have never had a need or want to do such a thing. I would just create 2 rules, one on your ingress and other for your egress.
-
Why is that? A extra rule, or shoot 1000 of them not going to be any sort of performance or extra load on pfsense.
You are right, but there's more behind my question. I'm really trying to get my head around floating rules, and it seems to me that when direction 'any' is used, 'source' and 'destination' should rightly be reversed depending on whether the packet is outbound or inbound.
-
@henderbc any would be used in a specific scenario - say you wanted to make sure nothing was talking on port 23 for example.. If you made that destination port and then applied it to multiple interfaces with any direction.
Just because there is an option for any, does not mean it applies to your scenario.
or it could be used in just a tagging scenario where you wanted to tag traffic on port X be it entering or leaving an interface, etc.
Not all settings are going to apply for every scenario..
Such advanced rules - make them harder to interpret quickly, etc. Unless you have a very specific use case where doing in floating makes sense. Its best to create your rules on the specific interfaces. Floating to me would be used for an outbound rules, the only one that I have that it makes real sense to do floating and outbound is my rule that keeps from sending destination traffic to rfc1918 out the wan. Just being a good netizen and preventing noise from going into the internet.
Say I make a typo or something and hit 192.168.11.1 vs 192.168.1.1 - pfsense would send that out its default gateway if there was no rule in floating to block outbound to rfc1918. Since I don't have any local networks on 192.168.11.
Now I could do that inbound on all my different local interfaces - but that would be a pain to maintain all the rfc1918 space in an alias that I am specifically using vs just a common rule that I know I never want to happen - I have no scenario where rfc1918 would be destination leaving my wan.. etc..
-
Just because there is an option for any, does not mean it applies to your scenario.
So then in summary, would it be correct to say that when 'direction' is 'any', 'source' and 'destination' should always be set to 'any' because anything else would make no sense?
-
@henderbc not sure - it would depend on the exact scenario you wanting to accomplish..
But your scenario where you want to stop IP X from being source inbound to your wan, and you also want to make sure no outbound traffic is initiated to that IP either. It would seem to me the simple solution to that scenario would be to create multiple rules.
I would prob apply that scenario as inbound rule on the wan interface. And as an outbound rule in floating if you wanted to stop pfsense itself and clients.
If you just wanted to prevent clients behind pfsense from going there, might be better as inbound rule on the lan side interface(s)..
Any time you can prevent traffic from actually entering the firewall rule its a better setup. Why would you want to let traffic into your firewall, have your firewall process the traffic to just say oh wait a minute - you can not leave outbound on that interface.
But it all comes down to your specific scenario and what your wanting to allow or block, etc.. Being explicit as possible in your rules with min amount of possible confusion or thought needed for a human to evaluate what exactly that rule is doing is best.. KISS principle ;)
From a processing perspective - I would want to prevent unwanted rfc1918 from even entering pfsense in the first place - but this would be more work on my part ;) And the rule outbound on the wan interface in floating is very explicit - no destination to any rfc1918 space, etc. This is makes for less complexity overall in the rule set.
-
@johnpoz
OK - that makes things clearer. The onus is on me to make all the settings consistent with each other.Thanks!
