docs(networking): document Console access over AWS PrivateLink

modules/networking/pages/configure-privatelink-in-cloud-ui.adoc

@@ -70,10 +70,95 @@ include::networking:partial$private-links-aws-client-vpc-setup.adoc[]
 
 == Access Redpanda services through VPC endpoint
 
-After you have enabled PrivateLink for your cluster, your connection URLs are available in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console.
+After you have enabled PrivateLink for your cluster, your connection URLs for the Kafka API, Schema Registry, HTTP Proxy, and Redpanda Console are available in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console.
 
 include::networking:partial$private-links-access-rp-services-through-vpc.adoc[]
 
+If you are connecting from a workstation outside the client VPC, see <<access-redpanda-console-from-a-workstation>>.
+
+[#access-redpanda-console-from-a-workstation]
+== Access Redpanda Console from a workstation
+
+For a private BYOC cluster, Redpanda Console is exposed through the PrivateLink endpoint (or through another private route into the cluster VPC, such as VPC peering or a transit gateway), so a workstation outside the client VPC cannot resolve or reach the Console URL directly. To open Redpanda Console from a laptop, first connect the workstation to the client VPC over a VPN, then sign in to Redpanda Cloud Console and navigate to the cluster.
+
+Common VPN options:
+
+* AWS Client VPN attached to the client VPC (described below).
+* A corporate VPN configured with a DNS forwarder that resolves `<cluster_domain>` against the client VPC's DNS resolver.
+* An SSH SOCKS5 proxy through a bastion host in the client VPC.
+
+The following diagram shows the network path from a workstation, through the VPN, into the client VPC, and across PrivateLink to Redpanda Console:
+
+....
+Workstation
+  │  (public internet, OpenVPN tunnel, mutual TLS)
+  ▼
+AWS Client VPN endpoint        ← AWS-managed; not PrivateLink
+  │  (workstation is now logically inside the client VPC)
+  ▼
+client VPC subnet
+  │  (VPC routing; DNS resolved via VPC resolver to a private IP)
+  ▼
+PrivateLink VPC endpoint ENI   ← PrivateLink begins here
+  │  (AWS PrivateLink service network, not on the public internet)
+  ▼
+Redpanda cluster VPC → Console load balancer → Redpanda Console
+....
+
+The client VPN tunnel itself does not use PrivateLink. The VPN's role is to place the workstation logically inside the client VPC; the private connection to the cluster is always the PrivateLink endpoint. This is true regardless of how a client reaches the client VPC (client VPN, corporate VPN, peered network, transit gateway, SSH bastion, or an EC2 instance inside the VPC).
+
+=== Set up AWS Client VPN
+
+For full setup instructions, see the https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-getting-started.html[AWS Client VPN Administrator Guide^]. The settings specific to Redpanda PrivateLink are:
+
+* *Authentication*: mutual certificate authentication. Generate a CA, server certificate, and client certificate; upload the server certificate and the CA certificate to AWS Certificate Manager (ACM).
+* *Client IPv4 CIDR*: a CIDR between `/22` (minimum) and `/12` (maximum) that does not overlap the client VPC CIDR. For example: `10.100.0.0/22`.
+* *DNS server IP addresses*: the IP of the client VPC's DNS resolver (the second usable IP in the VPC CIDR). For a default VPC with CIDR `172.31.0.0/16`, use `172.31.0.2`. This is what makes PrivateLink hostnames resolve to the endpoint's ENI IPs from connected clients rather than to public DNS.
+* *Split-tunnel*: enabled. Only traffic destined for the client VPC CIDR is routed through the VPN; the rest stays on the local internet.
+* *VPC ID*: the client VPC where the PrivateLink endpoint lives.
+* *Target network association*: associate the endpoint with a subnet in the same VPC as the PrivateLink endpoint.
+* *Authorization rule*: allow your client CIDR to reach the client VPC CIDR.
+
+The client VPN endpoint takes several minutes to reach the *Available* state after the subnet association is created.
+
+Allow inbound from the client VPN security group on the PrivateLink endpoint's security group, on port `443` (Console / Schema Registry) and on the Kafka API and HTTP Proxy ports (`30000-35999`, covering both the seed and per-broker ports).
+
+=== Connect using AWS VPN Client
+
+. Install the https://aws.amazon.com/vpn/client-vpn-download/[AWS VPN Client^] for macOS or Windows.
+. From the AWS Console, download the client VPN endpoint configuration file (`.ovpn`). Add your client certificate and private key inside `<cert>...</cert>` and `<key>...</key>` blocks at the bottom of the file.
+. Open AWS VPN Client and choose *File* > *Manage Profiles* > *Add Profile*. Select the `.ovpn` file and give the profile a name.
+. Select the profile and click *Connect*. The connection establishes in a few seconds.
+
+To verify, run the following from the workstation:
+
+[,bash]
+----
+dig +short console-<id>.<cluster_domain>
+----
+
+The response should be a private IP from the client VPC's CIDR range. For example:
+
+[,bash,role=no-copy]
+----
+172.31.0.97
+----
+
+If the response shows a public address (for example, the cluster VPC's internal LB IPs such as `10.x.x.x`), the VPC's DNS resolver was not pushed to the client. Re-check the *DNS server IP addresses* setting on the client VPN endpoint.
+
+=== Open Redpanda Console through the Cloud Console left navigation
+
+With the VPN connected, sign in to the Redpanda Cloud Console at https://cloud.redpanda.com[cloud.redpanda.com^] and select your cluster.
+
+. The cluster *Overview* page loads as normal; it is served by the Redpanda Cloud control plane and does not depend on the VPN.
+. Click any item in the cluster's left navigation (*Topics*, *Brokers*, *Consumer groups*, and so on). These views are served by Redpanda Console at `https://console-<id>.<cluster_domain>`. With the VPN connected, your browser resolves the hostname to the PrivateLink endpoint's ENI in the client VPC and the views load.
+. If the left navigation does not load (the page hangs or returns a network error), confirm the VPN session is connected and that `dig` returns a private IP for the Console hostname. Without an active VPN session, only the cluster *Overview* page is reachable from a workstation outside the client VPC.
+
+[NOTE]
+====
+Redpanda Console does not provide a standalone login form. Do not open `https://console-<id>.<cluster_domain>` directly in a browser: the SPA loads but cannot complete authentication, because the authentication token is handed off from Redpanda Cloud Console. Always start from https://cloud.redpanda.com[cloud.redpanda.com^].
+====
+
 == Test the connection
 
 You can test the connection to the endpoint service from any VM or container in the client VPC. If configuring a client isn't possible right away, you can do these checks using `rpk` or cURL:

modules/networking/partials/private-links-access-rp-services-through-vpc.adoc

@@ -1,13 +1,14 @@
-You can access Redpanda services such as Schema Registry and HTTP Proxy from the client VPC or virtual network; for example, from a compute instance in the VPC or network.
+You can access Redpanda services such as Redpanda Console, Schema Registry, and HTTP Proxy from the client VPC or virtual network; for example, from a compute instance in the VPC or network.
 
 The bootstrap server hostname is unique to each cluster. The service attachment exposes a set of bootstrap ports for access to Redpanda services. These ports load balance requests among brokers. Make sure you use the following ports for initiating a connection from a consumer:
 
-|=== 
-| Redpanda service | Default bootstrap port 
+|===
+| Redpanda service | Default port
 
-| Kafka API | 30292 
-| HTTP Proxy | 30282 
-| Schema Registry | 30081 
+| Kafka API | 30292
+| HTTP Proxy | 30282
+| Schema Registry | 30081
+| Redpanda Console | 443
 |===
 
 === Access Kafka API seed service
@@ -53,3 +54,45 @@ Use port `30282` to access the Redpanda HTTP Proxy seed service.
 ----
 curl -vv -u <user>:<password> -H "Content-Type: application/vnd.kafka.json.v2+json" --sslv2 --http2 <http-proxy-bootstrap-server-hostname>:30282/topics
 ----
+
+=== Verify the Redpanda Console network path
+
+When you configure private connectivity through the Cloud API, set `connect_console: true` on the network configuration to enable Console access through the cluster's private endpoint. The Cloud UI sets this for you when you enable private connectivity.
+
+The Redpanda Console URL is served on port `443` (HTTPS) and follows the form `https://console-<id>.<cluster_domain>`. The `<id>` is a per-cluster suffix assigned by the Redpanda control plane and is opaque to you; the full URL is shown in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console.
+
+To verify that the network path to Redpanda Console is open, run the following commands from a host in the client network. First, confirm DNS resolves the hostname to a private IP on the cluster's private endpoint:
+
+[,bash]
+----
+dig +short console-<id>.<cluster_domain>
+----
+
+The response is a private IP from your client network's address range, for example:
+
+[,bash,role=no-copy]
+----
+10.0.0.42
+----
+
+Then confirm Redpanda Console responds over HTTPS through the endpoint:
+
+[,bash]
+----
+curl -sS -o /dev/null -w "%{http_code}\n" https://console-<id>.<cluster_domain>/
+----
+
+Expected output:
+
+[,bash,role=no-copy]
+----
+200
+----
+
+A 200 response confirms the network path. The Console UI itself does not expose a standalone login form: sign in to https://cloud.redpanda.com[cloud.redpanda.com^], navigate to the cluster, and use the cluster's left navigation (*Topics*, *Brokers*, *Consumer groups*) to interact with Redpanda Console.
+
+[NOTE]
+====
+* DNS resolution for the Redpanda Console hostname is handled automatically by the cluster's private endpoint. You don't need to create a private hosted zone or override DNS in the client network.
+* Ensure your network access rules (for example, AWS security groups, Azure NSGs, or GCP firewall rules) on the private endpoint allow inbound TCP on port `443` from your client workload sources only (for example, the client network's CIDR or specific client access groups). Avoid broad source ranges such as `0.0.0.0/0`.
+====