Secure Remote Access to Hosting Panels with VPN and Bastion Hosts

When you manage multiple cPanel, DirectAdmin, Plesk or custom hosting panels across VPS, dedicated servers or colocation, the real challenge is not just performance—it is how people log in. Exposed admin URLs, shared passwords and open SSH ports are still the default in many teams, even though automated scans and credential stuffing attacks target these surfaces 24/7. A safer pattern is to move from “open to the internet” to a controlled VPN + bastion host architecture, where all remote access flows through a small, well‑hardened entry point. In this article, we will design that architecture step by step—network layout, firewall rules, user workflows and migration strategy—so you can secure hosting panels without making daily operations painful. The same principles apply whether your infrastructure lives on shared hosting, VPS, dedicated servers or colocation at dchost.com.

Why Direct Internet Access to Hosting Panels Is Dangerous

Leaving hosting panels and SSH ports open to the public internet looks convenient, but it creates a wide attack surface. Typical risks include:

• Credential stuffing: Attackers try leaked email/password pairs from other breaches against /whm, /cpanel, /plesk or custom admin URLs.
• Brute force and password spraying: Bots systematically guess weak passwords and target known usernames like admin, root or common email addresses.
• Exploiting panel vulnerabilities: When a new cPanel, Plesk or web server exploit appears, scanners immediately start hitting every open port they can find.
• Enumeration and reconnaissance: Even if login is blocked, response codes, error messages and banners can reveal software versions and internal structure.

You can (and should) still harden the panels themselves—rate limits, 2FA, IP allowlists and strong passwords. Our cPanel security hardening checklist covers many of these measures on the panel side.

But relying only on panel‑level protections means your most sensitive interfaces are still exposed to the whole internet. A stronger approach is to remove them from public reach entirely and require administrators to come in through a VPN and bastion host that you control and monitor.

Core Concepts: VPN, Bastion Host and Zero‑Trust Access

Virtual Private Network (VPN)

A VPN creates an encrypted tunnel between an administrator’s device (laptop, phone, tablet) and a private network. Once connected, the device receives an internal IP and can reach internal services as if it were on the office LAN.

If you want a refresher on the basics and protocol types, we have a separate guide on what a Virtual Private Network (VPN) is and why it matters.

Bastion Host (Jump Server)

A bastion host (or jump server) is a small, hardened server that acts as the single entry point into your infrastructure for administrative access:

• It is reachable only from the VPN network (not from the public internet directly).
• Admins SSH into the bastion, or access a web interface on it, and from there connect to internal servers or hosting panels.
• All admin activity can be logged and audited centrally.

Instead of dozens of servers each having exposed SSH or panel ports, the bastion concentrates that risk into one machine you can lock down very aggressively.

Zero‑Trust Approach to Admin Access

A zero‑trust model assumes no user, device or network segment is inherently trusted. Access is granted based on verified identity, device posture and least privilege, and it is re‑evaluated regularly.

In the context of hosting panels, zero‑trust means:

• Panel URLs are not publicly reachable.
• Every admin must authenticate to the VPN (ideally with MFA) before even seeing those URLs.
• From the VPN, they reach a bastion host that enforces additional access control and logging.

We have previously explored this in a broader context in our article on zero‑trust access to hosting panels and servers. Here, we will focus specifically on the VPN + bastion pattern and how to implement it step by step.

Reference Architecture: VPN + Bastion for Hosting Panels

Let’s define a concrete reference architecture you can adapt to your environment.

Key Components

• Admin devices: Laptops or workstations of system administrators, developers, support staff and sometimes trusted external partners.
• VPN gateway: A dedicated VPS or small cluster that terminates VPN tunnels (WireGuard, OpenVPN, IPsec) and assigns internal IPs to admins.
• Bastion host: A hardened Linux server reachable from the VPN network; it exposes SSH and possibly a small internal web UI used to relay access to hosting panels.
• Management subnet: A private network segment where the bastion and panel endpoints live.
• Hosting panel servers: cPanel, DirectAdmin, Plesk, custom panels and plain VPS instances.
• Central logging/monitoring: Your log stack (e.g. ELK, Loki, or any SIEM) and metrics/alerts platform.

Traffic Flow Overview

