Does the Upstream Router Really Deliver Inbound VPN Ports?

Three conditions decide whether a port forward on the lab router publishes anything: what the upstream edge delivers, which policy it applies, and whether replies return by the same path. A public-looking address answers none of them. So does a /30 prefix or a working outbound connection. Sort those conditions before changing NAT, or the local rule will look broken when the block sits two hops away.

Three Answers Decide Who You Escalate To

The upstream owner can describe the hand-off in one of three ways. The destination is delivered directly to your interface, a separate prefix is routed to your next hop, or something in front translates the address before it reaches you. Each answer names a different device that must permit the inbound connection, and a different team to call when it does not.

Filtering is the fourth variable and it is independent of all three. A network can filter traffic that keeps its public address, and a translator is not automatically the policy boundary. Ask about permitted source addresses, transports and ports at the same time as delivery, because a forwarded port the edge drops never reaches your rule.

Read the Hand-Off as a Service Contract

Write down five values before touching the lab router: the assigned interface address, the prefix length, the next hop, the destination address external clients will use, and the exact protocol and port. The destination is the interesting one, because it may not be an address configured on your device at all. If the upstream expects clients to reach a translated address, local DNAT has to match that contract rather than the interface address you see.

The IETF firewall-behavior discussion is a useful reminder that filtering and translation are separate functions. It explains why a router can enforce inbound policy without hiding addresses, and why NAT somewhere upstream does not prove filtering happens there. Treat the hand-off as a service description with an owner and a change process.

Observe One Attempt at Both Boundaries

One narrow, approved attempt correlated at two points replaces a pile of guesses. Run a capture on the lab WAN interface for the exact tuple, and ask the upstream owner to observe the same tuple at the edge. Keep destination, protocol, port, source and timestamp identical between the two views.

tcpdump -ni wan0 'tcp port 1194 and host 203.0.113.10'

Read the pair of results as a decision. Seen at the edge and seen on the lab WAN means delivery and edge policy both pass, so continue with the listener or DNAT. Seen at the edge but not on the lab WAN points at delivery or an intermediate policy, and the upstream owner is the next call. Seen nowhere means the test tuple, the source or the path is wrong before any firewall question.

Absence of evidence in one capture is not proof of a firewall. It is a boundary result that tells you which device to inspect next.

Keep Local NAT From Hiding the Answer

Only after ingress is confirmed does the local rule become interesting. Confirm that the DNAT target is the VPN listener's actual address and port, that forwarding is enabled for the relevant family, and that the reply leaves through the interface the request arrived on. A rule that rewrites the destination but not the return path produces the same timeout as a dropped packet.

Retain port security and the production hand-off while you investigate. Replacing the router or spoofing its MAC address to bypass attachment controls trades a diagnostic for an outage. A mirror port or an approved capture gives the same visibility without disconnecting services that share the link.

End with the ownership map: destination, delivering device, filtering device, lab ingress and listener. That map makes the next port-forward review small, and it authenticates nothing about the VPN itself.