OCI Bastion RDP Failure: Troubleshooting Error 0x708 with VNC Console Access by creating local console connection

 

Introduction:

Oracle Cloud Infrastructure (OCI) provides Bastion as a secure and convenient way to access private resources without exposing them directly to the internet. Recently, while trying to connect to a Windows Server 2012 instance via RDP through a Bastion host, I encountered connection issues. Despite setting up SSH port forwarding, the RDP session would not establish. This experience highlighted an important consideration: while Bastion is ideal for many scenarios, there are situations where it may not work, and OCI’s Console Connection (VNC) can be a reliable alternative.

In this blog, I’ll walk you through the root cause of the Bastion failure, explain why it occurs, and guide you on how to use Console connections to access Windows instances.

Identifying the Problem: When Bastion Refuses RDP

After setting up the OCI Bastion session (as shown in the image above) to access my Windows Server 2012 instance, I attempted to initiate an RDP session using the following SSH port forwarding command:

ssh -i ssh-key-2025-12-01.key -N -L 3389:<IP>:3389 -p 22 <OCI_BASTION_SESSION_OCID>@<BASTION_HOST>

Despite the command executing successfully, my RDP client failed to connect, showing a connection error on the local machine.

Root Cause (Internal Lock: Error 0x708)

Error code 0x708, or a generic "internal RDP error," almost always points to a problem within the Windows Server instance itself, specifically with session management.

• Stuck/Conflicting RDP Session: Windows Server 2012 struggles if a previous RDP session was improperly closed (by closing the window instead of selecting "Log Off"). This leaves a user session in a "Disconnected" state (or ghost session).
• RDP Service Refusal: When a new connection (via the Bastion tunnel) attempts to connect, the Remote Desktop Services (TermService) sees the existing hung session and refuses the new interactive login, resulting in the 0x708 error. Since Bastion only provides a network tunnel, it cannot resolve this internal lock.

Alternative Solution: Using Console Connection (VNC Access)

When Bastion access fails—especially with Windows RDP—OCI provides a reliable alternative: Console Connection. This method allows you to establish a direct VNC-based connection to your Windows instance without relying on SSH port forwarding or RDP availability. 

Required Tools

To successfully create and use a VNC console connection, you will need:

• PuTTY / Plink – For creating the SSH tunnel required for the VNC session.
• PuTTYgen – To convert your private key into the .ppk format.
• VNC Client (e.g., RealVNC Viewer) – To access the Windows desktop stream through the final forwarded port. 

Step 1: Create a Console Connection

1.1. Navigate to your compute instance in the OCI Console.

1.2. Click Create Console Connection from the OS Management page.

1.3. Download the SSH keys (both public and private). If you already have an existing key pair, you can simply upload the public key. Then click the Create console connection button.

Step 2. Key Preparation: Converting the Private Key to .PPK Format

To ensure compatibility with the plink.exe utility, your private key file (which you obtained when creating the Console Connection) must be in the PuTTY Private Key (.ppk) format.

Follow these steps to perform the conversion:

2.1. Locate PuTTYgen: Navigate to your PuTTY installation folder (for example, C:\Program Files\PuTTY).

2.2. Open PuTTYgen: Double-click the puttygen.exe application to launch the PuTTY Key Generator window.

2.3. Load the Key:

• Click the Load button.

• In the file explorer window, change the filter to "All Files (*.*)" so you can see your original key file (e.g., ssh-key-2025-12-01.key (1)). 
• Select your original private key file and click Open. (You may need to enter a passphrase if your key has one).

2.4. Save as .PPK:

• Once the key is loaded successfully, click the Save private key button.
• When prompted about saving without a passphrase, click Yes (unless you intend to set one).

• Save the file with the name console.ppk in a memorable location (e.g., in your Downloads folder\privatekey).

Step 3: Connect to the Instance Using VNC

Once the console connection is active:

3.1. Copy the VNC Connection For Windows

