Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker port binding not working as per documentation (iisdemo) #181

Closed
mathiasconradt opened this issue Mar 27, 2016 · 44 comments
Closed

Docker port binding not working as per documentation (iisdemo) #181

mathiasconradt opened this issue Mar 27, 2016 · 44 comments

Comments

@mathiasconradt
Copy link

@mathiasconradt mathiasconradt commented Mar 27, 2016

The iisdemo / port binding described on https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_docker#create-iis-image-1- does not work in the way described there.

It's either not clear what the host is (from my understanding, it should be the actual Windows 2016 server that I run docker on, so it should be "localhost" relative from there) or the port binding isn't working.

docker run --name iisdemo -it -p 8800:80 windowsservercoreiis cmd

does not bind the port 8800 on the host. I should be able to open "localhost:8800" or "172.16.0.1:8800" on the host (172.16.0.1 being the IP of the host, while 172.16.0.2 being the IP of the container).

Neither works a:

docker run --name iisdemo -it -p 80:80 windowsservercoreiis cmd

(Firewall rules are added, but also Windows Firewall entirely disabled just to be sure).

What's also interesting is that when I block port 80 on the host with some other service, and then start the docker container with port binding 80:80, I don't get any conflict, which I would expect though.

I can reach the IIS via the container IP, but I cannot reach it via host IP and bound port.

Original, fully detailed problem description here:
http://superuser.com/questions/1057223/windows-container-port-binding-on-windows-server-2016-not-working

Update:

In a second attempt, I used powershell instead of Docker to manage the container. I followed the documentation step by step on https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_powershell#create-iis-container-1-, but also with no luck. I cannot reach the IIS via the host IP and bound port, only via the container IP.

@mathiasconradt
Copy link
Author

@mathiasconradt mathiasconradt commented Mar 28, 2016

Stefan Scherer from the Docker team was able to reproduce the issue on Windows Server 2016 TP4.
moby/moby#21558 (comment)
Seems to be a regression in TP4 and will hopefully be gone in TP5.

@StefanScherer
Copy link
Contributor

@StefanScherer StefanScherer commented Mar 31, 2016

@mathiasconradt Thank you for the compliment, but I'm not from the Docker team 😆

neilpeterson pushed a commit that referenced this issue May 2, 2016
Issues with New-ContainerHost and Nano
@sitano
Copy link

@sitano sitano commented Jul 21, 2016

I verify @StefanScherer 's latest https://github.com/StefanScherer/docker-windows-box Windows 2016 TP5 still have this issue (VirtualBox + fresh box install). docker run -it -p 8080:80 microsoft/iis:windowsservercore cmd bind is accessable only from external to the host machine request, but requesting external ip interface from inside of the host machine self, does not work.

@PatrickLang
Copy link
Contributor

@PatrickLang PatrickLang commented Jul 21, 2016

I checked with the devs and they're aware of the issue. It will be fixed before Windows Server 2016 is shipped, but unfortunately I don't have a workaround for TP5.

@sitano
Copy link

@sitano sitano commented Jul 22, 2016

Thanks for an update!

@WolfspiritM
Copy link

@WolfspiritM WolfspiritM commented Sep 30, 2016

Can this be the reason localhost port binding doesn't work on Windows 10, too?
I can access the containers via IP but they don't expose their port to localhost.

What does work however is:
Getting the IP of the container via "docker inspect" and then doing:
start /B C:\Program Files\docker>docker-proxy.exe -container-ip 172.23.57.95 -container-port 80 -host-port 8123
After that it works even so docker-proxy "keeps running" so you need to kill it seperatly, but I assume docker-proxy is an "old way" to do it and it's going to be included in Hyper-V directly?

@pbering
Copy link

@pbering pbering commented Sep 30, 2016

Is there any news on this? I have the same issue on Windows 10 with latest Docker 1.13 beta...

@friism
Copy link
Contributor

