Confused with rules "direction" in/out meaning ?

[GiantJack]

Hi!

I am a bit confused with this "direction" field in firewall rules.

I currently have a VLAN (for guests) and a LAN.

I wanted to set some rules to isolate guests from LAN so I set the following rules (attached pic) in the VLAN section of the firewall.

If I try to access LAN from Guest, rule 1 blocks the traffic
If I try to access Guest from LAN, rule 3 blocks the traffic

Rules 2 & 4 are kind of not used.

When looking at the manual, I made the following understanding:

So because I set all those rules on my VLAN interface section of the firewall:
- vlan to lan is "in"coming to the firewall from VLAN interface (and so blocked by rules 1)
- lan to vlan is "out"coming of the firewall (from LAN) toward my VLAN (and so blocked by rules 3)

And my rules 2 & 4 could be used if I moved them to LAN section of firewall instead of VLAN ?

In case I would move rules 2 & 4 to LAN interface section of firewall
rules 2 would be traffic "out"coming the firewall from vlan to lan and so would block connexion attempt from VLAN to LAN
rules 4 would be traffic "in"coming the firewall from LAN to VLAN and so would block connexion attempt from LAN to VLAN.

Does it sounds correct ?

Does my rules 2 & 4 have any kind of mind currently placed in VLAN section? I was not able to figure out what it does exactly.

[hbc]

Usually you just block incoming traffic on an interface.
So on interface vlan_guest block incoming traffic from lan and on interface lan block incoming traffic from vlan_guest.

Blocking outgoing traffic is uncommon and mostly used in floating rules or wan e.g. to prevent RFC1918 addresses to leave wan.

[GiantJack]

Ok but is this statement correct:

block "out" src "lan net" to dest "vlan net" (inside vlan firewall section)
is similar to
block "in"  src "lan net" to dest "vlan net" (inside lan firewall section)
?

I understand that it's "best practice" to use mainly "in" rules at right place; but I also try to improve my understanding 

[hbc]

Yes, it's the same, except that the in rule needs less processing.

Imaging you have NAT, ad filtering, IPS, routing etc. With outbound filtering everything is processed, cpu consumed an then the packet is discarded due to an out blocking rule.

So better block it incoming and save the packet processing.

[franco]

One special case to consider is policy routing which only works on "in" direction to select the "out" direction interface. "out" filtering can be useful for catch all type rules where you didn't care about the origin, a bit like floating/group rules but with more processing overhead as hbc mentioned.


Cheers,
Franco

[GiantJack]

Thanks for clarifications! 

policy rules: I assume you mean for example rules to set a specific gateway ?

I think it's all clear for me now.
I will try to keep rules on the good side for processing but I may consider a few "out" ones if it's more clear to me to keep rules on the same interface section (if it's for sporadic traffic).

[chemlud]

.... to me to keep rules on the same interface section (if it's for sporadic traffic).

Do you have an example what you mean by this?

[GiantJack]

.... to me to keep rules on the same interface section (if it's for sporadic traffic).

Do you have an example what you mean by this?

Please see attached a couple of firewall rules inside the "VLAN22" section of my firewall.
Rules1: blocks any traffic incoming in firewall from VLAN22 to LAN
Rules3: blocks any traffic outgoing of firewall from LAN to VLAN22.

So traffic is blocked in both direction to isolate VLAN22 from LAN and LAN from VLAN22.

if I all understand correctly, rules3 could be alternatively placed in LAN section of the firewall in this way:
AltRules3: blocks any traffic incoming in firewall from LAN to VLAN22

"Alt rules 3" use less CPU before it's blocked at firewall input, before processing.

On the other end, In my situation, I see limited risk of heavy traffic from my LAN to try connecting on VLAN22, so the CPU impact should be low.
So it may be more convenient to have all the VLAN22 related rules in VLAN22 section of firewall instead of spread rules between VLAN & LAN (my LAN section already has a long list of rules).

let me know if anything sounds wrong or unclear.

[GiantJack]

@chemlud, hello,

Did you had any concerns with this ?

[shallpion]

So I was confused by this for a long long time too and until recently I came upon your post and the following discussion. I did some experiment by dumping the pf command on my set up (identical to you, a LAN and a guest VLAN) and I think what @hbc said in the first reply is very correct: out is almost only used in blocking outbound traffic from WAN port.

In short: in or out is relative to the firewall box itself, not the specific interface the rule is set on. Therefore if you are playing with rules blocking between your LAN and another VLAN, "out" will never be matched since the traffic does not go out of the firewall itself.

Here is a quote from "Building firewall with OpenBSD and pf" and hope it can clarify the confusion:

8.1.3 Inbound or Outbound (in, out)?

The next required keyword that appears after either the block (followed by optional drop, return-icmp, return-icmp6, return-rst,or return keywords) or the pass keyword is the direction keyword.There are two direction keywords you can use: in or out. They are known to cause some confusion, especially when the firewall is equipped with more than one network interface, and when NAT rules are used along with filtering rules.The key to understanding when a packet matches either the in or the out rule is remembering that these directions are relative to the firewall itself. Ifa packet is sent from an external host to the firewall, it matches the in rule on the firewall external interface; when it is sent from the firewall itself, it matches the out on the external interface. Similarly, packets sent from internal hosts to the firewall and destined to external hosts will match in rules on the interface connecting your private network segment to the firewall and out rules on the firewall external interface.