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

"any" protocol not working with advanced inbound or outbound IP rules

Scheduled Pinned Locked Moved pfBlockerNG
8 Posts 5 Posters 918 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.
  • I
    IamGimli
    last edited by May 5, 2019, 11:59 AM

    I'm running pfSense 2.4.4-RELEASE-p2 with pfBlockerNG-devel 2.2.5_22.

    I have a few IP rules setup (both IPv4 and IPv6) and they're working, except that I need a few of the advanced ones to allow ICMP on top of TCP and UDP. Unfortunately, for a reason I don't understand, the "any" option in the protocol selection isn't supported for advanced rules. If I go and manually update the pfBlockerNG-generated rules to have "any" protocol after they'Re loaded it achieves what I'm looking for, without any bad effect that I can see. Unfortunately this gets reset every hour as the rules get updated.

    I know I could create manual rules to support it but then I run into a different issue where I use pfBlockerNG to block Geo IPs and I need that block to apply before manual rules, except for these specific boxes that I exempt using the advanced IP rules. Because of the way pfBlockerNG re-orders firewall rules every time it updates either all of my manual rules get exempted from pfBlockerNG's Geo blocking rules or none are.

    Ideally the advanced IP rules would either support "any" as a protocol or have an added option of "TCP/UDP/ICMP" (ICMPv6 for IPv6 rules).

    1 Reply Last reply Reply Quote 0
    • J
      johnpoz LAYER 8 Global Moderator
      last edited by johnpoz May 5, 2019, 12:35 PM May 5, 2019, 12:35 PM

      I would really suggest against use of anything that creates auto rules for you.. If your getting more complex then simple block rule on the top.. Your prob going to be better off just using the pfblocker aliases in your own rules... And don't create any auto rules with pfblocker at all. Just let it update its aliases that you use in your rules and forwards, etc.

      An intelligent man is sometimes forced to be drunk to spend time with his fools
      If you get confused: Listen to the Music Play
      Please don't Chat/PM me for help, unless mod related
      SG-4860 24.11 | Lab VMs 2.8, 24.11

      I 1 Reply Last reply May 6, 2019, 5:28 PM Reply Quote 1
      • I
        IamGimli
        last edited by May 5, 2019, 2:15 PM

        Huh! I hadn't thought of that but that just might be what I need to do. A little more handraulic than I like but results are more important.

        Guess I got a bit of experimenting to do. Thanks for the suggestion!

        1 Reply Last reply Reply Quote 0
        • B
          BBcan177 Moderator
          last edited by May 5, 2019, 2:35 PM

          @IamGimli said in "any" protocol not working with advanced inbound or outbound IP rules:

          Ideally the advanced IP rules would either support "any" as a protocol or have an added option of "TCP/UDP/ICMP" (ICMPv6 for IPv6 rules).

          At the bottom of each IPv4/6/GeoIP Alias is "Advanced Inbound/Outbound" firewall rule settings where you can pre-define those firewall rule settings. Auto-rules are ok but if you have more advanced firewall rules, you can always opt for "Alias Type" rules, and manually create the firewall rules accordingly.
          Click on the Blue Infoblock icon for the "Action" setting in the IPv4/6/GeoIP Tab for more details.

          "Experience is something you don't get until just after you need it."

          Website: http://pfBlockerNG.com
          Twitter: @BBcan177  #pfBlockerNG
          Reddit: https://www.reddit.com/r/pfBlockerNG/new/

          W 1 Reply Last reply Aug 17, 2020, 5:31 PM Reply Quote 0
          • I
            IamGimli @johnpoz
            last edited by May 6, 2019, 5:28 PM

            Thanks again for the recommendation to use manual rules with pfBlockerNG aliases, it's working great!

            It was also remarkably easy to setup, just copied the auto-generated rules that I needed, changing their description to remove the leading pfB_ and voilà! I was also able to rationalize a lot of the rules so overall the implementation is much cleaner and leaner.

            1 Reply Last reply Reply Quote 0
            • W
              wolfsden3 @BBcan177
              last edited by Aug 17, 2020, 5:31 PM

              @BBcan177 Sorry for necro posting but...I'm finding this annoying. I just went to add in a feed and it gave me these errors about me needing to create inbound and outbound rules, that I shouldn't choose "any", etc. So I had to go setup an alias for web ports like 443 and 80 EVEN THOUGH it's a white list that should allow ANY ports in or out. This is now restricting me and doesn't make things easy. I have to fart around and do source and destination ports. Source ports always change seemingly.

              The old versions of PFB didn't do this which is why it seems to "work" until I want to go edit a feed to "permit both". Then I get all kinds of errors about these rules.

              Why not just allow "permit both" from any to any port like it used to? I can't move on in life until I fart around with the port source and destination. This seems like you're making it more complicated than it needs to be. When getting the error it doesn't save my stuff.

              Can you bring back "simple" functionality? I probably now broke something with my global white list since destination ports can be anything not just port 80 and 443.

              Thanks.

              1 Reply Last reply Reply Quote 0
              • B
                Bob.Dig LAYER 8
                last edited by Aug 17, 2020, 5:48 PM

                This post is deleted!
                W 1 Reply Last reply Aug 17, 2020, 6:05 PM Reply Quote 0
                • W
                  wolfsden3 @Bob.Dig
                  last edited by Aug 17, 2020, 6:05 PM

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    [[user:consent.lead]]
                    [[user:consent.not_received]]