OPNsense VLAN Interfaces and Firewall Rule Processing

OPNsense runs the same stateful packet filter as pfSense under a different management
layer, and the part that trips people up is not writing rules — it is rule processing
order. OPNsense has three rule categories (floating, group, interface) and a sort order
that decides which wins, so a rule can look correct, be enabled, and still never evaluate.
This article covers creating VLAN interfaces from scratch and then the ordering model that
explains why your rules behave the way they do.

Interfaces and VLANs: The Model

Everything in OPNsense travels via an interface, and interfaces are assigned to physical or
logical devices. WAN and LAN are assigned by default; anything else you create — guest
network, VXLAN bridge, PFSYNC for HA — is an additional assignment. A VLAN is created on a
parent interface first, then assigned to a new interface, then configured with an IPv4
or IPv6 address. Skip the assignment step and the VLAN exists but nothing filters it.

Step 1: Create the VLAN

Interfaces > Devices > VLAN
   Parent interface:  igb1
   VLAN tag:          100
   VLAN priority:     0
   Description:       VLAN100-TRUST
   Save

Interfaces > Assignments
   New interface:     VLAN100 on igb1 (VLAN tag 100)
   Description:       TRUST
   Add

Interfaces > [TRUST]
   Enable interface:  yes
   IPv4 Configuration Type: Static IPv4
   IPv4 address:      10.10.100.1 / 24
   Block private networks:  (leave off on internal interfaces)
   Block bogon networks:    (leave off on internal interfaces)
   Save > Apply

The two Block options only belong on WAN. Enabling them on an internal interface is
a classic self-inflicted outage, because RFC1918 traffic is exactly what you expect there.

For a trunk to a switch:

Interfaces > Devices > VLAN > repeat for tags 200 (GUEST), 300 (IoT)
Interfaces > Assignments > assign each, name them, set addresses
# Ports on the connected switch must be tagged for all three VLANs.
# See the pfsense/switch interoperability notes for the switching side.

Step 2: The Firewall Rule Hierarchy

This is the part that decides whether your rules do anything:

1. System-defined rules at the beginning
2. Floating rules
3. Group rules
4. Interface rules (assigned to a single interface)
5. Legacy interface rules (the older Firewall > Rules page)
6. System-defined rules at the end

Within the modern rule pages there is an explicit sort order with two components:
a priority group, driven by the interface hierarchy, and a sequence number. Lower sequence
numbers in the same priority group win. In practice:

• Floating rules are evaluated before anything assigned to one interface. Use them for
  policy that must apply to many interfaces (a DNS block, an anti-lockout exception).
• Group rules sit in the middle and are the right home for "all guest interfaces share this
  policy".
• Interface rules are last and are the right home for interface-specific decisions.
• The first match wins. There is no "implicit continue".

Step 3: Writing Rules That Do What You Mean

Firewall > Rules > TRUST > Add
   Action:              Pass
   Interface:           TRUST
   TCP/IP Version:      IPv4
   Protocol:            TCP
   Source:              TRUST net
   Destination:         any
   Destination port range: 443, 80
   Log:                 yes        (while building the ruleset)
   Description:         allow TRUST to web
   Save > Apply changes

Firewall > Rules > GUEST > Add
   Action:              Pass
   Interface:           GUEST
   Protocol:            UDP
   Source:              GUEST net
   Destination:         10.10.100.1 (firewall)
   Destination port:    DNS (53)
   Description:         guest DNS to resolver only
   Save

# ... followed by an explicit block so the deny is visible in logs
Firewall > Rules > GUEST > Add
   Action:              Block
   Interface:           GUEST
   Source:              GUEST net
   Destination:         TRUST net
   Log:                 yes
   Description:         block guest to trust

Always add the explicit block. pf's default is deny, but an explicit logged block is the
difference between "it does not work" and "here is the rule that dropped it".

Step 4: A Floating Rule for Cross-Interface Policy

Firewall > Rules > Floating > Add
   Action:            Block
   Interface:         GUEST, IOT
   Direction:         in
   Protocol:          TCP/UDP
   Source:            any
   Destination:       10.10.100.0/24
   Description:       RFC1918 trust network protection
   Quick:             yes
   Save > Apply

Quick on a floating rule makes it terminal — evaluation stops when it matches. That
is usually what you want for a security block, and it is the setting people forget, which is why
their block rule appears not to work.

Verifying and Debugging

# Live packet filter state
Firewall > Diagnostics > States          # GUI
pfctl -ss | head                          # shell

# pf rules as the kernel sees them — the ground truth
pfctl -sr | head -60
pfctl -sn

# Live log (Firewall > Log Files > Live View in the GUI)
clog -f /var/log/filter.log

# Where did that packet go?
tcpdump -ni igb1.100 -c 50 host 10.10.100.50

pfctl -sr shows the compiled ruleset in evaluation order. When a rule is not
working, this is the fastest way to find out whether it exists, in what order, and on which
interface. GUI confusion dissolves immediately.

Operational Notes

• Rules are evaluated on the ingress interface. Traffic leaving the trust network does not
  get filtered by rules on the WAN tab.
• Stateful filtering means return traffic is handled automatically; do not add rules for
  replies.
• Keep the anti-lockout rule intact on the management interface, and always change firewall
  rules from a console or out-of-band session the first time.
• Back up /conf/config.xml before every rule set change. Restoring from the GUI
  is significantly easier than reconstructing a rulebase from memory.
• If you also run pfSense, the VLAN and trunk configuration is close enough to be worth
  reading in parallel: pfSense VLAN trunk and firewall rules configuration. Cross-vendor policy behaviour is compared in FortiGate policy mode vs profile mode.

原文链接：https://docs.opnsense.org/manual/firewall.html