A VPN user needs one printer, not the whole LAN

The rule looks right and the printer still refuses. Or the printer works and the same user can also reach the file server, which is worse. Both outcomes usually come from the same place: the narrow rule was added to a rule set that already granted something broader. Reading the effective order explains the result before any new rule is written.

The symptom: the narrow rule changed nothing

A dedicated VPN pool, one printer address and a pass rule on TCP 631 is a reasonable design. When it produces no change at all, the first suspicion should be that the traffic never reached that rule. A rule only decides for traffic that arrives at its position in the evaluation order. The fields are easy to check and rarely the reason it fails.

The opposite symptom is easier to miss. The print job succeeds, and so does a connection to a file share the same user was never meant to reach. That means something earlier already permitted the LAN.

Both symptoms point at ordering rather than at the fields in the new rule. One of them is a rule that never matched, and the other is a rule that matched too early.

Which rule set the traffic actually hits

pfSense evaluates rules per interface, and OpenVPN has its own tab whose rules apply to every server and client instance. Those rules are processed before the rules assigned to a specific OpenVPN interface. A broad pass left on the OpenVPN tab therefore applies to this user as well, whatever the interface tab says. Copy that ordering into the change record so the review can check it without opening the GUI.

That is why a new narrow pass cannot subtract access. Firewall rules add permission, and they do not take it away from an earlier match.

Read the effective list from the top and stop at the first rule that matches the traffic. That first match is the decision, and everything below it is unreachable for that flow.

Write the pass rule from the print job

Start from the job rather than from the printer. The user needs the print service on the printer address, so the rule names that address, that protocol and that port. An alias for the VPN pool and an alias for the printer keep the rule readable.

Resist adding discovery or administration ports to make a wizard happier. A rule that admits the whole printer is a different policy from one that admits a print queue.

Keep the printer's own authentication in place. A network permit is not a substitute for it. A queue-level account is the right control for who may print what.

Six values carry the whole intent: pass as the action, IPv4 as the family, TCP as the protocol, the pool alias as the source, the printer alias as the destination, and 631 as the port. Anything beyond those six is a different policy than the one being requested.

Give the client a path without a LAN permit

The client needs a route to the printer address, and the office side needs a reply path to the VPN pool. Pushing a single /32 keeps the client configuration narrow, which helps troubleshooting. It is not the authorization boundary, because a client can add routes itself.

If the queue is addressed by name, define the resolver dependency separately. Allowing the whole LAN so that one name resolves is a much larger change than the job requires.

Choose deliberately between routing back to the pool and translating the source. Either works, and each hides something different from the logs.

Test the denial as well as the job

Submit one small, non-sensitive job from the VPN user, then try a LAN resource that should be denied and the firewall's own administration page. All three tests belong in the same session, because that is the only way to see the policy as a whole. A successful print job alone proves almost nothing about the boundary.

Review IPv6 and any other active VPN path before calling the deployment printer-only. A rule set that is narrow in one address family can be wide open in the other.