Unable to access to local network within windows WSL distros when rancher desktop 1.15.0

[yevon]

Actual Behavior

Recently I lost access to local network within WSL windows distributions but only when I start rancher desktop 1.15.0. I read some issues about it, and options like enabling tunneling or host resolver. Does it apply anymore? As they are now default features?

I'm receiving this Diagnostics message that I don't know if I must do something about it, but I completely uninstalled my .kube folder, uninstalled rancher desktop completely, reinstalled it and there is still this message there:

Maybe this might be related? Thanks!

Steps to Reproduce

Install rancher desktop 1.15.0 and try to ping any local network server, it says Host Unreachable but only when rancher desktop is enabled.

Result

Unable to access to local network.

Expected Behavior

I should be able to access to local network resources within WSL distros.

Additional Information

No response

Rancher Desktop Version

1.15.0

Rancher Desktop K8s Version

1.29.3

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 23H2

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

Standard windows defender, no security softwares. Already tried to disable windows firewall without success.

[Nino-K]

Hi @yevon,

We added that diagnostic in our latest release (1.15.0). The diagnostic message you're seeing is from the WSL integration when you attempt to enable Kubernetes in another WSL distribution. Generally, when you enable WSL integration and Kubernetes is active, Rancher Desktop tries to create a symlink from your kube config on the host to your WSL distribution (~/.kube/config). However, if Rancher Desktop encounters a kube config on the host with configurations other than Rancher Desktop-specific ones, it will not create the symlink and will display this diagnostic message. Essentially, this indicates that you need to manually create the symlink from C:\Users\username\.kube\config on the Windows host to ~/.kube/config in the WSL distribution.

@jandubois, should we consider including a link to the documentation in the diagnostic message to guide users on how to manually create this symlink?

[yevon]

Nice, I created the symlink with this command inside my Ubuntu wsl distribution and the diagnostics message dissappeared. sudo ln -sf /mnt/c/Users/<windows_username>/.kube/config /home/<ubuntu_username>/.kube/config. But it didn't make any difference, I keep getting destination host unreachable for my local network hosts. I will try to downgrade rancher to test if it solves the problem.

[yevon]

Seems to be solved by downgrading to 1.13.1 and disabling the windows tunneling. Is there a way to be able to keep the old behaviour but with latest versions? Should I be able to contact to local network hosts inside wsl distros with the new windows tunneling stack?

[elemental1313]