Click the three dots (...) next to the active connection and select "VNC Connection For Windows" to reveal the detailed commands needed to create the local port-forwarding tunnel.

3.2. The Core Solution: Establishing the Two-Stage VNC Tunnel

The OCI Console Connection for Windows requires two distinct SSH tunnels to forward the VNC desktop stream from the cloud to your local machine. We will define variables and then execute the two tunnel commands sequentially.

3.2.1. Preparation: Define Variables for the plink.exe and the private key

Open Windows PowerShell as Administrator and run the following three lines to ensure the system knows where to find plink.exe and your private key.

# 1. Define the full path to the Plink executable
$PlinkPath= "C:\Program Files\PuTTY\plink.exe"

# 2.Define the full path to your converted .PPK key
$PrivateKeyPath= "C:\Users\amir.kordestani\Downloads\privatekey\console.ppk"

Note: The original OCI command is split into two parts below.

3.2.2. Stage 1: Connecting to the OCI Console Service (Tunnel 1)

This first tunnel connects to the OCI console endpoint over HTTPS port 443 and forwards the connection locally to port 5905.

• Action: Paste the first part of the original OCI script (everything before the ; sleep 5;) into PowerShell and replace plink.exe with your defined variable.

  & "$PlinkPath" -i "$PrivateKeyPath"  -N -ssh -P 443 -l <ocid1.instanceconsoleconnection> -L 5905:<ocid1.instance>:5905 <instance-console>

Wait for Initialization:

The Start-Job command will run the tunnel in the background. Wait a few seconds for it to fully initialize. The PowerShell window running this command will hang/freeze, You should see the output like the image below.

3.2.3. Stage 2: Connecting the VNC Port to the Tunnel (Tunnel 2)

This second tunnel connects to the first tunnel (listening on local port 5905) and forwards the VNC stream to local port 5900, where your VNC client will connect.

• Action: Open another Windows PowerShell as Administrator Paste the second part of the original OCI script (everything after the ; sleep 5;) and replace plink.exe with your defined variable.

# 1. Define the full path to the Plink executable
$PlinkPath= "C:\Program Files\PuTTY\plink.exe"

# 2.Define the full path to your converted .PPK key
$PrivateKeyPath= "C:\Users\amir.kordestani\Downloads\privatekey\console.ppk"

# then run the follwoing command.
& "$PlinkPath" -i "$PrivateKeyPath" -N -L 5900:localhost:5900 -P 5905 localhost -l <ocid1.instance>

Success Indication: The PowerShell window running this second command will hang/freeze. This is the expected behavior and confirms that both tunnels are active and ready for the VNC client. You should see the output like the image below.

Step 4. Connecting to the Local Console via VNC Client

With your PowerShell terminal window frozen (running the second Plink command), the VNC stream is now available on your local port 5900.

4.1: Launch Your VNC Client

Open your preferred VNC viewer application (such as RealVNC Viewer, TightVNC, or TigerVNC).

4.2: Enter the Connection Address

In RealVNC Viewer, Click File >> New Connection. In the address or server field of your VNC client, enter localhost:5900, as shown in the image below.

4.3. Connect to the VNC session

Double-click the VNC session you already created and connect to the Windows Server.

Step 5: Clear the original RDP error

Once you are connected, proceed immediately to the session troubleshooting steps (like running quser or using Task Manager to sign off the conflicting session) to clear the original RDP error.

Then run the command "logoff 1" to immediately log off the user assigned to session ID 1.

Conclusion: 

The RDP failure through OCI Bastion—often seen as Error 0x708—stems from a stuck or conflicting RDP session inside the Windows VM, not a Bastion or network issue. Because the Bastion tunnel only provides a pathway and cannot resolve internal Windows session locks, the Console Connection (VNC) becomes essential. This out-of-band access bypasses the broken RDP service entirely and provides direct graphical control of the VM. Using the two-stage VNC tunnel, you can clear the hung session, restart RDP services, and restore normal remote access. Once resolved, RDP via OCI Bastion resumes functioning reliably for ongoing administration.