[SOLVED] Curious Floating Rules Behavior
-
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.
-
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?".
-
"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)..
-
Good God, man. If there was confusion before you have only compounded it.
-
Here maybe this video will help ;)
https://youtu.be/u-rkp7iuJ_w
-
Even that video confuses outside/inside.
Unless you're talking about outside/inside the firewall.
-
Outside is always the wire.. Connected to the nic/port.. When your talking ingress/egress to a port/nic
-
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).
-
"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..
-
Clear to everyone except….
-
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 -
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 INBOUNDHello 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.
