HTTP Proxy, SSH Tunnel or VPN: Pick the Right Layer

Ask three engineers how to reach an internal service and you will get three designs: a web proxy, an SSH tunnel, or a full VPN. All three can put a remote service within reach, and all three can make traffic appear to come from somewhere else. The differences surface later, when the protocol in use is not the one the chosen tool assumes. A design that passes a quick browser check routinely fails on the application that motivated the request.

Decide from two facts: which protocols must cross, and who can resolve the names involved. Everything else is preference.

A proxy moves only what it understands

A web proxy parses the protocol it was built for. The client hands it a request and it hands that request onward, so an application with no proxy setting never participates at all. For HTTPS the client needs an opaque channel, which the proxy supplies through CONNECT rather than by reading the request.

An SSH dynamic forward opens a local port that speaks SOCKS, and that port relays a TCP stream to whatever destination the client names. Protocols built on TCP generally work through it. UDP does not, unless a tool adds support explicitly. A local forward is narrower again: one local port mapped onto one fixed host and port, which serves a single known service and nothing more.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

A VPN moves packets. Everything the client routes into the tunnel crosses it, UDP and ICMP included, which is why it suits a network requirement rather than a single connection.

Somebody has to resolve the name

When the target name exists only in the remote network's DNS, whichever box performs the lookup must be able to see that zone. A web proxy does the lookup itself, so an internal name works through it even when the laptop cannot resolve the name at all. SOCKS can behave the same way, but only if the client forwards the name instead of connecting to an address it already resolved. That choice lives in the client, not in the server.

curl shows the split clearly: one flag passes the hostname to the proxy, another resolves it locally first. With local resolution an internal-only name fails before any tunnel is touched, and the error blames the proxy for what was really a DNS decision.

A VPN takes the third route by installing the private resolver and search domain beside the routes. That is convenient, and it manufactures a familiar illusion: a route that exists with a resolver that does not answer looks exactly like a dead tunnel, even though packets are reaching the far side.

When the network permits one exit only

Plenty of corporate networks allow outbound connections solely through an authenticated web proxy. OpenVPN and SSH can both be made to work there, the first by tunnelling its own transport through the proxy and the second through a proxy command that runs a small CONNECT helper.

Tunnels built on TCP survive that constraint, and a UDP-based VPN does not, which explains a great many configurations that work at home and fail in an office. A second cost is easy to miss: a TCP tunnel carried inside a proxied TCP connection now has two layers retransmitting, and under loss that pairing stalls in a way neither layer produces alone.

Chaining intermediaries is a different question from choosing a layer. Adding a second proxy or Tor changes who observes what, and position in the chain decides which hop sees ciphertext.

Order matters more than the number of hops. An outer hop watches an encrypted stream while an inner one sees the plaintext it carries, so a chain is only as private as its least careful link. Mixing protocols across hops does not automatically improve that. It mostly makes the failure modes harder to reason about.

A forged address is not one of the options

Crafting packets with somebody else's source address achieves nothing useful: replies travel to the real owner, and most networks drop the traffic outright. An intermediary is required precisely because the source cannot be invented, and that is the honest justification for all three designs.

It also bounds what any of them may claim. Appearing to originate from a particular address is a question about where that address is legitimately assigned and who may route it, not about which tool can fake a header. If a design assumes otherwise, the assumption fails at the first provider that filters it. Write the assumption down so the failure is recognisable when it arrives.

Decide by protocols and names

Reach for a proxy when a single web client needs a single web service and it has proxy settings. Reach for an SSH tunnel when a handful of known TCP services is enough and SSH access already exists. Reach for a VPN when several applications, non-TCP traffic, private DNS or a reusable path form part of the requirement.

Then verify with the real client and the real name. Loading a page through a proxy teaches you nothing about UDP, and getting one tool working over SOCKS teaches you nothing about the system resolver. Read which local address the process bound and which resolver answered. That is the difference between a path that works and one that happened to work once.