Access Intranet Without VPN: 3 Secure Alternatives Compared

"How do we give external colleagues access to internal systems?" This question lands on every operations team's desk at least once a quarter. The traditional answer is a VPN, but client distribution, routing conflicts and over-broad account permissions are pushing more teams to look for a VPN alternative. For small and medium teams, zero-trust intranet access built on an open source bastion host is becoming the more pragmatic choice: instead of granting everyone a network-layer tunnel, it moves the "who can reach which system" decision to the application layer and keeps a full audit trail.

This article compares three common approaches — public port forwarding, a self-hosted VPN, and a bastion host with a security gateway reverse tunnel — and shows how Next Terminal lets you securely reach internal SSH, RDP and Web systems without rolling out a VPN. All steps follow the current v3.7.2 documentation.

Why "no VPN" is becoming common

A VPN solves network-layer connectivity: once a client connects, it is as if the machine were plugged into the internal switch. The problems live in exactly that property.

• Client and routing overhead: every user needs a client, a config, and help with disconnects and reconnects. Cross-platform experience varies, and IT support costs grow.
• Coarse permission boundary: a VPN opens a whole network, not a specific asset. A leaked account often grants overly broad network access, inviting lateral movement.
• Hard-to-enforce audit: a VPN usually records "who connected, for how long", but rarely answers "who accessed which server at what time, and what did they do" — a gap for operations audit and compliance.

That is why "zero trust replaces VPN" is gaining ground: instead of trusting anyone who gets inside the network, verify identity and authorization on every single access.

Approach 1: Public port forwarding — cheapest, most dangerous

Mapping an internal server 192.168.1.10:22 to a public port like 1.2.3.4:2222 via a router or cloud security group is the lowest-effort path — it works in minutes. The cost is just as immediate:

• Exposed attack surface: once ports 22 or 3389 are reachable, scanners and brute-force scripts arrive within hours, and the logs fill with failed logins.
• No identity or authorization: port forwarding solves connectivity, not who may reach which asset. A reachable port is a port everyone can try.
• Almost no audit: there is no single place to trace who accessed what.

Port forwarding fits temporary debugging and personal projects; it does not hold up once multiple people and compliance are involved.

Approach 2: Self-hosted VPN — network reach, but a blurry boundary

Self-hosted VPNs such as WireGuard or OpenVPN offer strong encryption and a natural post-connect experience, making them the first "not port forwarding" option. In multi-user scenarios their limits are also clear:

• Connect = inside the network: joining a VPN grants reachability to the whole internal segment by default. Fine-grained "who can reach which machine" still requires extra network policies.
• Expensive account leaks: one leaked VPN credential hands over the internal boundary, and the blast radius is hard to contain quickly.
• Weak audit: VPN logs rarely link to "who operated which server"; forensics depend on per-host logs.

VPNs suit office networks controlled by network admins with a stable user base. For high-frequency needs like "grant a contractor temporary access", the account lifecycle and audit cost of a VPN is significant.

Approach 3: Bastion host + security gateway — zero trust, reverse tunnel

This is the recommended direction: deploy a lightweight security gateway inside the internal network. It dials out to the bastion host over a WebSocket reverse tunnel, so internal servers need no inbound public port, no port mapping, and no VPN. When a user reaches an asset through the bastion, traffic is forwarded by the gateway to the internal target.

Compared with the first two approaches, this path has several key advantages:

• Identity first: every access passes through the bastion's unified login and authorization — verify before forwarding, by default.
• Per-asset fine-grained authorization: the grant targets "this SSH/RDP/Web asset", not a whole network — least privilege by construction.
• Unified audit and recording: sessions are recorded and replayable; who accessed what and when is fully traceable.
• No public ports: the gateway connects outward, which naturally suits cloud VPCs, customer sites and isolated datacenters.

Protocol coverage is not limited to SSH — RDP, VNC and Telnet can also be forwarded through the security gateway. Combined with the built-in SSH proxy server and RDP proxy server, users can work directly in the browser or through their familiar local client tools, balancing ease of use with existing workflows.

