Problem connecting to WSL docker host

Technical Support
,
1

My VS Code Torizon debug system was previously working OK, but I’m now having problems pulling the docker image down to the Torizon target system.

Here’s my setup;
Windows host running Docker Desktop (4.34.1)
WSL (Ubuntu 22.04)
VS Code - latest (3.1.1)

I’ve got a small local network:
Windows Host: 192.168.8.227
Torizon target: 192.168.8.226

I can ping each device from the other. On the Windows host, “curl http://localhost:5002/v2/” gives me a good HTML response.

From the Torizon target, I’m able to “telnet 192.168.8.227:5002” without any problem, so I know that port 5002 is able to get through the Windows firewall.

On the Torizon target, “curl http://192.168.8.227:5002/v2/” gives me “Recv failure: Connection reset by peer”, so I’m unable to pull the image down to the target.

The Torizon target’s daemon.json file has “insecure-registries” : [“192.168.8.227:5002”], so that should be OK.

The issue seems to be that the docker daemon in the container running on Windows is not being exposed to the clients of the Windows device, even though the firewall is open.

Is there something I’m missing with the docker/container config?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for your detailed description of the setup and the troubleshooting steps you’ve taken so far.

Given your observations, it looks like the network connection between your Torizon target and the Windows host running Docker Desktop is established (as shown by successful telnet), but Docker’s local registry is not responding as expected when you attempt to pull images.

Here are the key things to check and steps you might be missing in your Docker/VS Code Torizon workflow:

1. Docker Desktop Registry Network Exposure

Docker Desktop on Windows (especially when using WSL2) runs containers and registries inside a special network space that isn’t always automatically exposed to your local network. By default, the registry may only be accessible via localhost on Windows, not from other hosts (like your Torizon target).

2. Utilizing the share-wsl-ports.xsh Script

The Torizon VS Code extension includes automation to expose WSL ports to the host using the share-wsl-ports.xsh script. This script opens the necessary firewall rules and relays traffic from your Windows IP to the internal WSL network. It should be triggered automatically when the extension activates in a WSL2 environment, but sometimes it may fail, especially if there was a system/environmental change.

Please reference:

Steps to Try

A. Manually ensure Port Exposure

  1. Restart the VS Code Torizon Extension inside WSL2.

    • Sometimes reloading or restarting VS Code with the Torizon workspace in your WSL2 shell will rerun the port sharing script and set up port forwarding properly.

  2. Check the status of the share-wsl-ports script:

    • Locate the script (typically inside your workspace at .vscode/share-wsl-ports.xsh) and run it manually in your WSL2 terminal:
      .vscode/share-wsl-ports.xsh
    • Watch for errors or warning messages.

  3. Check that the Docker registry is listening on the right interfaces:

    • From Windows, run:
      netstat -an | find "5002"
    • The output should show 0.0.0.0:5002 or your Windows LAN IP, not just 127.0.0.1:5002.

B. Review Windows Firewall and NAT Rules

  • Make sure the Windows firewall hasn’t changed rules that block forwarding to WSL.
  • Check for any third-party firewalls or proxies that could block the connection.

C. Restart Key Components

  • Restart Docker Desktop.
  • Restart VS Code with your Torizon workspace.
  • Restart your WSL2 Ubuntu instance:
    wsl --shutdown
    Then, reopen your terminal.

D. Try Accessing Registry Within WSL

  • From WSL2 Ubuntu shell, check if the registry is reachable:
    curl http://localhost:5002/v2/
    This should work and help confirm the registry server is up and the issue is with Windows-to-WSL bridging.

If all the above checks are OK, but you still see “Connection reset by peer” from the Torizon target, it’s almost always an issue with the Windows/WSL2 port relay—not with Docker or the daemon.json on the target.

For deeper info, you may also visit:

Let me know if these steps help, or if you need more detailed diagnostics!

Best regards,
Toradex AI Assistant.

3

