Navigation

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

    Gateway selection in rules

    Routing and Multi WAN
    3
    8
    2443
    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.
    • F
      frater last edited by

      I have a question about the order of executing rules…

      This line seems to leave no room for ambiguity... :

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

      I say it seems....

      It's clear to me that chosing "block" means traffic is stopped and no rule after that will get that packet going again.
      But if some rule sets the gateway to let's say "Loadbalance", subsequent rules will still be executed.
      I assume that rules that are changing the gateway will be ignored later on.

      I hope have clearly explained the "ambiguity" I am seeing.....
      From a developer's point of view (knowing exactly how pf works) I assume this ambiguity isn't there...

      I'm still having doubts about my setup and being new to pfsense I would like to know I'm correctly understanding it.

      I have 3 WAN-connections, 6 LAN's, 2 ISP's
      I've gathered the 6 LANs in an interface group.

      interface group:

      LANGROUP

      gateway groups:

      LoadBalance                    = all 3 WAN-connections in Tier 1
      LoadBalanceISP1              = 2 WAN-connections of ISP1 in Tier 1
      LoadBalanceISP1wFallback = 2 WAN-connections of ISP1 in Tier 1, WAN-Connection of ISP2 in Tier 2

      In the rules for interface "LANGROUP" I've defined the following rules

      #1    Traffic going to the network of ISP2 is using the ISP2 gateway (this rules can be improved)
      #2    TCP traffic going to port 25 of ISP1's SMTP-subnet is using "LoadBalanceISP1"
      #3    Traffic going to ISP1's complete subnet goes to "LoadBalanceISP1wFallback"
      #4    Traffic is directed to "LoadBalance"

      I can also set rules for several interfaces including interface groups. It is not clear what the order of rules is between these different interfaces...

      Thanks in advance....

      1 Reply Last reply Reply Quote 0
      • marcelloc
        marcelloc last edited by

        But if some rule sets the gateway to let's say "Loadbalance", subsequent rules will still be executed.

        No, they will not.

        Just like the description says "…Rules are evaluated on a first-match basis..."

        If you specify, for example, that http to google uses loadbalance, no other rule after that match will be checked.

        There is no "ambiguity".

        1 Reply Last reply Reply Quote 0
        • F
          frater last edited by

          @marcelloc:

          But if some rule sets the gateway to let's say "Loadbalance", subsequent rules will still be executed.

          No, they will not.

          Just like the description says "…Rules are evaluated on a first-match basis..."

          If you specify, for example, that http to google uses loadbalance, no other rule after that match will be checked.

          There is no "ambiguity".

          If so, it is working as expected….

          But let me explain why I see some ambiguity...
          I assume that rules after the rules dealing with gateway, for instance blocking some port are still being executed.....

          So as long as the gateway is not set, it can be set to a gateway or gateway group.
          If no gateway is explicitly set, the traffic will go to the default gateway.
          If a gateway is set, subsequent rules are executed, but the part setting the gateway is ignored (or are all actions of such a rule ignored?).

          I'm not trying to be a wise guy, I just want some confirmation if everything is going as I want it to.
          Thus far it is....

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            There really is no ambiguity.

            Rules are evaluated from the top down, first match wins. Gateway or not they behave the same way.

            If the rule has a gateway set, it goes out that gateway. No gateway set, it uses the default (or if it's a block rule, it gets blocked of course). That action has nothing to do with evaluation of other rules.

            The behavior is not any different if you do or do not have gateways on rules, it's always top-down first match wins (at least on the Interface tabs, Floating is another story)

            1 Reply Last reply Reply Quote 0
            • F
              frater last edited by

              so if I have this:

              #1  tcp traffic going to port 25 goes to loadbalance
              #2  tcp traffic going to port 25 to subnet 80.90.0.0/16 has to block

              rule #2 will never be executed?

              With netfilter (iptables) there are actions like 'DROP', 'REJECT' and 'ACCEPT' and these actions will stop the execution of rules in that chain.
              RETURN will go to the upper chain and LOG will continue….
              With netfilter it depends on the action if subsequent rules are getting executed.
              The order of the rules is important as well....

              As I said... I'm totally unfamiliar with 'pf'
              Knowing netfilter may be a handicap....

              1 Reply Last reply Reply Quote 0
              • jimp
                jimp Rebel Alliance Developer Netgate last edited by

                Correct.

                1 Reply Last reply Reply Quote 0
                • F
                  frater last edited by

                  @jimp:

                  Correct.

                  But if each match stops further execution of rules, isn't it much less flexible than netfilter?

                  And what's the order of rules between "Floating", "Interface" and "Interface groups"?

                  so if I have this:

                  #1  tcp traffic going to port 25 to subnet 80.90.0.0/16 has to be logged
                  #2  all traffic goes to loadbalance

                  This means that smtp-traffic to 80.90.0.0/16 gets logged and will go to the default gateway
                  all other traffic goes to loadbalance

                  I wouldn't have expected that, but I'm making the mistake to compare these rules with individual iptables rules and I should compare them to chains…
                  Please correct me...

                  1 Reply Last reply Reply Quote 0
                  • marcelloc
                    marcelloc last edited by

                    But if each match stops further execution of rules, isn't it much less flexible than netfilter?

                    No it's not. Just move block rule before allow and you will have all working.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post

                    Products

                    • Platform Overview
                    • TNSR
                    • pfSense
                    • Appliances

                    Services

                    • Training
                    • Professional Services

                    Support

                    • Subscription Plans
                    • Contact Support
                    • Product Lifecycle
                    • Documentation

                    News

                    • Media Coverage
                    • Press
                    • Events

                    Resources

                    • Blog
                    • FAQ
                    • Find a Partner
                    • Resource Library
                    • Security Information

                    Company

                    • About Us
                    • Careers
                    • Partners
                    • Contact Us
                    • Legal
                    Our Mission

                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                    Subscribe to our Newsletter

                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                    © 2021 Rubicon Communications, LLC | Privacy Policy