1. Admin starts VPN client, authenticates (user + password + MFA or certificate) and receives an internal IP address (for example, 10.20.10.25).
2. Firewall rules on the VPN gateway allow this VPN subnet to reach only the bastion IP and perhaps a few internal services (DNS, monitoring dashboards).
3. Admin opens SSH to bastion (for example, ssh [email protected]) or opens a browser to an internal URL on the bastion (for example, https://bastion.internal).
4. From the bastion, the admin connects to target servers over SSH or HTTP/HTTPS (for example, https://cpanel01.internal:2087).
5. All steps are logged: VPN login, SSH login to bastion, commands run, and connections initiated from bastion to target servers.

The core idea is that the only machines allowed to reach hosting panels on their admin ports (2083/2087 for cPanel, 8443 for Plesk, 2222 for DirectAdmin, 22 for SSH, etc.) are:

• the bastion host(s)
• and possibly a very small set of emergency IPs (for example, an on‑premise NOC range)

Designing Network Segments and Firewall Rules

Separate Management and Production Networks

A clean design separates traffic into multiple segments:

• VPN subnet: IP range assigned to admin devices when they connect to the VPN (for example, 10.20.10.0/24).
• Management subnet: Contains bastion and panel admin interfaces (for example, 10.20.0.0/24).
• Public/DMZ subnet: Production web servers, load balancers and reverse proxies that face the internet.

You can implement these as separate VLANs in colocation, as isolated networks on dedicated servers, or via virtual networks on VPS infrastructure at dchost.com.

Firewall Policy Blueprint

At a high level, firewall rules should implement the following policy:

• From internet to hosting panels: Block all direct access to panel ports (2083/2087/8443/2222/WHMCS‑like ports, SSH, RDP, etc.). Only allow HTTP/HTTPS to the public web frontends.
• From VPN subnet to bastion: Allow SSH (22) and HTTPS (if your bastion provides an internal web UI or reverse proxy for panels). Deny everything else by default.
• From bastion to management subnet: Allow SSH and specific panel ports to the relevant servers. Still apply least privilege (for example, only allow bastion to reach cpanel01 on 22/2087, not every port).
• From VPN subnet to management subnet directly: Block or at least heavily restrict; ideally, all access to management subnet goes through the bastion.

If you are building this on a VPS, tools like ufw, firewalld or raw iptables/nftables work well. Our guide on firewall configuration on VPS servers walks through practical examples for each option.

Implementing the VPN Layer

Choosing a VPN Technology

For admin access, you typically want:

• Strong encryption and modern ciphers.
• Per‑user identities (keys or accounts) for clean revocation and logging.
• Stable clients for Windows, macOS, Linux and often mobile.

Popular choices include:

• WireGuard: Modern, fast, simple configuration, great for per‑device keys.
• OpenVPN: Mature, widely supported, flexible but more complex.
• IPsec/IKEv2: Often built into OS clients; good for site‑to‑site and device VPN.

From a hosting‑team perspective, WireGuard is often a great starting point: small config files per admin, good performance and minimal overhead on a VPS or dedicated server.

User Identity and MFA

A VPN user should not be just “some laptop with a key file”. You want to tie access to a real person and enforce strong authentication:

• Issue unique keys/certificates per user and per device.
• Use MFA on a separate portal or identity provider if your VPN supports it.
• Document which VPN identities correspond to which people and which teams.

When an employee leaves or a contractor’s engagement ends, you revoke their VPN access first, then their bastion and panel accounts. A clean identity map makes this fast and auditable.

Split Tunnel vs Full Tunnel

You must decide whether the VPN will route all traffic from the admin device, or only traffic destined for internal subnets:

• Split tunnel: Only internal IP ranges (for example, 10.20.0.0/16) go through the VPN; internet browsing goes out locally.
• Full tunnel: All traffic, including web browsing, goes through your VPN and exits via your data center.

For most hosting teams, a split tunnel is enough if the VPN is used purely for administrative access. If you have strict regulatory or logging requirements, a full tunnel may be preferable so that admin web traffic while “on duty” is also monitored.

DNS and Internal Names

Inside the VPN, use an internal DNS zone such as *.internal or *.corp (not a public TLD you own) for management endpoints:

• bastion.internal → 10.20.0.10
• cpanel01.internal → 10.20.0.101
• plesk01.internal → 10.20.0.102

This keeps admin URLs distinct from public domains and gives you flexibility in renaming or moving services without changing bookmarks on every admin’s laptop.

Building the Bastion Host

Base Operating System and Hardening

Use a lean, long‑term‑support Linux distribution (for example, Debian or AlmaLinux) as the base for your bastion. Apply hardening practices similar to any critical VPS:

• Disable direct root SSH login; use sudo and per‑user accounts.
• Require SSH keys and disable password authentication.
• Restrict SSH to VPN subnet IPs.
• Apply automatic security updates and reboot policies.
• Deploy Fail2ban or similar to react to suspicious login attempts, even from within the VPN.

Our VPS security hardening checklist provides a practical baseline you can apply almost as‑is to your bastion host.

SSH Key Management and Access Sharing

The bastion is where SSH access should be most carefully managed. Instead of sharing one key or one user, every admin gets:

• a unique Unix user on the bastion (alice, bob, support01)
• a unique SSH key, stored in version‑controlled infrastructure code or an internal directory

This makes it easy to rotate keys, revoke old ones and see who did what. For more detail on safe SSH workflows, see our article on SSH key management and access sharing.

How the Bastion Exposes Hosting Panels

You have two main options to give admins access to panel UIs via the bastion:

1. SSH Port Forwarding from Admin Devices

Admins establish SSH tunnels from their laptops to the bastion, which forwards traffic to panel ports:

• Example: ssh -L 8443:cpanel01.internal:2087 [email protected]
• Then open https://localhost:8443 on the laptop browser to reach WHM on cpanel01.internal.

Pros:

• No additional web app on the bastion.
• Works well with existing SSH tooling and keys.

Cons:

• Less user‑friendly for non‑technical staff.
• Multiple tunnels can get messy when managing many servers.

2. Reverse Proxy on the Bastion (With Strong TLS Controls)

Alternatively, you can run Nginx or Caddy on the bastion and expose a small internal portal (for example, https://panels.internal/) which reverse‑proxies to the actual panel endpoints. In this model:

• Admins browse to a single internal URL after connecting to the VPN.
• The bastion, acting as a reverse proxy, connects to cpanel01.internal:2087, plesk01.internal:8443, etc.

If you go this route, you should protect the reverse proxy itself extremely well, ideally with mutual TLS (mTLS) so that only clients with a valid certificate can talk to it at all. We describe this in detail in our guide on protecting admin panels with mTLS on Nginx.

Command and Session Logging

Because bastion hosts are choke points, they are a perfect place to collect logs:

• Record who connected when (SSH logins, VPN user identity in metadata).
• Use auditd or advanced shells (or even session recording tools) to log critical commands.
• Ship logs to a centralized system (ELK, Loki, etc.) with long enough retention to support investigations and compliance.

If you already centralize logs from multiple VPS instances (for example, using Loki + Grafana as we describe in our centralized log management guide), just add the bastion as another log source and tag its events clearly.

Access Workflows for SSH, Panels and Custom Tools

SSH Access to VPS and Dedicated Servers

A clean SSH workflow looks like this:

1. Admin connects to VPN, receives internal IP.
2. Admin SSHes into bastion: ssh [email protected].
3. From bastion, admin uses either:

• Per‑user keys on target servers: ssh [email protected], but keys are centrally managed on bastion.
• SSH agent forwarding (if policy allows) so bastion does not store private keys itself.

For small teams, you can enforce that all production SSH must originate from the bastion, not from random admin IPs, by firewalling servers to allow SSH only from the bastion’s IP.

Access to cPanel/WHM, Plesk, DirectAdmin

Once VPN and bastion are in place, classic panel URLs become internal‑only:

• https://cpanel01.internal:2087 (WHM)
• https://plesk01.internal:8443
• https://da01.internal:2222

Admins reach them via:

• SSH port forwarding from local browser (for power users).
• Internal reverse proxy portal with mTLS (for larger teams and mixed skill levels).

You still keep panel‑level controls—strong passwords, 2FA, IP restrictions on the panel if supported—but the biggest change is that attackers on the open internet cannot even see the login pages.

Third‑Party Tools and Internal Apps

The same bastion and VPN used for hosting panels can safely expose:

• Monitoring dashboards.
• Internal Git or CI/CD interfaces.
• Custom support/admin tools.

Just ensure your firewall rules and reverse proxy configuration define which apps are reachable from which user groups. If some tools are more sensitive (billing, full client data exports), consider separate bastions or stricter mTLS profiles.

Operational Practices: Onboarding, Offboarding and Auditing

Onboarding a New Admin

A secure and smooth onboarding process might follow this order:

1. Create an identity in your directory or internal admin list.
2. Issue VPN credentials/keys for that person and register their devices.
3. Create a bastion Unix user with SSH key and appropriate groups (for example, “support”, “devops”).
4. Grant access on specific hosting panels according to role (read‑only vs full admin).

By centralizing the first steps on VPN + bastion, you avoid sending direct cPanel or root credentials via email or chat.

Offboarding and Access Reviews

When someone leaves or changes role:

• Revoke VPN access (keys, certificates, accounts).
• Lock or remove their bastion user.
• Rotate any shared panel credentials they might have used.
• Review logs from their last weeks for unusual access patterns.

Quarterly access reviews—who has VPN, who has bastion accounts, who has panel admin rights—help catch privilege creep before it becomes a risk.

Monitoring and Alerts

Because all flows pass through VPN and bastion, you get powerful detection signals:

• Alert on VPN logins from unusual countries or at odd hours for the user.
• Alert on multiple failed SSH attempts on the bastion, even from the VPN subnet.
• Track panel logins from the bastion IP and correlate with bastion user sessions.

If you are already using centralized metrics and alerts for VPS nodes (for example, Prometheus + Grafana—see our guide on centralized server monitoring and alerting), treat the VPN gateway and bastion as top‑tier monitored services.

Choosing Infrastructure at dchost.com for VPN + Bastion

From an infrastructure perspective, this architecture is lightweight:

• VPN gateway: A small VPS with adequate CPU for encryption and a public IP.
• Bastion host: Another small VPS (or shared with VPN for very small setups, though we prefer separating them).
• Panel servers: Existing shared hosting, VPS, dedicated or colocation servers where your sites already live.

On dchost.com you can:

• Use a VPS as VPN gateway and bastion for flexible routing and firewalling.
• Put high‑value production sites on dedicated servers or colocation and connect them to the same private management network.
• Keep smaller or low‑risk sites on shared hosting, but still restrict cPanel/DirectAdmin access behind VPN where possible.

If you are unsure how many vCPUs or how much RAM you need for a VPN/bastion combo versus your web workloads, our resource planning guide on choosing VPS specs for WooCommerce, Laravel and Node.js gives you a practical way to size VPS instances by load profile.

Migration Plan: From Public Panels to VPN + Bastion

Moving to this architecture does not need to be disruptive. A staged approach works well:

Phase 1 – Prepare Infrastructure

• Deploy VPN gateway VPS and test connectivity from a few admin devices.
• Deploy bastion VPS, harden SSH, integrate with your logging stack.
• Create internal DNS names for bastion and panel servers.

Phase 2 – Pilot with a Small Admin Group

• Onboard 1–3 admins to the new flow (VPN → bastion → panels).
• Keep public panel access open but start using the VPN path by policy.
• Gather feedback: is SSH port forwarding enough, or do you need a reverse proxy portal?

Phase 3 – Lock Down Server‑Side Access

• Restrict SSH on panel servers to accept connections only from bastion IPs.
• Restrict panel admin ports (2083/2087/8443 etc.) to bastion IPs via host firewall or security groups.
• Keep a short “break glass” rule for a known static IP if needed (for example, office IP).

Phase 4 – Close Public Panel Access

• Remove public DNS records pointing to panel ports.
• Verify that panel logins only appear from bastion IP.
• Communicate to all admins and vendors that VPN + bastion is now mandatory.

Phase 5 – Review, Document and Automate

• Write a short runbook: “How to access production panels safely.”
• Automate VPN account creation and bastion user setup via scripts or Ansible/Terraform.
• Schedule quarterly reviews of VPN users, bastion accounts and panel admin rights.

If you maintain multiple environments (dev, staging, production), you can adopt the same pattern at different strictness levels. We discuss environment separation options in our article on hosting architecture for development, staging and production.

Summary and Next Steps

Exposing hosting panels and SSH ports directly to the internet is no longer a tolerable risk for serious projects. Automated scans, password reuse and panel‑specific exploits mean that “hidden” URLs and “strong enough” passwords will eventually be tested. A VPN + bastion host architecture shrinks that attack surface dramatically: admins must authenticate into your private network first, then reach hosting panels through a small, hardened jump point you fully control, monitor and log.

The practical steps are straightforward: deploy a VPN gateway on a dchost.com VPS, add a bastion host with strict SSH key management, rewire firewall rules so only bastion can reach admin ports, and gradually move teams from public URLs to the new flow. Combine this with panel‑side hardening, proper backup and a basic zero‑trust mindset, and your hosting stack becomes much harder to compromise—without making daily operations painful.

If you would like help choosing the right mix of shared hosting, VPS, dedicated servers or colocation to implement this architecture, our team at dchost.com can review your current setup and propose a realistic plan. Start by mapping which panels you have today, who uses them and from where, then design your first VPN + bastion prototype. With a few careful steps, remote access to your hosting panels can go from “always a worry” to “just another well‑managed service”.