@friism friism commented Sep 30, 2016

Pinging @JMesser81

@JMesser81
Copy link
Contributor

@JMesser81 JMesser81 commented Oct 1, 2016

It is well documented that container endpoints attached to a Windows NAT network cannot be accessed using the external (host) IP and port. Instead, if you're trying to access a container endpoint from the container host itself, you must use the internal (NAT) IP and port. This limitation is being fixed in the next release of Windows.

@rs38
Copy link
Contributor

@rs38 rs38 commented Oct 1, 2016

@JMesser81 what next release? Server? Win10?

@pbering
Copy link

@pbering pbering commented Oct 3, 2016

@JMesser81 you write "cannot be accessed using external IP and port" but I can't use "localhost" or 127.0.0.1 to access local containers, is that the same issue?

@JohnPAguirre
Copy link

@JohnPAguirre JohnPAguirre commented Oct 6, 2016

Looking for more documentation Windows 10 container endpoints attached to the host issue on what is normal and/if there is a game plan on what is going to be fixed. Just started with docker engine for windows but this is honestly a surprise and this thread is what comes up on google about this issue.

@JMesser81
Copy link
Contributor

@JMesser81 JMesser81 commented Oct 6, 2016

@pbering - not sure I understand. Are you trying to access a container endpoint from the host using 127.0.0.1 or loopback? Or, are you trying to access the host from a container using 127.0.0.1 or loopback?

@JMesser81
Copy link
Contributor

@JMesser81 JMesser81 commented Oct 6, 2016

@JohnPAguirre - Here's a blog article I wrote about WinNAT capabilities and limitations. Most of the limitations I mention will be fixed in the next release.

@rs38 - Server and client are now merged so they're essentially one and the same release. Hoping to see some improvements in Windows Insider Preview (WIP) builds and possibly Windows Server previews (TBD) sometime in the new year.

@pbering
Copy link

@pbering pbering commented Oct 7, 2016

@JMesser81 I'm trying to access a container endpoint from the host with localhost:8000.

@pbering
Copy link

@pbering pbering commented Oct 7, 2016

@JMesser81 could you also throw the link to the blog post about "WinNAT capabilities and limitations. " that you mentioned?

@JMesser81
Copy link
Contributor

@JMesser81 JMesser81 commented Oct 10, 2016

https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/

Accessing a container endpoint from the host using localhost is not supported. You must use the internal IP address/port of the container endpoint.

@kendrahavens
Copy link
Contributor

@kendrahavens kendrahavens commented Jan 14, 2017

Related issue requesting a timeline for this fix: microsoft/aspnet-docker#13

@vzwick
Copy link

@vzwick vzwick commented Oct 24, 2017

@JMesser81

Hey Jason,

any update on this one?

@JanneRantala
Copy link

@JanneRantala JanneRantala commented Oct 24, 2017

I would also like to know some ETA for this. It's been over a year now and this is still not done. In developer's point of view this is one of the most critical things but it seems that all the "sexier" stuff gets done.

@JMesser81
Copy link
Contributor

@JMesser81 JMesser81 commented Oct 24, 2017

@kallie-b - who can provide an update. Soon :-)

@JanneRantala
Copy link

@JanneRantala JanneRantala commented Oct 24, 2017

@JMesser81 @kallie-b can you at least reveal if it will be for Windows Insiders first or for all? Insiders means it will be again months after users restricted by corporate policies are able to use it.

@kallie-b
Copy link
Contributor

@kallie-b kallie-b commented Oct 24, 2017

@JanneRantala -- Localhost/loopback support is part of the work we're doing for our next Windows release. We just completed a release, and currently Windows is on a semi-annual release cadence. That puts the next full Windows release in the Spring.

But, as you mentioned, before then you'll have access to our newest features via the Windows Insiders program. I'll reply back to this thread when localhost/loopback support for containers is available to Windows Insiders, which should be very soon :)