Can you give me some more specific information about the location of the share-wsl-ports.xsh script? Is it on the Windows host, WSL, the target? What’s the path?

4

After running share-wsl-ports, and running netsgrtat -an, I can see that my docker registry is not listening on 127.0.0.1:5002 - only 0.0.0.0:5002.

TCP 0.0.0.0:5002 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5002 0.0.0.0:0 LISTENING
TCP [::]:5002 [::]:0 LISTENING
TCP [::1]:5002 [::]:0 LISTENING
UDP 0.0.0.0:5002 :

5

@jonmills

Please first check the local WSL firewall rules, some systems are applying more strict rules:

sudo iptables -L -v -n

Please share the output with us, run in a new WSL terminal.

7

Thanks @matheus.tx .

Here’s the output;

sudo iptables -L -v -n
[sudo] password for jonmills:
Chain INPUT (policy ACCEPT 219 packets, 276K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER-USER all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-FORWARD all – * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 186 packets, 56688 bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5000
0 0 DROP all – !docker0 docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-CT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-CT all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-ISOLATION-STAGE-1 all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-BRIDGE all – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION-STAGE-2 all – docker0 !docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

8

Please try to run the following in a WSL terminal:

sudo iptables -I FORWARD -i docker0 -j ACCEPT && sudo iptables -I FORWARD -o docker0 -j ACCEPT

After that, please share with us again the output of the sudo iptables -L -v -n.
Also, try to deploy the debug sessions again to see if something changes.

BR,

9

Thanks Matheus.

Here’s the updated output. Unfortunately it didn’t fix the problem.

Also, on my Windows host, the following command is still successful:
curl http://localhost:5002/v2/

and the following command still fails:
curl http://127.0.0.1:5002/v2/

so it seems to be a problem mapping the ports into the docker registry in WSL.

sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 1 packets, 76 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-USER all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-FORWARD all – * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1 packets, 76 bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5000
0 0 DROP all – !docker0 docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-CT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-CT all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-ISOLATION-STAGE-1 all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-BRIDGE all – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION-STAGE-2 all – docker0 !docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

10

@jonmills thanks, now please run:

sudo iptables -I DOCKER 1 -i !docker0 -o docker0 -j ACCEPT

Again, please share the output of the sudo iptables -L -v -n after the command and try to deploy the debug session.

BR,

11

I assume that the ! before the first docker0 was a typo?

sudo iptables -I DOCKER 1 -i docker0 -o docker0 -j ACCEPT

sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 1 packets, 80 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-USER all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-FORWARD all – * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 4 packets, 208 bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – docker0 docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp – !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5000
0 0 DROP all – !docker0 docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-CT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-CT all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-ISOLATION-STAGE-1 all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-BRIDGE all – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION-STAGE-2 all – docker0 !docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

12

@matheus.tx what’s the preferred development environment (what are most devs using)? This Windows/WSL combination always seems to cause some pain. Would I be better moving to a Linux environment, or is it possible to debug via an external Docker registry (which doesn’t use WSL)?

13

So, I’m assuming that the second command also did not solve the issue, am I right? Although your iptables output seems correct now :thinking:.

what’s the preferred development environment (what are most devs using)? This Windows/WSL combination always seems to cause some pain.

Yeah, it’s weird how some Windows WSL 2 network environments behave, it does not seem to be in a pattern, it depends on company policies, Windows version 11 home/professional, etc. If possible better use a Debian/Ubuntu latest LTS Linux, so you will not have to deal with this Windows/WSL Linux stuff.

14

Thanks Matheus,

Yes, unfortunately, I’m still unable to curl from the API using any other address than localhost, so I’m assuming the problem is on the Windows side, rather than anything to do with the WSL firewall.

Maybe I’ll take some time to set up a Linux dev machine. This WSL Docker registry stuff seems pretty hard to get right. I’d still like to get my Windows setup working in the short term, if you’ve got any other things I can check?