Hey wranglers 🤠 Not sure if this question fits better in another channel but i'll start here as i've been struggling with something that seems simple enough. I'm spinning up a test-RKE2 cluster using CAPD instructions here https://caprke2.docs.rancher.com/01_user/01_getting-started.html I got the cluster up with 3 masters and 2 workers/agents

clusterctl describe cluster capd-rke2-test -n example

NAME                                                            READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/capd-rke2-test                                          True                     36m
├─ClusterInfrastructure - DockerCluster/capd-rke2-test          True                     51m
├─ControlPlane - RKE2ControlPlane/capd-rke2-test-control-plane  True                     36m
│ └─3 Machines...                                               True                     48m    See capd-rke2-test-control-plane-8r9w4, capd-rke2-test-control-plane-qd9wv, ...
└─Workers
  └─MachineDeployment/worker-md-0                               True                     34m
    └─2 Machines...                                             True                     46m    See worker-md-0-tnvnq-f7ksj, worker-md-0-tnvnq-x2r2c

However after pulling the workload cluster kubeconfig with

clusterctl get kubeconfig capd-rke2-test -n example > capd-rke2-test.kubeconfig

i can't connect to the API, all i get is a timeout.

"Unhandled Error" err="couldn't get current server API group list: Get \"<https://10.123.45.3:6443/api?timeout=32s>\": dial tcp 10.123.45.3:6443: i/o timeout"

I've been testing different subnets incase the network created by KIND conflicts with another on the corporate LAN i'm connected to but no matter which network i choose, even if completely disconnected from any network i get a timeout. Any ideas?

Can you confirm that

10.123.45.3:6443

is actually reachable from a client node (log into the client node and run a curl -kv https://10.123.45.3:6443 )? Also check if the control plane node is healthy and listening on port 6443. (log into the control plane node and run a ss -tuln | grep 6443)?