Networking Tunnel does not work with people in conflicting LAN

[Schaka]

Actual Behavior

Currently, we have a setup where testcontainers starts several images that then connect to an application running on the host system. The code itself finds the local machine's LAN IP and then passes it into the containers so they know where to find and access the servers.

Amongst other things, this is done so we can use Playwright to use connect to Chromium in a container and then use that Chromium instance to communicate with the application running on the host.

What I'm seeing is that as long as I'm on a LAN with IP 192.168.1.207, the containers cannot access my host under that IP.
If I hotspot myself from my phone and use another interface with an IP like 192.168.68.176, the connections can be made. My colleagues on 192.168.0.52, 192.168.178.59, etc also don't have that problem.

To me, this seems to be an IP conflict that could be avoidable if this was a setting that would allow me to change which IP/subnet is used for the veth-rd0 bridge.

The network docs state that

The process also establishes a Virtual Ethernet pair consisting of two endpoints: veth-rd0 and veth-rd1. veth-rd0 resides within the default namespace and is configured to listen on the IP address 192.168.1.1. Conversely, veth-rd1 is located within a network namespace and is assigned the IP address 192.168.1.2.

Could this be a setting? Can this currently be changed at all to circumvent this bug? I would think I'm not the only user with this subnet.

I also tried using the IP assigned to Ethernet adapter vEthernet (WSL (Hyper-V firewall)), but as it's a hidden network adapter in Windows, it seems that most server software won't bind to it, even when binding on 0.0.0.0.

Steps to Reproduce

1. Turn your LAN into 192.168.1.0/24 subnet or set your local IP to 192.168.1.50 statically
2. Start an image that needs a network connection, like chrome-headless
3. Try to communicate from within that image to 192.168.1.50
4. See ERR_ADD_UNREACHABLE or similar error for whatever connection you tried to open
5. Change your IP to a different subnet, say 192.168.2.50
6. Watch it working again

Result

Connection cannot be establied. I also cannot ping the host under the given IPs unless I manually go inside the rancher-desktop VM in WSL and ip route del 192.168.1.0/24.

Expected Behavior

I would expect a connection to be established.

Additional Information

No response

Rancher Desktop Version

1.14.1

Rancher Desktop K8s Version

1.29.6

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Win 11

What CPU architecture are you using?

x64

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

None

Windows User Only

No response

[Nino-K]

This is something that we are planning to support in our upcoming releases.

[NikPiermafrost]

Following since i resintalled it on 1.15.1 and can't get to my local network cluster anymore

[Nino-K]

This issue was addressed in our upcoming release, version 1.16. Please try the release once it becomes available and let me know your feedback. For now, I will close this issue; however, feel free to reopen it if necessary.