Feature Request: Support fib daddr type / fib saddr type matching in firewall rules (especially prerouting raw)
Summary
Expose nftables' fib daddr type (and ideally fib saddr type) expression as a match condition in VyOS firewall rules, particularly under `firewall <ipv4|ipv6> prerouting
raw`. This would let a rule match "destination is one of this router's own local addresses" (fib daddr type local) without requiring the operator to manually enumerate eve
ry locally-configured address in a network-group/ipv6-network-group.
Motivation / real-world use case
We run a DFZ edge router (VyOS 1.5.1, FRR 10.5.2) carrying full BGP tables (~1M IPv4 / ~250k IPv6 prefixes) from multiple transit/peering sessions, with no NAT and no statef
ul forward policy on these interfaces. We wanted to stop connection-tracking pure forwarded/transit traffic on these interfaces (via action notrack in `firewall <family> p
rerouting raw`) to keep the conntrack table small and avoid tuning system conntrack table-size upward just to accommodate transient full-table transit flows that carry no
functional benefit from being tracked.
The problem: notrack decisions are evaluated in the raw table at PREROUTING, before the kernel's routing/FIB lookup determines whether a packet will be locally delivered (
INPUT) or forwarded (FORWARD). A blanket notrack scoped only by inbound-interface therefore also untracks traffic destined *to the router itself* on that interface — BGP
, BFD, NTP, DNS client queries, RPKI cache sessions, etc. Several of these relied entirely on the ct state established/related shortcut in our *_LOCAL input-filter rul
esets to admit return traffic (no dedicated stateless allow rule existed for some of them). Once notrack was applied, that shortcut stopped firing (an untracked packet's `ct
state` is untracked, never established), and — combined with a firewall rule that only matched one direction of a bidirectional TCP service (BGP: destination port 179
only, no source port 179 counterpart for sessions where our router was the connecting/client side) — this caused a real, multi-minute production BGP outage when first att
empted, before being identified and rolled back.
What we actually want
Distinguish, at the raw/PREROUTING stage, between:
- traffic destined to the router itself (keep tracking — control plane, small volume, benefits from the established/related shortcut), and
- traffic being forwarded through the router (safe to notrack — pure transit, no NAT, no stateful policy).
Current workaround (and why it's not ideal)
We had to manually build a network-group/ipv6-network-group containing every address configured on the router (loopback + every interface address, including addresses th
at are duplicated across multiple "unnumbered" point-to-point links), then add two rules per notracked interface:
set firewall ipv4 prerouting raw rule 1 inbound-interface name 'eth0' set firewall ipv4 prerouting raw rule 1 destination group network-group 'R1-OWN-ADDRESSES-V4' set firewall ipv4 prerouting raw rule 1 action 'accept' set firewall ipv4 prerouting raw rule 2 inbound-interface name 'eth0' set firewall ipv4 prerouting raw rule 2 action 'notrack'
This works, but:
- It requires manual enumeration of every local address and ongoing maintenance whenever an address is added, removed, or an interface is renumbered.
- There is no commit-time check that the list is complete. A missed address silently falls through to the catch-all notrack rule — a newly added service/anycast address co
uld unexpectedly lose the established/related shortcut it might be relying on, with no warning.
- It has to be repeated per router and kept in sync across a fleet (we run four routers with this pattern).
We verified via live tab-completion on VyOS 1.5.1 that no such match currently exists:
vyos@r2# set firewall ipv4 prerouting raw rule 1 destination ? Possible completions: address IP address, subnet, or range address-mask IP mask fqdn Fully qualified domain name > geoip GeoIP options - Data provided by DB-IP.com > group Group mac-address MAC address port Port
No fib/local-address-type option is exposed anywhere in this rule's match tree.
Requested syntax (example)
set firewall ipv4 prerouting raw rule 1 destination fib-type 'local' set firewall ipv4 prerouting raw rule 1 action 'accept' set firewall ipv4 prerouting raw rule 2 action 'notrack'
fib-type values would map directly to the nftables fib expression's type values (local, unicast, broadcast, anycast, etc. — local is the one relevant to this use case). This is not a request for new kernel/nftables functionality — fib daddr type local is a standard, already-supported nftables expression. The ask is purely to expose it through VyOS's declarative config schema (interface-definitions XML) so it can be used from the CLI/config like any other match.
Why this matters beyond our specific case
This is the general pattern for any router that wants to distinguish "traffic destined to me" from "traffic passing through me" at the raw/PREROUTING stage — relevant wherever notrack-based conntrack optimization is desirable on a box that forwards a large number of flows (DFZ/transit routers) but also runs a small number of local control-plane/management services. It is the same semantic goal that other platforms solve architecturally (e.g. Junos: a firewall filter applied to lo0.0 catches all locally-destined traffic regardless of the physical ingress interface, without needing to enumerate addresses) — VyOS/Linux has the underlying primitive (fib daddr type) but doesn't currently surface it.
Related, lower-priority idea
A more general "dynamically-derived group" mechanism — analogous to Junos's policy-options prefix-list <name> apply-path "<config path>", which populates a prefix-list directly from another part of the configuration (e.g. every configured BGP neighbor address) instead of requiring duplicate manual entry — would solve a related but distinct drift problem: keeping firewall groups like IPv4_EBGP_HOSTS in sync with the actual configured BGP peers. We're not aware of any VyOS equivalent to apply-path; firewall groups are currently static and must be maintained by hand in parallel with the routing config they're meant to reflect. This is a bigger ask (effectively a new declarative subsystem) and is mentioned here for context/completeness rather than as the primary request.
Environment
- VyOS 1.5.1 (circinus), official generic ISO, FRR 10.5.2
- Verified via live CLI tab-completion on production hardware (HP ProLiant DL360p Gen8)