## This patch release fixes 3 regressions in the 1.6.0 release * On Windows, the

host.rancher-desktop.internal

and

host.docker.internal

names did not resolve. * On macOS, the bridged interface was not being used, even when running with administrative rights, and only port forwarding to localhost was active. * On macOS and Linux, upgrades from a previous release did not update all files inside the VM. In particular,

nerdctl

would stay at the previous version (e.g.

0.22.2

in Rancher Desktop 1.5.1) instead of being upgraded to

0.23.0

.

Is the intent that host.rancher-desktop.internal be used for the k3s endpoint and other cluster endpoints? So I can add that to my no_proxy (or you may have already) to keep intra VM traffic inside and not trying to head out to internet egresses?

No,

host.rancher-desktop.internal

is just another alias to access the host from inside the VM. It has the same value as

host.docker.internal

. But yes, it should be in

no_proxy

as well.

yeah just didn’t know if those IP flows in the k3s network would start using that namespace vs the IP directs. on macOS it’s not been an issue, but WSL i track flows egressing the distro to the proxy since I can’t limit WSL2 down to a specific IP space without other bits on top of the generic stack

I am still unable to ping

host.docker.internal

to resolve my host machine. I am on Windows 11 and Rancher-Desktop version

1.6.2

with

dockerd

and Kubernetes version

v1.24.4

😞 Do I need any additional configuration for that to work? I assumed that accessing my host via that address works out-of-the-box

@loud-megabyte-65691 Is the problem that the name doesn't resolve, or that the address isn't routable? The former should be fixed in 1.6.1+. The latter would be a different issue. I don't know if

ping

actually works, but can you connect via

curl

? Are you using proxy settings? Could this be a VPN issue?

Hm with

curl

to

host.docker.internal

I get the blue IIS page HTML back so that resolves and works, but when I try to connect to something running on a specific port, for instance my local Seq logging server which runs on port 5341,

curl

to

host.docker.internal:5341

does nothing. Same result for applications running on other ports. I don't use any proxy settings. Being on my company's VPN doesnt seem to make a difference.

@calm-sugar-3169 Could this be a firewall issue?

I will take a look shortly, in a meeting currently

Yea it just hangs. Pinging something on the internet like google.com works just fine.

can you run

New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

and try pinging again?

Works like a charm! Both

ping

to

host.docker.internal

and

curl

to

host.docker.internal:5341

are working.

I believe we have this document and it’s currently up to users discretion to run or not. @fast-garage-66093 do you we want to run this rule as part of Privileged Service?

I want to have a Preferences setting to make it automatically (but not by default), and I want a diagnostic to inform you when the firewall is currently blocking the connection. I'll create a Github issue for it.

👌