Invert Match vs Implicit Deny

Hello, I’ve seen some youtube videos on setting up VLAN rules to segregate traffic between vlans. Is there any difference or recommended approach when it comes to an invert match and an implicit deny? What are the implications of each?

This

VS.

The difference is what implicit effects you will get and may not have explicitly considered.

E.g. if you have an allow from all to all rule at the end you may need to explcitly block access to the pfsense UI and SSH ports in some of your networks. (see the following thread: Pfsense login accessed from public IP internally)

I would encourage you to never do that and to explicitly allow things you are OK with to happen. That is a more failsafe approach.

also instead of “! private” you can have more aliases where you have one for each network enumerating which other internal networks it may access, and then allow “iot-destinations” that at the end of the rule list.

The beauty of this is that you will see all traffic blocked by the default deny rule in the logs. This allows you to identify unwanted traffic, or to see which additional rules you would need to add to allow wanted traffic that is blocked by accident.

the end of a filter list would be something like

allow IPv4 * * iot-destinations * * (change alias content accordingly, if no other networks accessible, it should be empty, do not include the own network address)
allow IPv4 * * !ALL_RFC1918 * * (only if this VLAN has Internet access)

1 Like

I originally started out with a block all and was trying to open ports per service but this network has a lot of devices and it was a pain getting everything open correctly. I want to get everything setup so I can log and then will start tightening things.

So, the end of the filtering list would have allow all internal VLAN routing above these two rules you mentioned? I’ve been doing that specific from IP vlan1 to IP vlan2 in the other VLAN.

So, we create an IOT_DESTINATIONS alias which will allow us to add IPs for inte rvlan routing as needed? I guess if i wanted to only specify specific source address i could add IOT_SOURCE and IOT_DESTINATIONS alias.

Protocol Source Port Destination Port Gateway
ALLOW INTERNAL ACCESS ABOVE
allow IPv4 * * * IOT_DESTINATIONS * *
allow IPv4 * * * !RFC_1918_local * *

This rule architecture prevents the need for explicitly blocking UI and SSH?

The beauty of this is that you will see all traffic blocked by the default deny rule in the logs. This allows you to identify unwanted traffic, or to see which additional rules you would need to add to allow wanted traffic that is blocked by accident.

These above rules in the table will allow this? Is this how you do your network?

You can do how you see fit. I personally put the IP network addresses in this alias for all the VLANs that should be reachable from the IOT VLAN without any further restrictions.

The larger overall generic structure of the rulesets for each VLAN could done like this: you can have several sections and you can put a commentary separator on top of each section, and then put the individual rules you see fit into those sections accordingly:

  • Anti Lockout rule
    (exists only on LAN interface)

  • top section: rules added by pfBlocker-NG (no section heading possible here)
    … these rules are generated by pfBlocker-NG, only if you use this package

  • section: rules to allow traffic to this pfsense device
    … manual rules, e.g. access to UI and SSH

  • section: rules for internal traffic
    … manual rules for East-West traffic, here you work with Aliases for the selected local clients in this VLAN, and aliases for the local server destinations in other VLANs, and aliases for the destination ports

  • section: default rules
    optional rule: reject IPv4 TCP/UDP * * ! ALL_RFC1918 Blocked_Ext * (The Blocked_Ext is a port alias that you can use to prevent machines to use e.g. DNS and NTP on the Internet)
    allow IPv4 * * VLAN-destinations * * (change alias content accordingly, if no other networks accessible, it should be empty, do not include the own network address)
    allow IPv4 * * !ALL_RFC1918 * * (only if this VLAN has Internet access)

if you omit the !ALL_RFC1918 rule to only allow specific external destinations you add the following 2 sections:

  • section: rules to avoid filter log entries
    … manual rules for unwanted traffic blocked by the default deny rule, but should not appear in log files

  • section: rules for selective Internet access:
    … manual rules for North-South traffic to allow dedicated Internet destinations to selected local servers, here you work with Aliases for the selected local servers, and aliases for the Internet Destinations, and aliases for the destination ports

  • bottom section: rules automatically generated to allow NAT port forwardings
    … these rules are generated by NAT port forwarding rules

As you can see every VLAN will use the same structure while individual sections may be omitted, depending on the needs for that VLAN. The only section you would have in 99% of the cases is the “default rules” section.
This may seem overcomplicated and overwhelming. In fact thought it does help you to have the same rationale everywhere and will after 1 day let you understand you rulesets a lot easier because everything adheres to the same structure.

Note that you can factor out rules that are the same for all networks into floating roules. I decided not to do that because it makes the understanding of the control flow harder to understand and you want to keep it as easy to understand as possible.

The optional rule to block Internet DNS and NTP would be used if you want machines to use your local DNS and NTP servers. You can use different ways to direct the machines to you local services (DHCP, NAT, DNS RPZ overriding of external domains).

Thank you. I appreciate your thorough response. I’m going to read through this and I’ll update the post with my interpretation! :slightly_smiling_face:

With pfBlocker-NG do you not use the floating rules? You have pfblocker add rules per interface? I just noticed you mentioned that in your response.

Correct, exactly this, no floating rules.

I just want to make sure my understanding is correct. I was under the impression that “floating rules” with inbound/outbound filtering provided additional features (beyond matching and traffic shaping) that interface rules alone do not.

Here is my understanding:

  • pfSense applies rules on a per-interface basis, and these rules only filter traffic as it enters (inbound) the firewall on that interface.

    • Traffic originating from LAN devices (LAN-to-Internet) is filtered by LAN rules as it enters the LAN interface. LAN DEVICE → LAN INTERFACE

    • Traffic originating from the Internet (WAN-to-LAN) is filtered by WAN rules as it enters the WAN interface. WAN ← INTERNET DEVICE

I think the key is that “inbound” refers to traffic entering a specific interface, not necessarily entering or leaving your network.

After a rule allows inbound traffic on an interface, a state is created and subsequent traffic in either direction is no longer evaluated by rules until a new state is needed.

Floating rules mainly add flexibility and advanced features (e.g., traffic shaping, matching on multiple interfaces at once, etc.). Also order processing with special consideration for quick.

Floating rules:

  • A pass or block inbound floating rule on an interface is equal to a pass or block interface rule.

  • A floating rule set to “block outbound” on LAN interfaces is the same as creating a block rule on the WAN interface.

  • A floating rule set to “pass outbound” on LAN interfaces is the same as creating a pass rule on that interface. If this is not set to quick a block rule on the interface could still interfere with the traffic.

nope,
a floating block outbound should be the same as a block rule on several LAN interfaces