Firewall Rules Order

SteveITS

@katakuri a clientbon WAN would normally not connect to pfSense ..?

A packet arriving on WAN is essentially from the Internet.

The second VLAN needs no rule. The packet is exiting that interface.

No need for ICMP on the parent that is separate.

once a firewall rule passes a packet is it clear to go wherever it might be bound for?

Yes. Once in the house it can leave via any door. Rules on the way in tell it which door.

katakuri

And so, by that same logic, does that mean that external internet traffic matches the firewall rule for the WAN interface? E.G., if I want to allow a port into my network I would put the rule on the WAN port? Does that also follow the rules above? A packet arrives from the internet, goes through Floating rules, then the WAN port, and if it passes then it moves on.

I think I was misunderstanding the WAN port in this context, I was thinking of the WAN port as where traffic going out originates.

So I can allow internet traffic into my network using Floating or WAN rules? I didn't expect that.

katakuri

@SteveITS said in Firewall Rules Order:

@katakuri a clientbon WAN would normally not connect to pfSense ..?

I don't know what that means - are you saying internal client traffic should not originate on the WAN port? If so I think that's what I was not understanding. I was thinking about WAN from the perspective of a packet leaving the network.

SteveITS

*a client on WAN
--my typo

@katakuri Firewall rules apply as a packet arrives on an interface. The only packets arriving on WAN are from outside the network.

If you make a rule on WAN to allow port 443 then the Internet can try to log in to pfSense.

Example: a packet from a device on LAN enters the LAN interface, is allowed or not, and then sent to its next destination...for example DNS listening on the LAN IP, or forwarded on to the configured gateway to get to the Internet, another VLAN, whatever. For that specific packet, rules on any other interface are completely irrelevant.

Floating rules are more complicated so I suggest avoiding those if at all possible, especially at this stage.

katakuri

Thanks for the clarification, that helps a lot. What we are discussing here specifically applies to the inbound rules, correct? I was just reading here that I need a rule to prevent internal traffic from leaking out of the WAN which sounds like rules can be set up on both sides of the route:

https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html

So I could for example define an inbound rule on my VLAN interface allowing ICMP to anywhere but then define an outbound rule on my WAN port to block ICMP? Would that allow my VLAN to ping all internal networks but not allow pinging to the internet? It would probably be better to use the destination attribute of the ICMP rule but I am just trying to clarify what exactly happens.

SteveITS

@katakuri Are you looking at floating rules? Let's just avoid those. The processing order is different, it defaults to last match wins, and other pitfalls.

So I could for example define an inbound rule on my VLAN interface allowing ICMP to anywhere but then define an outbound rule on my WAN port to block ICMP?

The WAN interface firewall rules has no inbound or outbound choice, rules apply on inbound packets only. If you want to allow your VLAN to ping internal and not the Internet then you'd use something like:

on VLAN interface:
allow ICMP to (alias_containing_all_internal_networks)
reject ICMP to any

You could make the first rule into one rule for each subnet or interface if you wanted, and not use an alias. For example pfSense has a "LAN subnets" choice in the dropdown for each interface on pfSense.

katakuri

I am a bit confused about how VLANs interact with the assigned physical interface. If I have 2 VLANs assigned to port 3 (igc1 on my 4200), I have separate firewall rules for the VLANs and Port 3. Inbound traffic for those VLANs must come through port 3, so port 3 rules can override at the boundaries? Is that correct? Here is an illustration:

Port 3:
VLAN 31
VLAN 32

Port 4:
VLAN 41

VLAN 31 traffic arriving on port 4 is dropped because VLAN 31 is not assigned to port 4.
VLAN 31 traffic arrives on port 3. Port 3 firewall rules pass it, then process VLAN 31 rules? Or does it go straight to VLAN 31 rules? If a VLAN31 client on port 3 sends an ICMP packet to VLAN 41, do the rules process like this:

Port 3 inbound rules
VL:AN 31 inbound rules
Traffic heads out of Port 4 with VLAN 41 tagging.

katakuri

@SteveITS said in Firewall Rules Order:

The WAN interface firewall rules has no inbound or outbound choice, rules apply on inbound packets only. If you want to allow your VLAN to ping internal and not the Internet then you'd use something like:

Every time I think I got this I don't. All inbound on WAN is from the internet, right, because that is what it is plugged into? Is the block rule for RFC 1918 only needed in case your WAN is an RFC 1918 network?

katakuri

@SteveITS said in Firewall Rules Order:

Are you looking at floating rules? Let's just avoid those.

