Static Tunnel Addresses in pfSense: Preference or Reservation?

Two designs look similar on paper and behave very differently when a rule depends on them. One types an address into a client override and trusts the address as an identity. The other closes dynamic admission entirely, so an endpoint either has a unique assignment or does not connect. Only the second turns an address into a policy input you can defend, and the difference is worth understanding before you write a single firewall rule.

What an override address actually promises

A Client Specific Override carries per-client options, including a preferred tunnel address. Netgate describes that address as a preference rather than a reservation, which means the dynamic pool does not give up the address for anyone else.

That is usually fine. A collision is rare, and the client normally receives what it asked for, which is enough for convenience and not enough for authorization. Convenience and authorization are different requirements, and only one of them survives a collision.

With subnet topology, the field takes the client address together with the server network's mask, so an address inside a 10.90.0.0/24 tunnel is written as 10.90.0.10/24.

None of that reserves the number. A client whose override fails to match, or a duplicate session, can end up elsewhere in the pool, and a rule keyed on the address then describes somebody who is not there.

Close the dynamic path with a scoped default

The alternative is a static-only server: every admitted endpoint has its own identity and its own unique address, and nothing else gets in.

Implementing it means a DEFAULT override scoped to that one server with connection blocking enabled. A client without a matching override then cannot fall back to ordinary dynamic admission. That single line is what converts a preference into a closed set.

Scope matters. A default override applied to every VPN instance on the box will lock out unrelated tunnels, and that failure looks like a broken service rather than a policy decision. Bind it to the one server whose admission model you are changing. Then note the scope in the change record, because the next person will not remember which tunnel it belongs to.

Audit the whole allowed set afterwards. The default block does not fix a named override that was left without an address, and that endpoint will simply fail to connect with no obvious hint about why.

Match on the identity the server really uses

An override matches something. On a server that matches certificate common names, the override name must be that common name, not the display name of the person. Copy it from the certificate rather than from the account list.

A server configured to use the username as the common name matches on a different key entirely, and an override named for the certificate will never fire. Read the setting rather than inferring it from what the account list shows.

Keep the additional authentication factors the deployment requires. A closed address model changes who may connect and which address they receive; it does not replace the certificate check or the second factor.

Write the access rules after the map is sound

Once the identity-to-address map is closed, rules can reference addresses without pretending they are people. An alias grouping one person's endpoints can reach a specific service while another alias reaches something else. The alias becomes the reviewable object, and the address becomes an implementation detail inside it.

Keep destinations and ports explicit. Allowing the whole local network from the entire tunnel pool is the design this exercise was meant to replace.

Read floating, group and interface rules in their real evaluation order, because an earlier broad pass defeats a later narrow one. Turning off internal client-to-client forwarding keeps peer traffic at the boundary where those rules are reviewed. A rule that only exists on paper is not enforcement.

Test the negative cases

Exercise four fresh connections: a named endpoint, one with no override at all, a service that should be reachable and one that should not. The unlisted endpoint is the important case, because it is the one the design exists to stop. If it connects, the default block is not doing its job.

Check IPv6 separately, since an IPv4 address policy says nothing about a second stack. Then confirm the application still authorizes the user, because a tunnel address is a network fact rather than proof of who is at the keyboard. Both checks belong in the acceptance note.

Finally, plan the migration. New overrides and narrow rules do not retroactively change sessions that are already established, so existing states have to expire or be cleared deliberately.