Error binding local socket for ssh port forward; seems IPv6 related

[kuza55]

• A brief description
  I get some really weird results when trying to forward ports with ssh.

When I try to run:
ssh -L 3390:localhost:3389 user@host

I get an error saying:
bind: Address already in use

However, if I do
ssh -L 127.0.0.1:3390:localhost:3389 user@host

Everything works fine, it binds the port correctly and I can forward a port.

• Your Windows build number

Version 10.0.14390 Build 14390

• Strace of the failing command

This is the strace of the failing command:

socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(4, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(4, {sa_family=AF_INET6, sin6_port=htons(3390), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
listen(4, 128) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(3390), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

This is an strace of the successful command:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(4, {sa_family=AF_INET, sin_port=htons(3390), sin_addr=inet_addr("127.0.0.1")}, 16) = 0

Notably there is no attempt to bind on ipv6

[sunilmut]

@kuza55 - Thanks for reporting this and trying out WSL! Unfortunately, IPV6_V6ONLY is currently not fully supported in WSL (even though the setsockopt passes). Also see #157. We are very well aware of this limitation and are looking into supporting the IPV6_V6ONLY option fully. Meanwhile, you may be able to workaround the issue by using the IPv4 address only.

[kuza55]

I have no real desire to use IPv6 here, the real problem is that due to the previous IPv6 calls, the IPv4 bind fails.

[sunilmut]

Correct, and understood. As indicated earlier, we are looking into resolving the IPV6_V6ONLY problem. Please keep the feedback coming.

[sunilmut]

With the help of the Windows networking team, we were able to fully implement the IPV6_V6ONLY flag. That should resolve the issue here. The fix is still in our dev branch, but should soon hit the release branch.

[kuza55]

You guys are killing it, keep up the good work! :D

[PetaPetaPeta]

Another thing that can solve this is using the '-4' flag to enforce the use of IPv4.

[sunilmut]

Just FYI that the IPV6_V6ONLY issue is fixed in 14936 (see release notes)

[sunilmut]

Closing this out since this should be now resolved in builds 14942+. If it is still broke, please let us know.