Build Clear pfSense Firewall Rules with Aliases and Logging

A short, named rule is easier to review than a long list of addresses. This guide permits one example flow: management host 10.10.10.25 to application host 10.20.20.10 on TCP 443. The rule belongs on the interface where the management host’s packets enter pfSense. Replace every address with an approved lab value and preserve a separate management path while changing rules.

Understand the evaluation order

pfSense evaluates floating rules, interface-group rules, and then rules on an individual interface. Within an interface tab, the first matching rule wins. Review existing group and floating rules before assuming a new interface rule is effective.

01

Record the Exact Flow and Current Rules

Scope

Identify the source host and ingress interface, destination host, protocol, port, and business owner. Save a configuration backup and note the current rule order. Confirm a direct path exists between the subnets and that the application really listens on TCP 443. Do not create a broad subnet-wide pass rule to solve a single-host requirement.

Source: 10.10.10.25 on MGMT interface
Destination: 10.20.20.10 on SERVERS network
Service: TCP 443
Expected: only the approved management host can reach this service

❯ What to Verify

The source, destination, protocol, port, owner, and ingress interface
are confirmed before editing the firewall.

02

Create Named Host and Port Aliases

Aliases

Open Firewall > Aliases. Add a Host alias MGMT_HOST for 10.10.10.25 and another Host alias APP_HOST for 10.20.20.10. Add a Port alias APP_HTTPS containing 443. Use descriptions that name the purpose and owner. Alias names use letters, numbers, and underscores; they cannot use spaces.

Firewall > Aliases > Add
Host: MGMT_HOST = 10.10.10.25
Host: APP_HOST = 10.20.20.10
Port: APP_HTTPS = 443
Save and Apply Changes

❯ What to Verify

The aliases appear with the intended type, address or port, and description.

03

Create the Narrow Pass Rule

Access Rule

On Firewall > Rules > MGMT, add a pass rule using IPv4 TCP. Set source to MGMT_HOST, destination to APP_HOST, and destination port to APP_HTTPS. Enable logging during the pilot, give the rule a descriptive name, and place it above any broader block that would match first. Do not put it on the SERVERS tab: the connection enters through MGMT.

Firewall > Rules > MGMT > Add
Action: Pass; Address Family: IPv4; Protocol: TCP
Source: MGMT_HOST
Destination: APP_HOST; Destination Port: APP_HTTPS
Log packets handled by this rule: enabled for pilot
Description: Allow approved management host to app HTTPS
Save > Apply Changes

❯ What to Verify

The new rule shows the intended aliases and position on the MGMT tab.

Illustration: The narrow MGMT rule uses the three aliases created in Step 2 and enables logging for the pilot.

A pass rule alone does not make the policy narrow

If a broader pass rule above or below already permits the same traffic, the negative test may still succeed. Review all matching floating, group, and interface rules. Change existing access only through the approved change process, especially anti-lockout and management rules.

04

Inspect the Loaded Alias and Rule Match

Inspection

Use Diagnostics > Tables to check the addresses loaded for a host or network alias, especially if the alias contains a hostname. Then check Status > System Logs > Firewall after a test connection. The log’s interface, source, destination, and rule information should match the approved flow. An empty log may mean the rule did not match, logging is disabled, or an established state handled the traffic.

Diagnostics > Tables > select MGMT_HOST or APP_HOST
Status > System Logs > Firewall > filter for source/destination

❯ What to Verify

Alias contents match the approved values and a new test connection
matches the intended pass rule.

05

Run Positive and Negative Tests

Validation

From 10.10.10.25, connect to the application on TCP 443 and verify the actual application response. Repeat from a second management host that is not in the alias. That host should fail unless another approved rule grants access. Test a different destination port to ensure the exception is not broader than intended. Existing firewall states can persist after a rule change; use a fresh connection and interpret old states separately.

# On an approved Windows test client; replace the lab host.
Test-NetConnection 10.20.20.10 -Port 443

❯ What to Verify

The approved host reaches TCP 443. The unapproved host and other port
remain blocked unless separately authorized.

06

Review Logs and Close the Change

Closeout

Keep logging if the flow needs an audit trail, or reduce verbose pass logging after the pilot if it creates excessive volume. Retain the rule description, owner, test evidence, and rollback instructions. Export an encrypted configuration backup. When troubleshooting later, distinguish a default-deny entry from a block by a specific rule and inspect the rule ID rather than guessing from the packet’s port alone.

Record: alias members | rule order | rule ID | positive/negative tests |
        log decision | application owner | backup location

❯ What to Verify

The approved exception is documented and repeatable, with no unintended
access shown by the negative tests.

Primary references

See Netgate’s alias configuration, firewall rule settings, rule methodology, and firewall log guide.