-
In that case, I was trying to set up a DMZ following instructions from here. Would this be working correctly as a DMZ? I want to be able to access the internet from the DMZ but have no access into any of my subnets. Do I need to change anything? I attached my rules below.
wrath and lilan are hosts where wrath needs to access an NFS share on lilan. RFC1918 is 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8.
-
Considering how firewall rules are processed top-down first-match, your last rule will never hit since rule #4 allows all access to anywhere (including LAN). Here is how I do it. My DMZ servers need to talk to our LAN-based Zabbix server, and they need to get DNS from LAN, too.
-
Oh I see, I have been thinking about it backwards? When people say the rules are top down I thought that would mean that the last thing to be read would be the bottom, in my case blocking RFC1918. Instead I should be thinking about it based on priority? So the rules higher up are the rules that will be respected?
-
First match wins (except for floating rules).
-
So, this better?
-
I suspect not, if your pfSense DMZ interface is part of RFC1918. Why not get rid of your last two rules and then just copy my last rule?
-
Well, I have many subnets… I guess I could block them all, but wont that be the same as I currently have?
-
Here's what i ended up with:
-
Still no good. Your 4th rule allows all access to anywhere. Delete it entirely.
-
You have lots of "allow BUT" rules, the ones with "!". Doesn't make sense.
Either make them block that range OR make them allow it but NOT "allow all but…" -
@KOM:
… just copy my last rule?
Problem is that it works but is harder to follow than need be.
Blocking something with an allow rule seems … strange.Better use one rule first to explicitly block * to LAN
Add another rule to allow * to world. -
-
-
It does.
Don't know what problems KOM had with it, I'd do it that way. -
It does.
Don't know what problems KOM had with it, I'd do it that way.Great! That is why I was confused. I'll try that.
Thanks everyone.
-
Your first ruleset allowed access everywhere before the LAN block. Your second ruleset has you blocking all private IP space and not just LAN. Your 3rd ruleset allowed everything before the blocks.
Second ruleset would do the job but the block is overly broad, and this can potentially impact you down the road if you add any interfaces or VLANs.
-
@KOM:
Your first ruleset allowed access everywhere before the LAN block. Your second ruleset has you blocking all private IP space and not just LAN. Your 3rd ruleset allowed everything before the blocks.
Second ruleset would do the job but the block is overly broad, and this can potentially impact you down the road if you add any interfaces or VLANs.
How so? The DMZ shouldn't have access to any other VLANS/interfaces.
-
How so? The DMZ shouldn't have access to any other VLANS/interfaces.
Sure, until you add one for some reason and then need access from DMZ to LAN (for custom DNS, for example) and can't figure out why things aren't working. If you only have the LAN and DMZ then you could just as easily used LAN net instead of your RFC1918 alias.
-
-
No need to complicate things with what could happen in the future. KISS.
Precisely, which is why when you want to block access specifically to LAN, you block access to that LAN's subnet and not all of RFC1918 space. Right now, he's got 5 subnets with a total of ~1200 addresses being handled by a blockrule that targets ~18 million addresses. While I also hang my hat on KISS, I fail to see how using an RFC alias with 18 million addresses is easier than just using LAN net or ! local net.