Of course, as is mentioned above, while you're waiting for localhost/loopback support, you can access your containers via published port on their host using either:

  • The container's private IP and published port
  • The host's public IP and published port for the container

@hugo6
Copy link

@hugo6 hugo6 commented Nov 24, 2017

Hi @kallie-b any news on windows Localhost/loopback support ?

@StefanScherer
Copy link
Contributor

@StefanScherer StefanScherer commented Nov 24, 2017

It‘s available in Windows Insider 17035 or above. So it should be part of 1803 / RS4 release.

@MikeChristensen
Copy link

@MikeChristensen MikeChristensen commented May 23, 2018

@StefanScherer I'm running Windows 10 Build 1803, but still have the same problem. Can you confirm if this fix made it into 1803, or do I still need to use Windows Insider builds?

@rs38
Copy link
Contributor

@rs38 rs38 commented May 23, 2018

I tested the fix sucessfully two weeks ago with 1803. Visual Studio "deploy to docker" still does the "old" way with grabbing the "172.x.x.x." from the container config.

@MikeChristensen
Copy link

@MikeChristensen MikeChristensen commented May 23, 2018

Strange. I'm running the container like so:

docker run -d -v "C:\Product\src\API:C:\inetpub\wwwroot" `
-p 567:80 `
--dns-search=kitchenpc.com `
kitchenpc/api:dev

I can reach the site on the IP of the container on port 80, but I cannot reach the site on localhost:567 or 127.0.0.1:567. I'm using pure Docker commands and not Visual Studio for anything. I'm on Windows 10 Build 1803, and am NOT on Windows Insider.

@StefanScherer
Copy link
Contributor

@StefanScherer StefanScherer commented May 23, 2018

@MikeChristensen the container image must also be newer than the ltsc image.
The kitchenpc/api:dev should use the 1803 base image.

I've checked in Windows 10 1803, Docker for Windows Stable 18.03.1-ce-win65 and this example image:

PS C:\> docker run -d -p 8081:8080 stefanscherer/whoami
68b8152cf423e6a5987d48220e2b9b03c1d43b6442c46f094d01b433f16a4fbd
PS C:\> curl.exe http://localhost:8081
I'm 68b8152cf423 running on windows/amd64

@kallie-b kallie-b removed their assignment May 23, 2018
@kallie-b
Copy link
Contributor

@kallie-b kallie-b commented May 23, 2018

@daschott :)

@MikeChristensen
Copy link

@MikeChristensen MikeChristensen commented May 23, 2018

Ah, so this is only supported on Windows 10 images. I was using microsoft/aspnet:4.7.1-windowsservercore-1709 (Though I also tried microsoft/aspnet:4.7.1-windowsservercore-ltsc2016)

λ curl.exe --head http://172.28.21.107/home/
HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 149
Content-Type: text/html; charset=utf-8
Location: /Login.aspx?ReturnUrl=%2fhome%2f
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
WSN: E2B9870CF10D
X-Frame-Options: SAMEORIGIN
X-Powered-By: ASP.NET
Date: Wed, 23 May 2018 14:56:12 GMT

λ curl.exe --head http://localhost:8080/home/
curl: (7) Failed to connect to localhost port 8080: Timed out

Any idea when the Windows Server Core images will support this? Thanks!

@rs38
Copy link
Contributor

@rs38 rs38 commented May 25, 2018

there are no "Windows 10 images"...

docker images can base on the latest semi annual "kernel" which can be servercore or nano.

try:
microsoft/aspnet:4.7.1-windowsservercore-1803 in your case.

By the way I do not really understand why the regarding virtual NIC / Switch and NAT Problem resulting in not binding to localhost needs Container Host and Base Image 1803 when working in Hyper-V abstraction like mandatory for Win10.

@daschott
Copy link
Contributor

@daschott daschott commented May 25, 2018

@rs38 @MikeChristensen @StefanScherer I confirm that localhost/loopback support on Windows 10 April 2018 and Windows Server 1803 is a known issue that is actively being fixed.

Even though the functionality may work for some people, it will not work for everyone. Using a new container image is also not going to fix it unfortunately!

I will post back here once a fix is out :)

@daschott
Copy link
Contributor

@daschott daschott commented May 30, 2018

As a (perhaps not very ideal) workaround in the meantime:
If you have at least one network adapter which is connected (and does not have a 169.254.x.y IP address) localhost should work. Disabling any adapters which have a 169.254.x.y IP address assigned should make this work again.

Otherwise, you should be also able to access the exposed service using http://hostname:hostport

@MikeChristensen
Copy link

@MikeChristensen MikeChristensen commented May 30, 2018

Odd. I don't have any 169.x.x.x addresses, yet localhost doesn't work (on Windows 10 host and aspnet:4.7.1-windowsservercore-1709 image). My IPs on the host are:

IPv4 Address. . . . . . . . . . . : 172.29.158.177(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.12.209(Preferred)
IPv4 Address. . . . . . . . . . . : 172.28.16.1(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.32.1(Preferred)

@lahma
Copy link

@lahma lahma commented May 31, 2018

I'm seeing same kind of problems with following setup on Windows Server build 17650 running on bare metal:

IPv4 Address. . . . . . . . . . . : 192.168.2.188
IPv4 Address. . . . . . . . . . . : 172.22.192.1

I cannot reach port from localhost, container IP nor the 192.168 address from host. I can reach the port from another computer on network (goes to 192.168 IP).

@rs38
Copy link
Contributor

@rs38 rs38 commented May 31, 2018

I am still a bit confused because I thought I already had that running and tested an app bound at locahost.

Currently I can reach the container (either 1709 or 1803 nano based, they behave the same) locally on my static IP, which is okay:

docker run -d -p 8001:80 rs38/hellonano1803
wget http://surfacebook:8001

Win10 1803
IPv4/v6 does not relate to that?

@carlfischer1
Copy link
Contributor

@carlfischer1 carlfischer1 commented Jun 2, 2018

@lahma moby/moby#36990

@daschott
Copy link
Contributor

@daschott daschott commented Jun 27, 2018

@MikeChristensen @rs38 @StefanScherer
Thank you for your patience. We fixed the localhost access issue with Windows Insider build 17692 and above that certain users were affected by. So for example let's say you spin up a microsoft/iis container and publish on port 8080 on your host using the command:
docker run -p 8080:80 microsoft/iis

From Windows Insider build 17692 and above, you should be able to access this using:
http://localhost:8080

We are still working on all the checkmarks that are needed to be able to propagate this fix to Windows April 2018 Update and Windows Server, version 1803. I will post back here if a KB is released.

@daschott
Copy link
Contributor

@daschott daschott commented Jul 30, 2018

Hi, @MikeChristensen @rs38 @StefanScherer. We backported the container localhost/loopback access fix for Windows April 2018 Update (Windows 10 version 1803) through KB4340917, available now.

To validate this fix, you can use docker run -p 8080:80 microsoft/iis command. Once the container is running, you should be able to use loopback and access the container using http://localhost:8080 or http://127.0.0.1:8080.

@MikeChristensen
Copy link

@MikeChristensen MikeChristensen commented Jul 31, 2018

Confirmed this works on Windows 10 with latest updates. Thanks!!

@adragoset
Copy link

@adragoset adragoset commented Sep 6, 2018

@daschott has the fix been ported to Windows Server, version 1803

@daschott
Copy link
Contributor

@daschott daschott commented Sep 6, 2018

@adragoset
see this previous comment

This should work for you on 1803 with the KB4340917 now :)

@scooley
Copy link
Contributor

@scooley scooley commented Nov 3, 2018

Fixed in 1803. See KB4340917

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests