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

Not able to see host ports from 10.0.75.1, but can from 192 host IP #334

Closed
bradyemerson opened this issue Dec 18, 2016 · 10 comments
Closed

Comments

@bradyemerson
Copy link

Expected behavior

Should be able to reach container host from inside container over 10.0.75.1 ip address.

Actual behavior


# nmap 10.0.75.1

Starting Nmap 7.01 ( https://nmap.org ) at 2016-12-18 09:59 UTC
Nmap scan report for 10.0.75.1
Host is up (0.0031s latency).
All 1000 scanned ports on 10.0.75.1 are filtered

Nmap done: 1 IP address (1 host up) scanned in 22.35 seconds

# nmap 192.168.56.1

Starting Nmap 7.01 ( https://nmap.org ) at 2016-12-18 10:02 UTC
Nmap scan report for 192.168.56.1
Host is up (1.0s latency).
Not shown: 993 closed ports
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
2179/tcp  open  vmrdp
5357/tcp  open  wsdapi
8081/tcp  open  blackice-icecap
16992/tcp open  amt-soap-http

Nmap done: 1 IP address (1 host up) scanned in 27.20 seconds

Information

  • Version 1.12.3 (8488)
  • Windows 10 running hyper-v
  • I confirmed 10.0.75.1 is my host IP via ipconfig
  • I'm on a corporate laptop assigned to a domain

Steps to reproduce the behavior

  1. I utilized nmap to test open ports from my 10 IP as well as my 192 IP
@rn
Copy link
Contributor

rn commented Dec 19, 2016

@bradyemerson this looks like a duplicate of #37. Could you confirm that you try to connect from a container to service running on the host?

Also, I'm a little confused about 10.0.75.1. This is the default address we use for the internal network between the Linux VM and the host but you say that it's your "Host IP address".

FWIW with Beta33 I can do:

PS C:\Users\rneugeba\Desktop> docker run -ti --rm alpine ping -c 1 10.0.75.1
PING 10.0.75.1 (10.0.75.1): 56 data bytes
64 bytes from 10.0.75.1: seq=0 ttl=127 time=0.977 ms

--- 10.0.75.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.977/0.977/0.977 ms

and:

PS C:\Users\rneugeba\Desktop> docker run -ti --rm alpine /bin/sh -c "apk add -U nmap && nmap 10.0.75.1"
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
(1/4) Installing libgcc (5.3.0-r0)
(2/4) Installing libpcap (1.7.4-r0)
(3/4) Installing libstdc++ (5.3.0-r0)
(4/4) Installing nmap (7.12-r0)
Executing busybox-1.24.2-r11.trigger
OK: 17 MiB in 15 packages

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-19 11:56 UTC
Nmap scan report for 10.0.75.1
Host is up (0.00078s latency).
Not shown: 994 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2179/tcp open  vmrdp
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 205.98 seconds

@bradyemerson
Copy link
Author

@rneugeba thanks for the response. This does seems similar to #37 and will try to use the nginx suggestion. The service I'm trying to connect to specifically is Windows file share (port 445) to enable folder sharing between host and container. Currently I'm unable to enable C drive for sharing.

To clarify on 10.0.75.1, I'm referring to the internal network. I can see that my host machine has been assigned 10.0.75.1 on the internal network via ipconfig.

This works fine on another Windows 10 computer I have, which is not on a corporate domain, so I feel this must be something unique with that.

I'm looking to see if other's have had similar issues with corporate networked laptops and if there is a suggested work around. Thanks!

@rn
Copy link
Contributor

rn commented Dec 21, 2016

This sounds more like a firewall issue. Is port 445 enabled? Do you have any third party firewall software installed?

@bradyemerson
Copy link
Author

The standard DockerProxy rules are enabled in the Windows Firewall. I'm not aware of any other firewall in place. We do have McAfee and Malwarebytes as well.

I tried the nginx proxy approach suggested in #37 and it's not able to bind to port 445 as the windows service has already bound to it. I could use a nonstandard port (ex 8445), but is it possible to tell Docker to use this port instead of standard 445 for file sharing?

@bradyemerson
Copy link
Author

This can be closed. It is definitely something related to our corporate Win 10 settings, but I have been unable to narrow it to a specific setting or conflicting software. It works fine on my non-corporate Win 10 machine.

I have worked around this by using Docker Toolbox + VirtualBox.

@mikedarke
Copy link

If you do find a solution to this @bradyemerson let me know, I'm having the same issue on our corporate network as well.

@bradyemerson
Copy link
Author

@mikedarke I used Docker Toolbox (https://www.docker.com/products/docker-toolbox) with Oracle VirtualBox instead hyper-v.

@mikedarke
Copy link

@bradyemerson yeah thanks, I'll try that instead as well

@szczurmys
Copy link

You can try add incoming rule in firewall:

Example:

  • protocol: any/tcp/udp/...
  • program: any
  • action: allow
  • local port: any
  • remote port: any
  • local address: 10.0.75.1
  • remote address: 10.0.75.0/24

or you can try use address 10.0.75.2 instead of 10.0.75.1

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants