Advanced

Firewall → Advanced is an escape hatch for PF configuration that does not fit a Traffic Rule or NAT Rule. Each editor accepts raw PF text and inserts it at a fixed point in the generated /etc/pf.conf.

Use the managed rule pages whenever they can express the policy. Advanced content is global, is not represented as a Sylve rule object, and can change how every managed rule behaves.

Caution

These sections are not a second place to recreate ordinary Traffic Rules or NAT Rules. A quick rule, a broad pass, or a global PF option here can override the policy assembled by Sylve. Test one change at a time with Preview before saving.

How the page works

The Editable Sections list on the left selects an insertion point. Generated pf.conf renders the current draft without saving it and validates the complete candidate with pfctl -nf. On Disk shows the configuration currently written by Sylve, not the unsaved draft.

The examples below are saved on the demo host and shown through the generated configuration. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are documentation-only address ranges. Replace bridge0, addresses, and labels with values for the host you administer.

Advanced rules refer to FreeBSD interface names, not Sylve switch labels. The demo’s Manual Switch is named WAN, but it attaches to the existing host bridge bridge0, so the raw PF examples correctly use bridge0.

Saving trims each section, validates the rendered configuration first, then applies it when the firewall service is enabled. If the apply step fails, Sylve restores the previous Advanced settings and reapplies the earlier configuration. PF syntax validation is valuable, but it cannot tell whether a broad rule is the policy you intended.

Placement matters

Sylve renders the main configuration in this order:

Pre Rules
Sylve object tables
Pre NAT Declarations
Sylve nat / rdr / binat anchor declarations
Post NAT Declarations
Sylve NAT rule anchor
Pre Traffic Anchor
Sylve Traffic Rule anchor
Post Traffic Anchor
Post Rules

The names describe the insertion point, not a separate firewall engine. PF still processes translation before filtering.

Section	Use it for	Example
Pre Rules	Global set options, normalization, and independent table definitions that must appear before managed content.	set block-policy drop set skip on lo0
Pre NAT Declarations	Translation rules or exclusions that must be declared before Sylve’s translation anchors.	no nat on lo0 from any to any
Post NAT Declarations	A narrow match rule that should sit after translation declarations but before the managed NAT anchor and filter section.	match in on bridge0 inet proto tcp from any to 192.168.12.60 port 443 tag CADDY_HTTPS
Pre Traffic Anchor	A global filter exception that must be considered before managed Traffic Rules.	block in quick on bridge0 inet from 198.51.100.0/24 to any label "drop-test-net"
Post Traffic Anchor	A filter adjustment that should run after managed Traffic Rules.	match out on bridge0 inet from 192.168.12.0/24 to any set prio 2
Post Rules	A final, deliberately ordered fallback or exception after all managed content.	block in quick on bridge0 inet from 203.0.113.0/24 to any label "late-test-net"

Translation-adjacent sections

Pre NAT Declarations is before the three nat-anchor, rdr-anchor, and binat-anchor declarations. Use it for a translation rule or exclusion that has to be available ahead of those anchors. The example keeps loopback traffic out of NAT, which is normally a harmless exception when loopback is already skipped.

Post NAT Declarations comes after those declarations and before Sylve enters the filtering section. The example is a match rule that tags inbound HTTPS traffic headed for Caddy’s translated address. match adds a property without itself choosing pass or block, making it a better fit than a second broad access rule when all that is needed is a tag or other PF modifier. This is a tagging-only example: nothing else in this guide matches tagged CADDY_HTTPS. In a real policy, add a later rule that consumes the tag if it should affect routing, shaping, logging, or access control.

Do not assume an Advanced DNAT example replaces the NAT Rules page. Use the managed page for normal service publishing so Sylve can validate the target, display counters, and keep the rule tied to its configuration.

Before and after Traffic Rules

The two traffic-anchor sections bracket anchor "sylve/traffic-rules", which loads the Traffic Rules created in the UI.

• Pre Traffic Anchor is for a rule that must be considered first. The shown block in quick is intentionally narrow and uses a documentation range. With quick, later Traffic Rules cannot reverse the decision for matching packets.
• Post Traffic Anchor is for a rule that should see packets only after managed Traffic Rules have been evaluated. The example uses match out to set priority for LAN egress traffic without adding another pass decision.
• Post Rules is the final insertion point. Its example shows a last, narrow block. It is not a substitute for a baseline firewall policy and should never be a careless block all on a remotely administered host.

Preview the assembled configuration

Open Generated pf.conf after editing to see the candidate in its real position. The preview includes the managed object tables, NAT rules, and Traffic Rules, then runs PF syntax validation against the combined configuration. Use this view to verify ordering and confirm that a custom rule uses the interface, address family, address, and port you intended.

Object Tables shows the tables rendered from objects used by enabled managed firewall rules. It is a diagnostic view. The generated table identifiers include internal object IDs and can change with configuration, so do not treat them as a stable interface for hand-written Advanced rules.

A safe working sequence

1. Start with the smallest possible PF rule and use a specific interface, family, address, and port.
2. Put it in the latest section that satisfies the ordering requirement, then reason about PF evaluation. A quick rule preempts later matches; without quick, a later matching filter rule can become the decision that applies.
3. Open Generated pf.conf and check the surrounding lines, not only the custom snippet.
4. Save only after the Preview validates. Reopen On Disk to confirm the applied configuration.

If a policy can be represented by a Traffic Rule, NAT Rule, object, or route, prefer that managed feature. Advanced Firewall is for the remaining cases where direct PF control is genuinely necessary.