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 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
Turn your LAN into 192.168.1.0/24 subnet or set your local IP to 192.168.1.50 statically
Start an image that needs a network connection, like chrome-headless
Try to communicate from within that image to 192.168.1.50
See ERR_ADD_UNREACHABLE or similar error for whatever connection you tried to open
Change your IP to a different subnet, say 192.168.2.50
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?
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
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 on0.0.0.0
.Steps to Reproduce
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