Yeah - I saw the direction on the Floating rules and assumed that it was like that for all rule types.

SteveITS

@katakuri said in Firewall Rules Order:

VLAN 31 traffic arriving on port 4 is dropped because VLAN 31 is not assigned to port 4.

Yes but it should never arrive there unless something (switch?) is misconfigured.

Or does it go straight to VLAN 31 rules?

Only the VLAN rules since they are separate interfaces in pfSense.

If a VLAN31 client on port 3 sends an ICMP packet to VLAN 41, do the rules process like this:

Port 3 inbound rules
VL:AN 31 inbound rules
Traffic heads out of Port 4 with VLAN 41 tagging.

Correct.

All inbound on WAN is from the internet, right, because that is what it is plugged into? Is the block rule for RFC 1918 only needed in case your WAN is an RFC 1918 network?

Correct.

katakuri

Many thanks for your patience - I am sure I am not saying everything correctly but I am trying to understand how to set up my network correctly. This started because I created a loop in my network and when I looked more into it I realized I didn't really know how to set it up correctly which is why I am trying to understand now rather than just apply recipes I find on the internet, which is how I made the mess in the first place. :(

tinfoilmatt

@katakuri Consider that each interface has two 'sides'—'in' and 'out' (more technically 'ingress' and 'egress' respectively)—with ruleset processing occuring 'in between' both directions.

So on a basic firewall with only a WAN and LAN interface, you technically have four directions to consider:

1.) WAN ingress (traffic originating from Internet or traffic originating from LAN interface)

WAN ruleset processing

2.) WAN egress (traffic destined for Internet or traffic destined for LAN interface)

3.) LAN ingress (traffic originating from local clients or traffic originating from WAN interface)

LAN ruleset processing

4.) LAN egress (traffic destined for local clients or traffic destined for WAN interface)

This is a little hard to conceptualize because traffic can ingress or egress to/from either direction. In other words, traffic can ingress-from and egress-to the internet from the WAN interface—or ingress-from and egress-'back'-to the LAN interface. Conversely, traffic can ingress-from and egress-to the local network from the LAN interface—or ingress-from and egress-'up'-to the WAN interface.

Not responding to anything in particular. Only hoping this might conceptually help.

katakuri

@tinfoilmatt said in Firewall Rules Order:

1.) WAN ingress (traffic originating from Internet or traffic originating from LAN interface)

Is that why for instance Floating rules can process inbound and outbound, but the other rules can only process inbound? A LAN rule can pass a packet that ends up going out of the WAN interface and the WAN rules are not triggered. But a floating rule could veto an outbound packet on the WAN interface that was passed from a LAN rule?

Bob.Dig

@katakuri said in Firewall Rules Order:

But a floating rule could veto an outbound packet on the WAN interface that was passed from a LAN rule?

Yes. But, as a beginner, you should not consider any floating rules anyways. Even if you are not a beginner, you would not use them unless you absolutely have to. 99.9% off all rules have the direction "in" and therefor can be created anywhere else.

katakuri

Good to know. I only had them defined because I found a reference to them on a 'helpful' forum when I first set them up. I have rewritten all of my rules now but there are still two rules that I believe are anti-lockout rules. Not sure where they came from. They look like this:

<rule>
  <type>pass</type>
  <ipprotocol>inet</ipprotocol>
  <direction>any</direction>
  <quick>yes</quick>
  <floating>yes</floating>
  <interface>any</interface>
  <statetype><![CDATA[keep state]]></statetype>
  <protocol>tcp</protocol>
  <source><address>PFManagmentAccess</address></source>
  <destination><network>(self)</network><port>FirewallPorts</port></destination>
  <descr><![CDATA[FirewallAccess]]></descr>
</rule>
<rule>
  <type>block</type>
  <ipprotocol>inet</ipprotocol>
  <direction>any</direction>
  <floating>yes</floating>
  <interface>any</interface>
  <statetype><![CDATA[keep state]]></statetype>
  <protocol>tcp</protocol>
  <source><address>PFManagmentAccess</address><not></not></source>
  <destination><network>(self)</network><port>FirewallPorts</port></destination>
</rule>

PFManagmentAccess is defined as my internal network and FirewallPorts is defined as 443, 22. No idea where those rules came from.

SteveITS

@katakuri FWIW the only interface/rules tab with anything on it by default is LAN. The anti-lockout rule there looks like:

There's a checkbox on System>Advanced>Admin Access to remove that.
(there are also two default rules there to allow IPv4 and v6 to any)