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

    Google Home and Mini snort2c blocks

    Scheduled Pinned Locked Moved Firewalling
    9 Posts 2 Posters 710 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.
    • D
      davparker
      last edited by

      I recently installed a Netgate firewall. I installed and enabled Snort initially. But I'm seeing traffic from a Google Home Hub & Mini outbound getting blocked. When this happens the Google Assistant can't respond. I created a fw rule to never block outbound from these devices to TCP/443. I also stopped Snort on the WAN interface, no other interfaces were configured. These IPs the Google devices need to communicate with keep getting added to the snort2c table. How do I prevent these IPs from continuing te get added to the snort2c table. I'd like to enable Snort again at some point, but first I need to be sure this traffic won't continue to get blocked.

      Thanks,
      David

      S 1 Reply Last reply Reply Quote 0
      • D
        davparker
        last edited by

        I ended up removing Snort. Even though I only had disabled all rules, deleted the interface, etc, it kept adding legitimate IPs to the snort2c block list. I had enabled a pass list, added the IPs there, still kept blocking. I even added outbound rules to permit traffic for those IPs, but still they kept getting added to the snort2c list. Uninstalling the Snort package resolved the issue. I may take another crack at it later.

        1 Reply Last reply Reply Quote 0
        • S
          SteveITS Galactic Empire @davparker
          last edited by

          @davparker Couple things for next time...

          Run Snort on LAN not WAN. It will log LAN IPs instead of the WAN IP. Snort runs outside the firewall so on WAN you will end up scanning lots of inbound traffic that your firewall will then drop.

          Run in alert only mode for a week or two so you can review the alerts, adjust rules etc.

          You can disable rules entirely, or suppress the alerts by source or destination IP.

          As you found, in legacy mode (the default) you can create a pass list to ignore the Google IP ranges if you can figure them out. PCs on LAN are in the internal pass list by default IIRC. Restart Snort on the interface to load the updated pass list.

          Firewall rules won't override the Snort block table.

          Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
          When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
          Upvote ๐Ÿ‘ helpful posts!

          D 1 Reply Last reply Reply Quote 0
          • D
            davparker @SteveITS
            last edited by

            @steveits Thanks, but I couldn't figure out why it was still adding IPs to the blacklist even after having alert mode only, deleting Snort on interfaces altogether and stopping the Snort process. I had no idea what process was deciding to blacklist IPs much less why. I could not prevent it from happening. I'll need to read up more before I attempt this again. It is quite a bit different than running Snort on a Firepower even though there are some similarities.

            S 1 Reply Last reply Reply Quote 0
            • S
              SteveITS Galactic Empire @davparker
              last edited by

              @davparker possibly, there was a second/zombie Snort process running? Itโ€™s been posted about before. For instance if watchguard is installed and it starts Snort during a Snort update/restart.

              Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
              When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
              Upvote ๐Ÿ‘ helpful posts!

              D 1 Reply Last reply Reply Quote 0
              • D
                davparker @SteveITS
                last edited by

                @steveits I've reinstalled Snort and have things setup again, in Alert mode. It appears that 120:3 "(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE" was responsible blocking IPs left and right. I've force-disabled that for now. I do have Snort enabled on the WAN interface. I don't want it blocking internal IPs. The setup examples I've come across so far indicate to monitor a WAN interface.

                S D 2 Replies Last reply Reply Quote 0
                • S
                  SteveITS Galactic Empire @davparker
                  last edited by

                  @davparker It won't block LAN IPs by default.

                  WAN is (was?) the default for a long time but look at posts by bmeeks, the package maintainer, discussing WAN vs LAN. It'll work on WAN, just with the caveats I posted above.

                  Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                  When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                  Upvote ๐Ÿ‘ helpful posts!

                  1 Reply Last reply Reply Quote 1
                  • D
                    davparker @davparker
                    last edited by

                    Actually, I am now running Snort on WAN & LAN. I plan on keeping the LAN in Alert mode, to collect data, I've enable Blocking mode on the WAN. All is good so far.

                    1 Reply Last reply Reply Quote 0
                    • D
                      davparker
                      last edited by

                      @steveits Thanks, that is good info. I may just do LAN entirely.

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