Blocking traffic between networks
-
different concepts used in pfsense than what i am used two in the Linux firewall products I have used for the past decade. Why a /8? It's jsut a CIDr I chose. NO I do not have 17 million devices but I jsut wanted to make sure I never had an ip conflict..:)
So ANY is the Internet? That's different.
-
WAN is not the internet. WAN is the WAN subnet. any is the internet.
With so few interfaces I would stick with interface rules and forget the group rules and the floating rules - at least for now.
They make it much harder to visualize what you are doing and vastly more difficult for people to help you. Start with two interfaces and move on from there. It might be a little more work but it will make a lot easier to see exactly what you are doing.
so this ruleset will block guest connections to the wan but allow access to the internet? I am going to assume yes..:) I also see the rule allowing the use of pfsense as the dns resolver. Let me try this.
-
"Why a /8? It's jsut a CIDr I chose."
Bad choice that is for sure.. Just plain Borked!! Plain and simple.
-
You can use a /8 sure but if you ever decide to split that into multiple segments you're in for an unpleasent reconfiguration of the existing network. Also if you ever need to connect a VPN tunnel to a place that uses a 10...* subnet you're in for some real trouble. Use a /24 just like everybody else is using, least amount of hassle. Pick something else than 10.0.0.0/24 though, that is guaranteed to clash with something. A 10.x.y.0/24 where x and y are random numbers is a good choice.
-
At the risk of repeating myself, if you are renumbering just stay away from anything in 10.0.0.0/8 entirely.
Even if you use 10.rnd.rnd.0/24 you will still collide with everyone else who, like this, thought using 10.0.0.0/8 was a good idea.
Same can be said about 192.168.0.0/24, 192.168.1.0/24 and, thanks to sonicwall, 192.168.168.0/24.
-
All valid points about possible overlap/conflict with other networks on a vpn, etc. There is also the point that you would never ever ever put 16mil hosts on the same layer 2. So it makes zero sense to use such a mask on an actual interface.
/8 works great for a summary route, or even a firewall rule, etc. But on an actual interface just points to someone without clue 1 to networking in general.
-
Just an idea
Add all of the lan networks to an alias, and then have a floating rule that allows all traffic that is NOT (inverted) going to the alias destination?
-
Don't "block" traffic with pass rules.
-
You have said that quote a few times derelict.. I don't agree.. He is not blocking with an inverted rule, your just not allowing.. The default deny on the end is what blocks ;)
A ! rule to allow access to internet how is that any different than a block to your networks above an Any?
-
Because you are not blocking traffic. You are passing it.
If you want traffic between interfaces blocked, block it.
If you want to pass certain traffic and rely on the default deny rule that is fine, but using ! rules to accomplish that makes the rule set difficult to read for both humans and pf.
Evidence here: https://redmine.pfsense.org/issues/6799
-
"If you want traffic between interfaces blocked, block it."
You are the ! rule is just allowing traffic to the internet or whatever the opposite of your dest is..
So I put
allow ! rfc1918.. This allows traffic to the internet.. It doesn't block anything.. It allows traffic to something other than rfc1918.. If going to an rfc1918 address that rule is not triggered and go to the next rule, etc. If the traffic is NOT allow then it hits the default deny and is blocked.
How is that not better than leaving an any any rule at the end to allow traffic to the internet? That bug is related to a VIP.. Use of a VIP on a lan side interface seems pointless to me.. In what context would you be using a vip on a lan? Other than running multiple layer 3 on the same layer 2 which is just plain borked..
As to reading the rule set.. Seems pretty easy to me to read the !.. If you want to put specific block above the ! rule to specifically block traffic sure ok.. Have it, it seems just adding more rules than is actually needed to get the outcome you want.. If pf has a problem reading ! rules, then it should be pulled from the ability to even create them ;)
If human needs help understanding the rules - put in a description.. I have for example this on my ! rfc1918 rule. "Anywhere but local Networks ipv4" That is pretty freaking clear ;) hehehe
To do the specific block I would need block rfc1918, then below that either an allow any, or my allow rules for what I want, or an allow ! rfc1918 to be able to use the internet. Because if its not allow it will be blocked by the default deny at the end, etc.
I hear you and agree with the statement that an explicit block is exactly that. And I agree my ! rfc1918 allows traffic. But it only allows to where I want the traffic to go.. Which is what every allow rule is. And either need a rule like mine or an any rule to allow traffic out to the internet.. So how exactly are you allowing traffic to the internet.. Your either doing allow any.. or using an invert of your local networks.
So in your example I should have to do
block rfc1918
allow ! rfc1918
"default deny"This seems like putting in a rule for no reason just to deny access to my other networks.. Or even worse yet if do not use aliases for my network and put in every single segment as block before I do my allow ! rfc1918 anyway.. Which is better then an allow any wouldn't you say?
Only reason I could see for putting in such an explicit block would be if I wanted to log traffic to rfc1918 address.
Can agree to disagree I guess. I think your way is just extra work and extra rules - that to me make it harder to evaluate a rule set when there are more of them, than when there are fewer of them to run through.
-
This originally came up because pfBlocker adds this:
10.10.10.1/32 LAN IP Alias pfB DNSBL - DO NOT EDIT
I do not know why he chose to put that on LAN and not localhost. Probably has a good reason.
I would:
reject rfc1918
allow any
"default deny"That is another reason to use an explicit block rule, to get the reject feedback to local users.
Sorry I just do not like the ! rules. It just feels sloppy and lazy to me.
-
Don't be sorry that is for sure.. Just one of those things we are not in total agreement on.. Most of the time I am right with you on everything..
But in this instance while you think its sloppy and lazy, I see it as extra rules for no reason ;) heheeh
Reject is a good reason to do that sort of rule - this for sure I will agree with. But I have found that end users are not looking at sniffs to figure out why something is not working to reject while it might speed up an error in the end application vs waiting for tcp timeout after retrans, etc. Rejects don't always solve the issue. And then again if you got some application that is banging at your door.. Why do the extra work of a reject, etc.
if I wanted the reject or a log then sure I would do the explicit, but vs the any I would do an allow ! rfc1918. To me this is the rule closest I can get to the actual rule I want. I don't want a allow any rule. I want an allow to NOT rfc1918 address ;)
If your not doing the reject or a log.. Then your block rule and then allow takes two rules. While my way accomplishes the same thing with 1 rule - where you say sloppy and lazy I say elegant and efficient - hehe
