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

[SOLVED] Curious Floating Rules Behavior

Scheduled Pinned Locked Moved Firewalling
45 Posts 5 Posters 8.5k 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
    Derelict LAYER 8 Netgate
    last edited by Nov 22, 2017, 1:31 PM

    See there you go again. Can you not read? We are both saying that OUT is RELATIVE TO THE INTERFACE. You keep bandying about this nonsense about "egress outbound traffic."

    Please define "egress outbound traffic" so everyone knows wtf you are talking about.

    There is a diagram in my signature. Use that as a reference when you describe it.

    It is per interface, nobody has ever said any different.

    Chattanooga, Tennessee, USA
    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
    Do Not Chat For Help! NO_WAN_EGRESS(TM)

    1 Reply Last reply Reply Quote 0
    • K
      Kryptos1
      last edited by Nov 22, 2017, 1:35 PM

      @Derelict:

      See there you go again. Can you not read? We are both saying that OUT is RELATIVE TO THE INTERFACE. You keep bandying about this nonsense about "egress outbound traffic."

      Please define "egress outbound traffic" so everyone knows wtf you are talking about.

      There is a diagram in my signature. Use that as a reference when you describe it.

      It is per interface, nobody has ever said any different.

      Gotta go to work, but Ill respond tonight/tomorrow. I feel like Bill Nye debating Ken Ham with comments like "Can you not read?".

      1 Reply Last reply Reply Quote 0
      • J
        johnpoz LAYER 8 Global Moderator
        last edited by Nov 22, 2017, 1:44 PM Nov 22, 2017, 1:36 PM

        "Specifically, citing "green  is outbound (egress).." is a total contradiction to the drawing you posted. That green arrow is not "OUTbound", it is OUTside relative the the LAN. "

        I suggest you research ingress and egress.  These are standard networking 101 terms that if you do not grasp your going to have a hard time of it.

        edit:  Lets try it another way.  A nic or even a port on a switch is like putting a door on a house..  With pfsense or the switch being the house.  If the traffic is going into the interface from the network it is ingress - your going into the house..  if the traffic exiting the nic towards the network then its egress (leaving the house)..

        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

        1 Reply Last reply Reply Quote 0
        • D
          Derelict LAYER 8 Netgate
          last edited by Nov 22, 2017, 1:40 PM

          Good God, man. If there was confusion before you have only compounded it.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 0
          • J
            johnpoz LAYER 8 Global Moderator
            last edited by Nov 22, 2017, 1:59 PM

            Here maybe this video will help ;)

            https://youtu.be/u-rkp7iuJ_w

            picfromvid.png
            picfromvid.png_thumb

            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

            1 Reply Last reply Reply Quote 0
            • D
              Derelict LAYER 8 Netgate
              last edited by Nov 22, 2017, 2:27 PM

              Even that video confuses outside/inside.

              Unless you're talking about outside/inside the firewall.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • J
                johnpoz LAYER 8 Global Moderator
                last edited by Nov 22, 2017, 2:51 PM

                Outside is always the wire..  Connected to the nic/port..  When your talking ingress/egress to a port/nic

                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

                1 Reply Last reply Reply Quote 0
                • D
                  Derelict LAYER 8 Netgate
                  last edited by Nov 22, 2017, 7:32 PM

                  I disagree.

                  When talking outside/inside in a firewall context outside is untrusted and inside is trusted… in general terms. Toss in dmz as another branch if you like.

                  Everything on every interface is "on the wire" at some point. Outside/inside have special meaning.

                  Traffic/connections on a NIC is either received (inbound) or transmitted (outbound).

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • J
                    johnpoz LAYER 8 Global Moderator
                    last edited by Nov 22, 2017, 7:43 PM

                    "Traffic/connections on a NIC is either received (inbound) or transmitted (outbound)."

                    Well stated… But the wire that plugs into the nic is always 'outside" the device... Traffic is either put on the wire from the device, egress.. Or in to the device from the wired - ingress..

                    Agree you have to be clear on what context your talking with a firewall when you say outside inside.. But thought the question was in/out of an interface.. ingress, egress.. Where the rules apply - so the context seems to be clear..

                    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

                    1 Reply Last reply Reply Quote 0
                    • D
                      Derelict LAYER 8 Netgate
                      last edited by Nov 22, 2017, 8:19 PM

                      Clear to everyone except….

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • W
                        wussupi83
                        last edited by Nov 23, 2017, 12:49 AM Nov 22, 2017, 10:02 PM

                        @Kryptos1:

                        @Derelict:

                        No, it controls traffic in the outbound direction on that interface. It has zero to do with whether the interface is considered to be "inside" or "outside" as is generally referred to in firewall/ASA terms.

                        The second example in that test sheet confirms pfsense does not behave that way. Anyone can prove it to themselves by simply 1) starting with a factory install of pfsense 2), place two machines on two different interfaces, 3) create a floating rule specifying the LAN only (this is key because you're testing how pfsense processes OUT vs IN  packets), all Ipv4, enabled quick match, and action of drop, 4) on the OPT interface, create a normal rule under the interface tab to pass all traffic ANY to ANY (which ensures pfSense's default policy of drop doesn't interfere with the test). Then simply test all three directions (all, in, out) by passing a packets from the OPT station to the LAN and vice versa.

                        When testing the OUT direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they are OUT[side] relative the the LAN.

                        When testing the ANY direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they include packets that are OUT[side] relative the the LAN.

                        When testing the IN direction on the floating rule, packets originating from the OPT to the LAN station PASS - because they are not OUT[side] relative the the LAN (i.e. the rule simply doesn't apply).

                        Remember, the floating rule didn't even specify the OPT at all - thus "OUT[bound]" couldn't possibly be "OUT[bound]". The second test proves this, that the floating rule does not process packets as being "OUT[bound]" but rather OUT[side] (i.e. the direction of the packet relative to the interface that's been selected in the floating rule's config.)

                        "When testing the OUT direction on the floating rule, packets originating from the OPT to the LAN station DROP -because they are OUT[side] relative the the LAN."

                        • because they are passed from the OPT client to (INBOUND) the OPT interface and then routed to the LAN interface which sends them OUTBOUND to their destination. Because they are heading OUTBOUND from the LAN interface, they meet the OUTBOUND "drop" LAN floating rule criteria and are dropped.
                        [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO OUTBOUND PACKETS
                        &
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = PASS PACKET OUT (OUTBOUND) THE LAN INTERFACE BECAUSE MY LOGIC TELLS ME TO "PASS OUT" PACKETS  MEETING THIS RULE. 
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN (NET)           =    (OUTBOUND FROM THE LAN INTERFACE) = YOU MUST EXCLUDE LAN NET FROM SOURCE IN THE RULE TO AVOID THIS STEP. 
                        

                        "When testing the ANY direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they include packets that are OUT[side] relative the the LAN."

                        • same as above but will also drop packets originating from a LAN client heading to (INBOUND) the LAN interface.
                        [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO EITHER INBOUND OR OUTBOUND (ANY) PACKETS
                        &
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO EITHER EITHER INBOUND OR OUTBOUND (ANY) PACKETS
                        

                        "When testing the IN direction on the floating rule, packets originating from the OPT to the LAN station PASS - because they are not OUT[side] relative the the LAN (i.e. the rule simply doesn't apply)."

                        • because they are passed from the OPT client to (INBOUND) the OPT interface and then routed to the LAN interface which sends them OUTBOUND to their destination. Because they are heading OUTBOUND from the LAN interface, they do not meet the INBOUND "drop" LAN floating rule criteria and are passed.
                        [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = PASS BECAUSE RULE APPLIES TO INBOUND PACKETS ONLY, THIS PACKET IS OUTBOUND
                        &
                        [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO INBOUND 
                        
                        1 Reply Last reply Reply Quote 1
                        • K
                          Kryptos1
                          last edited by Nov 24, 2017, 11:49 AM

                          @wussupi83:

                          @Kryptos1:

                          @Derelict:

                          No, it controls traffic in the outbound direction on that interface. It has zero to do with whether the interface is considered to be "inside" or "outside" as is generally referred to in firewall/ASA terms.

                          The second example in that test sheet confirms pfsense does not behave that way. Anyone can prove it to themselves by simply 1) starting with a factory install of pfsense 2), place two machines on two different interfaces, 3) create a floating rule specifying the LAN only (this is key because you're testing how pfsense processes OUT vs IN  packets), all Ipv4, enabled quick match, and action of drop, 4) on the OPT interface, create a normal rule under the interface tab to pass all traffic ANY to ANY (which ensures pfSense's default policy of drop doesn't interfere with the test). Then simply test all three directions (all, in, out) by passing a packets from the OPT station to the LAN and vice versa.

                          When testing the OUT direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they are OUT[side] relative the the LAN.

                          When testing the ANY direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they include packets that are OUT[side] relative the the LAN.

                          When testing the IN direction on the floating rule, packets originating from the OPT to the LAN station PASS - because they are not OUT[side] relative the the LAN (i.e. the rule simply doesn't apply).

                          Remember, the floating rule didn't even specify the OPT at all - thus "OUT[bound]" couldn't possibly be "OUT[bound]". The second test proves this, that the floating rule does not process packets as being "OUT[bound]" but rather OUT[side] (i.e. the direction of the packet relative to the interface that's been selected in the floating rule's config.)

                          "When testing the OUT direction on the floating rule, packets originating from the OPT to the LAN station DROP -because they are OUT[side] relative the the LAN."

                          • because they are passed from the OPT client to (INBOUND) the OPT interface and then routed to the LAN interface which sends them OUTBOUND to their destination. Because they are heading OUTBOUND from the LAN interface, they meet the OUTBOUND "drop" LAN floating rule criteria and are dropped.
                          [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO OUTBOUND PACKETS
                          &
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = PASS PACKET OUT (OUTBOUND) THE LAN INTERFACE BECAUSE MY LOGIC TELLS ME TO "PASS OUT" PACKETS  MEETING THIS RULE. 
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN (NET)           =    (OUTBOUND FROM THE LAN INTERFACE) = YOU MUST EXCLUDE LAN NET FROM SOURCE IN THE RULE TO AVOID THIS STEP. 
                          

                          "When testing the ANY direction on the floating rule, packets originating from the OPT to the LAN station DROP - because they include packets that are OUT[side] relative the the LAN."

                          • same as above but will also drop packets originating from a LAN client heading to (INBOUND) the LAN interface.
                          [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO EITHER INBOUND OR OUTBOUND (ANY) PACKETS
                          &
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO EITHER EITHER INBOUND OR OUTBOUND (ANY) PACKETS
                          

                          "When testing the IN direction on the floating rule, packets originating from the OPT to the LAN station PASS - because they are not OUT[side] relative the the LAN (i.e. the rule simply doesn't apply)."

                          • because they are passed from the OPT client to (INBOUND) the OPT interface and then routed to the LAN interface which sends them OUTBOUND to their destination. Because they are heading OUTBOUND from the LAN interface, they do not meet the INBOUND "drop" LAN floating rule criteria and are passed.
                          [PFSENSE BOX]     OPT INTERFACE (ADDRESS)  <---     OPT CLIENT (NET)    =    (INBOUND TO OPT INTERFACE)
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)   --->    LAN CLIENT (NET)    =    (OUTBOUND FROM LAN INTERFACE) = PASS BECAUSE RULE APPLIES TO INBOUND PACKETS ONLY, THIS PACKET IS OUTBOUND
                          &
                          [PFSENSE BOX]     LAN INTERFACE (ADDRESS)  <---     LAN CLIENT (NET)    =    (INBOUND TO LAN INTERFACE) = DROP BECAUSE RULE APPLIES TO INBOUND 
                          

                          Hello wussupi83,

                          You nailed it. The green boxes show the area where everyone is trying to say the same thing using different terms. "Outside" to me is whatever is "plug[ed] into the nic is always 'outside" as cited by johnpoz; "Outside is always the wire.. Connected to the nic/port..". Derelict associates "outside/inside" to mean trusted vs untrusted. Whatever the case, In/Out under floating rules are directions relative to the interface.

                          OUT.png
                          OUT.png_thumb

                          1 Reply Last reply Reply Quote 0
                          45 out of 45
                          • First post
                            45/45
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                            This community forum collects and processes your personal information.
                            consent.not_received