Forward Everything to One Host, or Rewrite the Port Too?

Forwarding everything to your VPN server can describe two very different rules. One changes the destination address and keeps the incoming port; the other also rewrites the port onto a single listener. The exposure is not the same, and the decision depends on three conditions rather than on the label the router's interface uses.

Condition one: which fields does the rule change?

Destination address translation and destination port translation are separate operations. A rule can perform the first alone, or both together, and the difference decides which services on the target host are reachable. Most vendor interfaces hide that choice behind a single label. Reading the underlying rule is the only way to know which one you got.

Read the actual rule rather than the menu label. A screen that says DMZ or all ports describes an intention, not a packet path. The Netfilter NAT documentation separates the two translations, which is the right mental model even when the router in front of you is a consumer appliance.

Two fields, two different questions.

Condition two: what is listening on the preserved ports?

If the rule keeps the incoming port, every arriving port is delivered to the same number on the VPN host, subject to that host's input policy. That includes services you may have forgotten were listening. The rule did not create those services, and it is now the path to them.

If the rule rewrites the port, the opposite happens: many outside ports collapse onto one listener, and nothing else on the host is reachable through that rule. A fixed-port rewrite does not become access to every local service merely because a wide range of outside ports matched it. The two designs fail in different directions, and the failure mode is what you are choosing. Pick the one whose failure you can live with.

Inventory the listener before you choose.

Condition three: how wide is the outside entry?

Publishing one selected port is narrower than publishing a range, and both are narrower than accepting everything. The outside width and the inside translation are independent choices, and most confusion comes from changing one while describing the other.

For an ordinary VPN entry, publish the transport and the listener the design actually needs. Then review three more things: the router's effective mapping, the target host's own input rules, and whether an IPv6 listener publishes the same service. A rule that looks narrow on one address family can be wide on the other.

Write the translated endpoint in full: protocol, outside port, inside address, inside port.

What neither rule gives you

Neither design proves the service is free of vulnerabilities, and neither protects availability. Authentication, updates and recovery stay in scope regardless of how narrow the port mapping is. A narrow mapping reduces reachable surface; it does not make the listener safe.

A broad rule that already supports another legitimate service is a dependency, not just a mistake. Inventory it and replace it through its owner before removing it, or the change will look like an outage caused by a security fix. The same caution applies to a fixed-port rewrite that something else quietly relies on.

Exposure analysis is about what can reach what, not about the label on the screen.

Decide with the translated endpoint in hand

Write the rule's result as a sentence: public UDP port X reaches address Y port Z. Then ask which services at Y can answer on Z and who owns them.

nft list ruleset

If the answer is the one listener you intended, the rule is doing its job.

If the answer is several, you have chosen host-wide forwarding whether or not the interface called it that.