It seems that this used to be an automatic thing, and now just does not work. I LOVE the memory leak fix in 1.15.0 and i want to use this version of rancher desktop, but it wont be possible for me as i no longer have the network tab available as stated here in this issue and i require the network tunneling to be disabled. Though i do not see the diagnostic error, i instead see "Expose Rancher Desktop's Kubernetes configuration and Docker socket to Windows Subsystem for Linux (WSL) distros". So i thought i needed to do the symbolic link fix but that also failed (and its hard for me to know where to link that file since it didnt exist and i have no /home folder in my distro, so i assumed the default location (~/.kube/config) and copied it there with no luck). Not sure what else changed from 1.14.1 to 1.15.0 to remove the network tab that I needed :(

[Nino-K]

@yevon can I ask what operation you are attempting to do that prevents you from accessing the local network? I just need to understand what you are trying todo and how I can replicate the same thing. Thanks

[yevon]

I'm just trying to contact my docker registry inside my local network server, I cannot ping to anything outside the WSL host machine. I just do a ping 192.168.1.X inside ubuntu WSL when rancher desktop is shutdown, and it works, but when I just turn it on, it immediately stops working in latest versions that have the new windows tunneling feature.

[yevon]

I have a local network dns server, I don't know if this affects.

[alister]

I've also got similar issues with v1.15.0 - though I'm not using K8S at all. At 192.168.1.100 is a database, available via a VPN on the Win11 Pro host (to be used from containers in WSL2 / Ubuntu 24.04).

With Rancher 1.15.0 pinging the IP address from a wsl2 command line gets "Destination Host Unreachable" or "no route to host" for an attempted DB connection. The database can be pinged from PowerShell, and connected to/browsed from Windows without issue.

Without RancherDesktop 1.15.0 running, the ping is OK from a WSL2 command line.

I've downgraded RancherDesktop to v1.13.1 & disabled the networking tunnel in Prefs/WSL/Network and can ping and connect to the DB successfully from Windows, WSL2 & the containers.

[frequency-fruit]

I can confirm upgrading to 1.15.0 broke some network connections.

Here's 2 ping commands from Windows and 2 from a docker container. Connections to 192.268.0.* still work, but connections to 192.168.1.* don't work, even though they are both on the same network/subnet

PS> ipconfig

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::8d55:8643:be96:b81%9
   IPv4 Address. . . . . . . . . . . : 192.168.0.89
   Subnet Mask . . . . . . . . . . . : 255.255.254.0
   Default Gateway . . . . . . . . . : 192.168.0.1

Ethernet adapter vEthernet (WSL (Hyper-V firewall)):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::339b:6a93:5bff:fe10%46
   IPv4 Address. . . . . . . . . . . : 172.25.128.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

PS> ping 192.168.0.100 -n 1

Pinging 192.168.0.100 with 32 bytes of data:
Reply from 192.168.0.100: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.100:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
PS> ping 192.168.1.160 -n 1

Pinging 192.168.1.160 with 32 bytes of data:
Reply from 192.168.1.160: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.160:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

PS> docker run --rm -it rancher/rke-tools:v0.1.100 ping 192.168.0.100 -c 1
PING 192.168.0.100 (192.168.0.100): 56 data bytes
64 bytes from 192.168.0.100: seq=0 ttl=63 time=0.330 ms

--- 192.168.0.100 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.330/0.330/0.330 ms

PS> docker run --rm -it rancher/rke-tools:v0.1.100 ping 192.168.1.160 -c 1
PING 192.168.1.160 (192.168.1.160): 56 data bytes

--- 192.168.1.160 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

Here's my settings:

PS> rdctl list-settings
{
  "version": 13,
  "application": {
    "adminAccess": false,
    "debug": false,
    "extensions": {
      "allowed": {
        "enabled": false,
        "list": []
      },
      "installed": {}
    },
    "pathManagementStrategy": "manual",
    "telemetry": {
      "enabled": true
    },
    "updater": {
      "enabled": true
    },
    "autoStart": false,
    "startInBackground": false,
    "hideNotificationIcon": false,
    "window": {
      "quitOnClose": false
    }
  },
  "containerEngine": {
    "allowedImages": {
      "enabled": false,
      "patterns": []
    },
    "name": "moby"
  },
  "virtualMachine": {
    "memoryInGB": 2,
    "numberCPUs": 2,
    "hostResolver": true
  },
  "WSL": {
    "integrations": {}
  },
  "kubernetes": {
    "version": "1.28.12",
    "port": 6443,
    "enabled": true,
    "options": {
      "traefik": true,
      "flannel": true
    },
    "ingress": {
      "localhostOnly": false
    }
  },
  "portForwarding": {
    "includeKubernetesServices": false
  },
  "images": {
    "showAll": true,
    "namespace": "k8s.io"
  },
  "containers": {
    "showAll": true,
    "namespace": "default"
  },
  "diagnostics": {
    "showMuted": false,
    "mutedChecks": {}
  },
  "experimental": {
    "virtualMachine": {
      "type": "qemu",
      "useRosetta": false,
      "mount": {
        "type": "reverse-sshfs",
        "9p": {
          "securityModel": "none",
          "protocolVersion": "9p2000.L",
          "msizeInKib": 128,
          "cacheMode": "mmap"
        }
      },
      "networkingTunnel": true,
      "proxy": {
        "enabled": false,
        "address": "",
        "password": "",
        "port": 3128,
        "username": "",
        "noproxy": [
          "0.0.0.0/8",
          "10.0.0.0/8",
          "127.0.0.0/8",
          "169.254.0.0/16",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "224.0.0.0/4",
          "240.0.0.0/4"
        ]
      }
    },
    "containerEngine": {
      "webAssembly": {
        "enabled": false
      }
    },
    "kubernetes": {
      "options": {
        "spinkube": false
      }
    }
  }
}

[Nino-K]

@yevon It sounds like there might be an IP address conflict in your case. We use 192.168.1.1 as a static IP address for the virtual Ethernet pair that connects the external namespace to Rancher Desktop's network namespace. Therefore, no other devices should be using that IP address. Currently, it is a static assignment, but we plan to make it configurable in the future.

[yevon]

That explains a lot, in many european countries the standard router ip is 192.168.1.1 and private networks in same range. So 192.168.1.1 will make conflicts in many cases as it is the main gateway.

[Nino-K]

Hi @yevon we addressed the issue in an our upcoming release which should be out shortly. Please, try it out and see if you encounter anything else. I'm going to close this issue for now, feel free to reopen if needed.

[yevon]

Perfect thanks!!

[yevon]

Confirmed everything working fine on 1.16.0!