Replacing a Bastion Server with OpenVPN Access Server: Benefits of a Zero Trust Upgrade
By Rohit Kalbag
A bastion host was the sensible answer when all you needed was one locked-down way into a private network. It still works. But it keeps an SSH or RDP service open to the whole internet, and once someone is through, they're on your network. OpenVPN Access Server replaces that edge host with a self-hosted, Zero Trust application broker. Here's how it compares with a bastion, and with the managed bastion services from Azure, AWS, and Google Cloud.
The short answer: A bastion host (or bastion server) is a hardened, internet-facing machine that admins connect to over SSH or RDP before reaching private systems. Its weak spots are the exposed login service and the broad network access it hands out. You can replace it with a cloud provider's managed bastion (Azure Bastion, AWS Session Manager, Google Cloud IAP), which works well inside a single cloud. Or you can use a self-hosted broker such as OpenVPN Access Server, which covers multiple clouds and on-premises networks, grants identity-based access to specific applications rather than whole subnets, and keeps the whole access layer under your control.
What is a bastion host?
A bastion host (also called a bastion server) is a hardened, single-purpose machine at the edge of a private network. It acts as the controlled gateway into that network. Administrators connect to the bastion first, usually over SSH or RDP, and from there reach internal servers, databases, and services that aren't directly reachable from the internet.
The idea is simple: instead of exposing dozens of internal machines, you expose one tightly locked-down host and route all administrative access through it. That host becomes your single point for logging, patching, and monitoring.
Bastion host vs. jump server
The terms overlap and are often used interchangeably. A bastion is defined by its position (hardened, at the internet edge). A jump server is defined by its function (pivoting between security zones, including internal ones). This article focuses on the internet-facing bastion. If you're dealing with internal jump boxes, see our jump-server guide, which covers that pattern in depth.
Are bastion hosts still used?
Yes, widely, especially for SSH access into AWS VPCs and for RDP into Windows servers. What has changed is that you no longer have to build one yourself. All three major cloud providers now sell managed alternatives. Many security teams also see "one exposed login box that grants network access" as out of step with Zero Trust, which asks every connection to prove who it is and reach only what it's allowed to.
Teams still reach for a bastion when they need to:
- Keep private resources off the internet. Production servers, admin panels, and databases stay in private subnets, and only the bastion is reachable from outside.
- Reach cloud instances without public IPs. Engineers SSH or RDP into instances in a private subnet on AWS, Azure, or GCP.
- Audit administrative sessions in one place. Every session passes through one host that can be logged and reviewed.
- Give contractors temporary access. External parties get a controlled way in without opening the wider network.
What are the risks of using a bastion host?
The bastion model has structural weaknesses that get harder to ignore as environments grow and audits get stricter:
- It's an internet-facing login service. A bastion listens for SSH or RDP connections from anyone. That makes it one of the most scanned and brute-forced machines you run, and it depends entirely on you patching it quickly. Flaws like CVE-2024-6387 ("regreSSHion"), an unauthenticated remote code execution bug in OpenSSH's server, show why an exposed sshd is a real risk.
- "Connect, then roam." Once a user is on the bastion, they usually have broad network reach. Access is network-level, not application-level, so stolen credentials or a compromised host give an attacker a starting point for lateral movement.
- SSH key and credential sprawl. Keys, RDP credentials, and authorized_keys files multiply across users and teams, and revoking them cleanly when someone leaves is tedious and easy to get wrong.
- A single point of failure. If the bastion is down, nobody gets in, and someone has to keep patching, hardening, and monitoring it.
- Weak identity integration. Enforcing MFA, group-based policy, and clean offboarding on a Linux or Windows bastion usually takes extra tooling.
Is a bastion host a firewall? No. A firewall filters traffic by rule. A bastion is a host that users log in to. The two are often deployed together: the firewall allows traffic only to the bastion, and the bastion controls onward access.
Your options for replacing a bastion host
There's no single right replacement. It depends on where your resources live and what your team needs to reach. Here's a fair comparison of the common paths:
|
Option |
Where it works |
What users reach |
Who runs it |
|---|---|---|---|
|
Self-managed bastion VM |
Anywhere |
The network behind it (SSH/RDP, then onward) |
You: patching, hardening, keys |
|
Azure virtual networks (and peered VNets) |
RDP/SSH to Azure VMs without public IPs; tiers from Developer to Premium |
Microsoft (managed PaaS) |
|
|
AWS (Session Manager also supports on-prem nodes running the SSM Agent) |
Shell or SSH/RDP sessions to managed nodes, authorized by IAM |
AWS (managed) |
|
|
Google Cloud |
SSH, RDP, and other TCP to VMs without external IPs, authorized by IAM |
Google (managed) |
|
|
Any cloud, on-prem, or hybrid; one broker across all of them |
Specific applications or segments, by identity and group policy |
You, on your own infrastructure |
When a managed bastion is the right call: if nearly everything you manage runs in one cloud and your admins mainly need SSH or RDP, the provider's own service is quick to adopt and removes the exposed host. These services are strong, and worth using where they fit.
Where they run out: each one covers its own cloud and its own identity system (Azure, AWS IAM, Google IAM). That means one access policy per provider, plus a separate answer for on-premises systems. Most are also built around admin sessions, not general access to internal apps and databases, and some have hard limits. EC2 Instance Connect Endpoint, for example, caps a TCP connection at one hour and 20 concurrent connections per endpoint. And the control plane is always the cloud provider's, which matters if you need to show that your access layer is fully under your control.
When Access Server is the better replacement
Consider a self-hosted broker such as Access Server when two or more of these apply:
- You run across more than one cloud, or cloud plus on-prem. One policy model and one identity integration cover AWS, Azure, GCP, and your data center. Access Server Link can deploy it into AWS, Azure, or GCP in minutes.
- People need more than SSH and RDP. Developers and contractors need internal web apps, databases, and APIs, not just a shell.
- You're being audited. Under DORA, NIS2, and the CRA, or SOC 2, application-level, identity-driven access with enforced MFA is easier to evidence than network access through an exposed host.
- Data sovereignty matters. For UK and EU organizations, running the data plane, control plane, and configuration yourself avoids the CLOUD Act questions that come with US-operated access services.
- You've adopted a Zero Trust strategy. "Connect, then roam" is at odds with least-privilege access.
How Access Server replaces the bastion
Here's what changes when you swap the bastion for Access Server. We cover each benefit in more depth in our jump-server replacement guide. Below is the bastion-specific summary.
No exposed SSH or RDP service. Access Server is a VPN server, so it does accept inbound connections, but what it exposes is very different. A bastion runs a login service that responds to anyone. Access Server exposes only the OpenVPN protocol, whose control channel is protected by an HMAC signature check. Packets without a valid signature are dropped very early, before the TLS handshake begins, so port scans and unauthenticated probes get no response. TLS Crypt also encrypts the control channel and is the default on new installations of Access Server 2.9 and later.
Access to the application, not the network. With domain routing (Access Server 3.1.0 or newer), users are granted a named application rather than a route to a subnet. Access Server answers with a stand-in address from an internal pool (100.64.0.0/10 by default) and forwards only that connection. The client never learns the real IP or subnet, and has no network path to neighboring systems through that connection. See the full technical breakdown for how the DNS and NAT steps work, and use access control rules for segment-level policy where you need it.
Identity instead of SSH keys. Access Server authenticates against your directory with SAML, LDAP, or RADIUS (for example, Microsoft Entra ID via SAML), with TOTP-based MFA and group-based policy. When someone leaves and you disable them in your identity provider, they can no longer authenticate, and there are no orphaned keys left on a bastion.
No single point of failure. Access Server can run as an active-active cluster: every node accepts connections at the same time, load is spread by DNS round-robin, and if one node fails, another picks up the load. All nodes share one subscription.
You pay for concurrent connections, not seats. Access Server is licensed by concurrent connected devices. If you have 100 devices across 50 users but only 25 are ever connected at peak, you need a 25-connection subscription. You can try it free with two connections.
Self-hosted and open-source at the core. You run the entire stack, so no third-party vendor sits in the connection path. The OpenVPN protocol it's built on has been independently audited, not a proprietary black box.
How to migrate off a bastion host
Moving off a bastion is usually gradual, not a single cutover:
- Inventory what users reach through the bastion (hosts, ports, databases, internal apps) and who uses each.
- Deploy Access Server on your own infrastructure or in your cloud, and connect it to your identity provider.
- Define per-application policies by user or group, using domain routing for named apps and access control rules for segments.
- Run both side by side, moving one team at a time while the bastion stays available as a fallback.
- Close the door: remove the security group or firewall rules allowing port 22/3389 from the internet, release the bastion's public IP, clean out authorized_keys and shared RDP accounts, and retire the bastion image so it isn't rebuilt by accident.
Want to see it in practice? Here's how one NOC team moved from jump hosts to Access Server on AWS.
Ready to see how OpenVPN can help protect your organization from attacks?
Try the self-hosted Access Server solution or the managed CloudConnexa service for free, no credit card required.
See Which One is Right for YouFAQ
What is a bastion host?
A bastion host (or bastion server) is a hardened machine at the edge of a private network that administrators connect to, usually over SSH or RDP, before reaching internal systems. It limits exposure to one host, but that host is open to the internet and typically gives broad network access once you're on it.
Are bastion hosts still used?
Yes, but they're increasingly being replaced. Cloud providers offer managed alternatives (Azure Bastion, AWS Session Manager, Google Cloud IAP), and Zero Trust approaches like OpenVPN Access Server grant identity-based access to specific applications without an exposed login server.
Is a bastion host the same as a VPN?
No. A bastion is a host you log in to and then move on from, giving network-level access. A VPN creates an encrypted tunnel from your device. Access Server goes further than a traditional flat VPN: users authenticate against your identity provider and reach only the applications they're authorized for.
What's the difference between a bastion host and a jump server?
They overlap heavily. A bastion is defined by its hardened, internet-facing position, and a jump server by its role of pivoting between security zones, including internal ones. Our jump-server guide covers the internal-pivot case.
Do I still need a bastion if I use Azure Bastion or AWS Session Manager?
No. Those services replace the self-managed bastion inside their own cloud. The gap shows up when you also need access to other clouds, on-prem systems, or non-admin applications. Access Server can cover all of those with one policy model.
Can Access Server replace an AWS bastion host?
Yes. Access Server can run inside your VPC and give authenticated users encrypted access to private-subnet resources, so those instances don't need public IPs and you don't need a standing bastion. It's available on AWS Marketplace or through Access Server Link.
Isn't Access Server also exposed to the internet?
It accepts inbound VPN connections, but it exposes only the OpenVPN protocol, not an SSH or RDP login. Its HMAC-protected control channel drops unauthenticated packets before the TLS handshake, so scans and brute-force probes get no response.
What happens to my SSH keys?
Access moves to your identity provider, so instead of keys scattered across authorized_keys files, you get centrally managed access that's revoked when you disable the user.
Is Access Server cheaper than maintaining a bastion?
Often, once you count the time spent hardening, patching, and monitoring an internet-facing host. Access Server is licensed by concurrent connections rather than per seat, and you can start free with two connections.
Ready to close the door on your bastion?
If your bastion host has become a liability rather than an asset, Access Server gives you a self-hosted, Zero Trust way to reach everything it used to, without the exposed login service, the broad network access, or per-seat pricing.
Try Access Server free: two connections, no credit card required. Get a quote to see what concurrent-connection licensing would cost for your team.
Further reading
- Replacing a Jump Server with OpenVPN Access Server: From Jump Box to Zero Trust
- Self-Hosted ZTNA: How Domain Routing Turns Access Server Into an Identity-Aware Proxy
- Understanding Clustering with OpenVPN Access Servers
- OpenVPN Access Server vs. NetBird
- Buy, Build, or Self-Host: A European Decision Framework for Replacing Your ZTNA Vendor
