Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Firewall rule not working

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 3 Posters 4.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      MarkVLK
      last edited by

      Hi all,

      I created a few rules in my pfSense firewall to block traffic that Snort showed as behaving suspiciously.

      However, it seems as though my firewall rules aren't being enforced as I'm still getting Snort alerts from these source IPs fairly often.

      Am I doing something wrong with the firewall rules, or why is this traffic still reaching my network?

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        Firewall rules let you choose what passes between interfaces.  A firewall rule can't stop traffic from hitting your WAN.  All traffic not specifically allowed by a rule is dropped by default, but it still hits the interface and gets logged.

        1 Reply Last reply Reply Quote 0
        • M
          MarkVLK
          last edited by

          @KOM:

          Firewall rules let you choose what passes between interfaces.  A firewall rule can't stop traffic from hitting your WAN.  All traffic not specifically allowed by a rule is dropped by default, but it still hits the interface and gets logged.

          Thanks for the quick and simple explanation! I guess I'm more of a noob than I realized… More learning to do.

          How do the pfBlocker rules work in that case then? I see on my dashboard that dozens of packets match the pfBlocker rules (and are presumably blocked) every day. Is that just because they're in my LAN outgoing rules as well or is there something else pfBlocker is doing in the background?

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            I don't use pfBlocker, but as far as I know, all it does is setup aliases and firewall rules to block specified IP address ranges that supposedly define a country's IP space.  So, if you have a rule that allows people to get to your DMZ web server from WAN, the pfBlocker rules will block all packets coming from the banned IP ranges.  The traffic still hits your WAN, but the firewall rules prevent any further action.

            1 Reply Last reply Reply Quote 0
            • M
              MarkVLK
              last edited by

              @KOM:

              I don't use pfBlocker, but as far as I know, all it does is setup aliases and firewall rules to block specified IP address ranges that supposedly define a country's IP space.  So, if you have a rule that allows people to get to your DMZ web server from WAN, the pfBlocker rules will block all packets coming from the banned IP ranges.  The traffic still hits your WAN, but the firewall rules prevent any further action.

              Ah ok, makes sense!

              pfBlocker does indeed create aliases and then apply rules to one or more interfaces depending on what settings you choose, but it does much more than blocking a country's IP space! You can have it get lists of CIDRs and block those specific IPs, so for example I have mine set up to block all the IPs in the DShield.org Recommended Block List (http://feeds.dshield.org/block.txt) as well as another list that's updated daily of top spammer and malware IPs which blocks an additional 2,000-3,000 IPs and rejects packets going to those destinations from LAN which is nice.

              I'm actually glad you mentioned the DMZ example though because I've been having trouble getting my Wii U to keep steady connections to Mario Kart online through DMZ… Makes me wonder if it's because I don't have any rules set to allow packets from WAN -> DMZ, only have rules that allow packets from DMZ -> *

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by

                Since pfSense is a statefull firewall, you only need to implement a rule to allow the initiator to talk.  Responses will be automatically allowed.  As long as your Wii U can talk out, it should be able to get replies from Nintendo Online without specific rules.  Notice that you don't have to have a rule for every possible incoming connection.  There may be another issue causing your problem with that, but that's for another topic.

                1 Reply Last reply Reply Quote 0
                • V
                  viragomann
                  last edited by

                  @MarkVLK:

                  I created a few rules in my pfSense firewall to block traffic that Snort showed as behaving suspiciously.
                  However, it seems as though my firewall rules aren't being enforced as I'm still getting Snort alerts from these source IPs fairly often.

                  If Snort listens on WAN interface it acts any packet arriving there, no matter if they are matched by a firewall rule, and if it matches a Snort rule you can see it in the alerts.
                  If you don't want to see alerts of packets which match a WAN block rule, you may let listen Snort on DMZ or LAN interface.

                  1 Reply Last reply Reply Quote 0
                  • M
                    MarkVLK
                    last edited by

                    @KOM:

                    Since pfSense is a statefull firewall, you only need to implement a rule to allow the initiator to talk.  Responses will be automatically allowed.  As long as your Wii U can talk out, it should be able to get replies from Nintendo Online without specific rules.  Notice that you don't have to have a rule for every possible incoming connection.  There may be another issue causing your problem with that, but that's for another topic.

                    Yeah I guess I have more troubleshooting to do then for that separate issue. Thanks for the info though! Definitely helpful to better understand how the firewall works.    :)

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.