Port Forward vs VPN Access: Where the Packet Actually Goes

Two designs, one HTTPS application, and the packet takes a different route in each. A port forward changes where the packet is delivered and leaves the rest of it alone. A VPN carries that packet inside another packet first, so the application's listener sees a different source and a smaller maximum payload. The encryption people argue about is present in both cases, because the application is still HTTPS; what differs is who can open a connection and what the network in between can observe. That distinction settles most of the practical questions.

The DNAT rule rewrites the destination and stops there

On a Linux gateway, publishing a service means a rule in the nat table's PREROUTING chain, or the equivalent in nftables. The rule matches the public address and port, then rewrites the destination to the application's private address. Source address, source port and payload are untouched, and conntrack records the mapping so replies get rewritten back on the way out. The behaviour is the traditional address-translation model described in RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

The application's listener never learns that the connection arrived through a translation. It sees the client's real source address, which is useful for access logs and rate limits, and it answers to the private address because conntrack reverses the mapping. Nothing along that path decrypts or re-encrypts anything: TLS still runs between the client and the application's own certificate.

The rule also fixes the failure modes you will meet later. If the gateway forwards but the application's host has no route back to the client, replies leave with the wrong source and the handshake stalls. If a second rule matches first, order decides the outcome, and iptables -t nat -L -n -v shows the counters that prove which rule took the packet.

The tunnel wraps the packet before the listener sees it

A VPN does not publish the application at all. The client builds an outer packet addressed to the gateway's public address, encrypts the inner packet inside it, and the gateway decrypts and routes the inner packet to the private destination. With WireGuard the outer transport is UDP, usually on a high port; with OpenVPN over TCP 443 the outer packet looks like TLS to anything watching the path.

Inside the tunnel the inner packet keeps private addresses: the client's tunnel address, say 10.8.0.6, and the application at 10.20.30.40. The listener therefore sees a source from the tunnel pool, and every client shares that gateway as its next hop. Access logs behind a VPN often show the gateway rather than the user for exactly this reason, unless the gateway preserves the original source.

The wrap costs header space, and that is the one mechanism-level difference with a consequence you can measure. An outer IP header plus UDP plus WireGuard's own header eats into the path MTU, so large packets must be fragmented or the inner TCP stack must clamp its MSS. A transfer that works over the forwarded path can stall over the tunnel when a middlebox drops the ICMP that would have signalled the smaller MTU.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Exposure is decided at the entry, not by the cipher

Both designs end at the same TLS listener, so both inherit the same certificate, the same protocol versions and the same application login. What changes is who is allowed to start a handshake. With a public forward, any host that can reach 203.0.113.10:443 gets a TCP handshake and a TLS ClientHello before your application authorization is consulted at all. With tunnel-only access, the listener is reachable only from addresses the gateway routes into the tunnel, and a stranger's SYN dies at the gateway policy.

That difference is about reachability, not about confidentiality. A forwarded HTTPS service is not plaintext, and a VPN does not remove the need for application authentication: tunnel admission answers whether a device may send packets into this network, while the file application answers whether a user may read a document. Conflating the two is how teams end up with a VPN that grants the whole LAN and an application with one shared password.

Inspect the listener and the policy separately, because either one can be wider than you assume:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

If ss shows the listener bound to 0.0.0.0, the application is reachable from wherever routing and firewall policy allow, and the forward is only one of the ways in. Binding to the private address, or restricting the source range in the firewall, is a separate decision from choosing a VPN, and it is the decision that actually narrows exposure.

Measure the path, not the label

When someone claims the forward is faster, the honest comparison holds everything else constant: same client, same access network, same file, same TLS configuration, same application host. Run the transfer twice per path and record total time, failure count and responsiveness, not the output of an unrelated speed test.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Those numbers separate connection setup from transfer time, which matters because the two paths usually differ in round-trip latency and MTU rather than in cipher cost. TLS work happens at the endpoints in both designs, and a tunnel adds encapsulation, a different route and possibly a busier gateway. If the tunnel path is longer or its gateway is loaded, the difference belongs to the path and not to the word encryption.

Pick the entry policy the service actually needs, then decide whether a measured difference justifies changing it. A public forward suits a service meant for the open internet, with source restrictions, patched TLS and monitoring in front of it. Tunnel-only access suits an internal tool whose users are already enrolled, provided the gateway routing and the application permissions are both narrower than the whole LAN.

Before you call the design finished, confirm four things: which address the listener is bound to, which rule or route admits the packet, whether the return path works from the client's real address, and whether large payloads survive the MTU. Each of those has a command above, and none of them is answered by the word secure or by a bandwidth chart.