• I'm a bit confused about DMZ firewall rules. In regards to the order of rules do I want the rule that blocks traffic to be at the bottom or top of the rule set? Do I need a rule that blocks traffic at all? Or is all traffic implicitly blocked unless I let it through?


  • Rules are matched from the top down, the first rule that matches wins, the rest don't get evaluated.


  • Each interface has a hidden Default Deny rule that you can envision as being at the very bottom of the list.  If no rules above it apply then the traffic is blocked.


  • 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?

  • Banned

    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.


  • @jahonix:

    @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.

    Yea, this is what I wanted to do originally.


  • @Atreides:

    So, this better?

    Doesn't my earlier post above accomplish that?


  • It does.
    Don't know what problems KOM had with it, I'd do it that way.


  • @jahonix:

    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.


  • @KOM:

    …If you only have the LAN and DMZ ...

    @Atreides:

    Well, I have many subnets…

    He doesn't and he told us.
    No need to complicate things with what could happen in the future. KISS.


  • 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.


  • This way, I have one rule that will cover anything I make in the future. If I were to specifically cover each subnet that would mean every time I add a VLAN or subnet I have to worry about forgetting to block it. I would much rather play it safe with a single rule and selectively whitelist anything I want through the firewall. How is it complicated?

    If I have a VLAN that I want to be able to access something in the DMZ, I just make to single rule for that IP or network, which is what i've currently done. It's much safer to whitelist everything I want to let through then blacklist everything I want blocked anyway.

    Yes, either way would work but I think I prefer this way. Thanks for the help.


  • How is it complicated?

    It just depends on your point of view and how you work, that's all.  Both methods will work.  For me, I would never forget to secure a newly-added subnet, but I might easily forget that I blocked all of private IP space in a blockrule made potentially months or years ago.

    I'm glad you have it working the way you want.