A typical access chain looks like this: the user's browser or local client first signs in to the bastion host and passes authorization, then the bastion delivers the request over the WebSocket reverse tunnel to the intranet security gateway, which forwards it to the target asset. Throughout the chain there is no open inbound port on the intranet side, leaving scanners nothing to find — the most visible difference from port forwarding and VPN.

If you are evaluating a JumpServer alternative or a Teleport alternative, the reverse-tunnel capability and audit completeness of the security gateway are dimensions worth comparing closely.

Comparing the three approaches

Approach	Connection direction	Identity / authorization	Audit	Best for
Public port forwarding	Inbound direct	None	Almost none	Temporary debugging, personal projects
Self-hosted VPN	Inbound (gateway)	Network layer, coarse	Weak	Stable office networks, fixed users
Bastion host + security gateway	Reverse tunnel (outbound)	Application layer, per asset	Session recording, full audit	Multi-network, external collaborators, compliance

Approach 3 replaces "network-layer access" with "identity and authorization first" — the core difference from VPN, and the most concrete form of zero trust in practice.

Landing approach 3: reverse tunnel + per-asset authorization

Landing approach 3 needs three pieces: a lightweight gateway that connects out, a bastion host that owns identity and authorization, and a per-asset authorization model. Below we use the open source bastion Next Terminal as a concrete example — it packages the gateway, authorization, and session audit out of the box, and the flow is largely similar in other bastions. Once you understand this structure, you can apply it to whichever tool you choose.

Using "an external user reaches a Linux server on the company intranet" as the example, landing approach 3 is really about a few design decisions rather than which commands to type — once you understand these, the specific tool is just an implementation detail.

1. Where the gateway lives, and who is exposed

Key point: the gateway dials out, so no server in its network needs an inbound public port. You only need one machine that can reach the target internal assets to host the gateway; it calls back to the bastion on its own. For multi-site or multi-VPC setups, place one gateway per network and manage them all from a single bastion — no separate public entry per network.

2. How assets are onboarded, and how fine the authorization granularity is

Once assets are onboarded, the real question is whether you authorize a whole network segment or a specific asset. Prefer per-asset: expose only the few servers a given user group needs, rather than authorizing an entire VPC at once. That way, even if an account is compromised, lateral movement is contained to the smallest scope.

3. Audit and recording as a default

The main advantage over VPN is traceability. Make session recording and command logging a default-on practice, not an afterthought. Who accessed which server, when, and what they did should be replayable from a single place — this serves both compliance and day-to-day troubleshooting.

4. Accommodating native client habits

The browser is the default bastion experience, but many ops people prefer local SSH or RDP clients. If that matters for your team, the solution should support both "browser, out of the box" and "native client via proxy" paths, so people keep their workflow while access still routes through the bastion's authorization and audit.

In Next Terminal's case, gateway reverse tunnel + per-asset authorization + session audit are available out of the box and cover all four points above; see Security Gateway, Assets and Asset Access for specifics. Other bastions follow the same approach, differing mainly in UI.

Pitfalls to avoid when you roll this out

Approach 3 shrinks the attack surface, but the bastion host becomes the single external entry — a few mistakes are worth getting ahead of.

Asking the gateway for an inbound port on the internal server is the most common misunderstanding. The gateway dials out, so the internal target needs no inbound public port and no public IP; you only need a machine that can reach the target network. For multiple sites or VPCs, drop one gateway per network and select it when creating assets — no separate public entry per network.

Authorizing a whole network segment is the laziest and most dangerous move. Granting an entire VPC at once means a compromised account can move laterally across all of it. Authorize only the few servers a user group needs, and the blast radius stays minimal.

A plaintext bastion deployment defeats the purpose. The security gateway's encrypted communication relies on server-side HTTPS, so configure a valid certificate; enable 2FA or passkeys for the admin UI facing the internet, and review session recordings so "who accessed what" becomes part of routine inspection.

If you are migrating from port forwarding, a safer order is: close the externally exposed SSH/RDP ports first, onboard assets into the bastion with per-asset authorization, verify permissions, and only then remove the public port mappings and security-group rules — avoid a blind spot from old and new paths running in parallel. And you need not tear down the VPN right away: the bastion solves controlled, per-asset access with audit, while a VPN still has value in the few cases that need full network-layer interconnectivity (for example, a development environment that spans everything). The two can coexist.