• Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if you use block rules, you'll have to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default.

    Having to add the BLOCK ALL rule to the end of my firewall rules otherwise traffic on clients that are supposed to be blocked are making it through. I though before it had been blocked by default.
    I have been modifying the rules quite a bit over the last few days, but the inherent deny all that is supposed to be there doesn't seem to be working after a while.  When I do an upgrade, the default rule works again, but if I make some changes to the rules, the rule has to be manually added to the end.

    2.0-BETA5 (i386) built on Fri Jan 28 05:30:15 EST 2011
    Intel(R) Pentium(R) 4 CPU 2.40GHz; 40gb hd; 6 VLANs over onboard em nic

  • Rebel Alliance Developer Netgate

    The default deny block still works for me, you can post your /tmp/rules.debug file and perhaps something can be seen there that would show why it isn't working.

    Are you sure you don't have any thing on the floating rules tab or an interface group that might be overriding what you're trying to do?

    In addition to seeing the rules we'd also need to know the exact source and destination of the connection you say should be blocked, for comparison.

  • What ends up happening is when I try to reconfigure all the firewall rules on the lan interface, sometimes it all of a sudden lets clients that were normally blocked because of the deny rule (some of our point of sales computers, printers, etc) are then able to contact the internet.  A reboot doesn't fix it, I have to specifically add the deny all rule to the end of the list to deny those clients or do an update and then it is back working.  I wanted to figure out what exactly causes it, but I can't find an exact cause yet.  It just kinda randomly happens.  I have about 20 aliases that I use to cut down on how much crap is in the rule base.
    I am going to take a look at it more this week and see if I can come up with a reason.  I can also send you a few pics or a copy of my config to gain a better understanding of whats going on for the firewall.
    LOL, before I forget, this is the same computer I was getting the panics on for the em interface.  Haven't had a chance to load up the newest snap yet though to test out to see if it would crash, but that's a different topic.  ;D

  • The default block is applied first now in 2.0 not last as in 1.2.3.
    So if any of your rules matches that address than it will be allowed otherwise if no rules match at all it will not be allowed.
    Check even floating rules, if you have any, since they apply too if no direction(or direction in) specified.

  • Havent noticed the block all not working in latest snapshot,Noticed that the default listening sockets for the services ( ssh ,http ) are applied to the wan interface by default .

    hosts.allow is allowing everything also ,simple things but maybe they should only be listening on the lan interfaces
    as a default .

  • Rebel Alliance Developer Netgate

    They listen on all interfaces by default by design, access is granted by firewall rules. It's always been that way.

  • Thanks

  • I think what I am trying to explain may be getting misinterpreted.  Lets try an example.
      I am saying that if I had a network with a wan and a lan only.  IP range is  The pf sense box is  Delete the inherent pass any/any rule.  I set up only a pass rule for for it to access any ip only using ports 53, 80, and 443 (alias of "web access").  I then set up another rule for with a pass http to insert some random ip address.  Another rule from to any using port 53, 80, and 443 (using the "web access") titled "the server".  Traffic works from said clients.  Traffic doesn't not seem to work from not specified clients.
      If I understand the rules base correct, the rules I have specified should only be the ones contacting the web right?  the other clients should naturally be blocked since there is no rule specified for them, but what ends up happening is when I rearrange any of the above rules, all of a sudden the unspecified clients are now able to contact the web and I have to add a block any/any.

  • Please put some proof behind this.