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

Configuring Windows vEthernet Adapter Networks to Properly Support Docker Container Volumes #11528

Closed
scrap-worker opened this issue Mar 27, 2019 · 8 comments

Comments

@scrap-worker
Copy link

scrap-worker commented Mar 27, 2019

Help us make content visible

  • Searched for Docker container volumes and vEthernet
  • Found "Docker containers, images, and registries"

Configuring Windows vEthernet Adapter Networks to Properly Support Docker Container Volumes

  • There is no generally known way to support Docker Container Volumes in Windows when Windows Firewall is enabled. This is due in part to the fact that Windows defines the vEthernet Adapter networks as "Public". There does not appear to be a way to manually identify these virtual networks. All work-arounds (see the docker for windows issue below) expose users to potential security risks.
  • This document should be available directly under "Docker containers, images, and registries."
  • Abstract: There are some complexities involved with getting Windows, Windows Firewall and Docker for Windows configured to support Docker Container Volumes in a stable and secure manner.
  • Outline:
    • The vEthernet adapter and how Windows identifies networks.
    • Windows Firewall Rules
      • Public Network (Deny Default / Deny All)
    • Docker for Windows and the DockerNAT (The 10.0.75.x IP space it creates)
    • Configuration Options

Further context: docker/for-win#367 (comment)

edit by @mairaw: added article details


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label Mar 27, 2019
@mairaw
Copy link
Contributor

mairaw commented Apr 22, 2019

@Thraka can you take a look at this feedback?

@mairaw
Copy link
Contributor

mairaw commented Apr 22, 2019

Also adding @mvelosop and @nishanil since the feedback seems to be related to the e-book article and not our own Docker content.

@mairaw mairaw added waiting-on-feedback Waiting for feedback from SMEs before they can be merged and removed ⌚ Not Triaged Not triaged Source - Docs.ms labels Apr 22, 2019
@mvelosop
Copy link
Contributor

Hi @CyrexCore2k, thanks for the heads up!

@mairaw, I just have a basic knowledge of networks, so I can't go too deep in this issue (if at all), however this seem to be related to a recurring issue we've been having in eShopOnContainers.

At some point @huangmaoyixxx suggested a solution to issue #295 that seems to have worked for quite some people.

However, I'm not sure the Microservices Architecture Guide is the right place to show this level of detail. Anyway I do think this would be a great topic for a page in eShopOnContainers's wiki to which we could link from the guide.

@CyrexCore2k, it looks like you are knowledable in this topic, so it'd be great if you could explain this in the wiki 😊!

@scrap-worker
Copy link
Author

scrap-worker commented Apr 25, 2019

Thanks @mairaw and @mvelosop for your responses.

The solution suggested by @huangmaoyixxx appears to for a different issue and in the context of a non-corporate machine. Here is the situation that I'm in:

  1. Corporate Group Policy Firewall rules are set to deny all inbound access from networks designated as Public. While I can override these settings to allow inbound connections on Public networks I would probably be violating (a justifiable) corporate security policy and exposing my machine to security risks whenever I connect to Wifi at a coffee shop or airport.
  2. Windows Firewall designates all "unidentified networks" as Public.
  3. Docker for Windows creates a network using the Virtual NIC and calls it DockerNAT
  4. Windows Networking designates DockerNAT as an unidentified network. I have not discovered a way to identify the network.
  5. When Docker containers attempt to mount volumes from the host machine an inbound connection from the Docker daemon to the host machine is made on this network.

Obviously there is little/no security risk to allowing inbound connections from DockerNAT but given these five items I have not discovered a way to permanently allow inbound connections from DockerNAT. A solution which does not survive reboots is to tell Windows Firewall to consider the DockerNAT network as Private even though it is an unidentified network using the command:

Get-NetConnectionProfile | Where-Object { $_.InterfaceAlias -match "(DockerNAT)" } | ForEach-Object { Set-NetConnectionProfile -InterfaceIndex $_.InterfaceIndex -NetworkCategory Private }

While I do agree this documentation may not be the appropriate place to dig into the details of the issue this is where I ended up after a google search. Pointing to another location makes sense and while I can see how the eShopOnContainers project has run into the same thing it seems like it too would benefit from a location where this documentation can be placed.

Question is, where, and who do we talk to about this? Not trying to assign blame or downplay the complexities involved but this appears to be a Windows issue. There should be a way that Docker for Windows can set up the DockerNAT network it creates so that Windows Networking can identify the network (and hence Windows Firewall would allow me to permanently specify it as a Private Network) but since I can't figure out how to do that as an Administrator of my own machine my (semi-educated) guess is that Windows Networking does not provide a way or document how to do this. I don't know enough about the internals of Microsoft to know how to facilitate getting the .Net Core / Windows Networking / Windows Firewall people and perhaps some knowledgeable Docker devs to coordinate and come to a solution.

@mairaw would you be able to offer some guidance here?

@Thraka
Copy link
Contributor

Thraka commented Apr 25, 2019

This is outside our scope. After reading through the threads (and others on Dockers site) it sounds like the problem is with Docker and Windows not playing nicely together. This isn't related to .NET at all.

The main pain point sounds like you can't customize the network that docker installs because after reboot or upgrade docker reverts your changes. The problem seems to be with Docker not allowing that customization to persist.

It would be nice if Docker (during setup) would ask you if you want a locked down network (public-restricted) or a developer machine network (private-unrestricted) and set the defaults for the network appropriately.

If we had a tutorial that was related to a .NET Core app where we needed this network working, we would be describing the same thing: run this powershell script each time you start developing with Docker to get around the problem. Until Docker allows you to customize the default behavior of the network, we're all stuck in this situation.

@Thraka Thraka closed this as completed Apr 25, 2019
@Thraka Thraka added external Not related to content and removed waiting-on-feedback Waiting for feedback from SMEs before they can be merged labels Apr 25, 2019
@scrap-worker
Copy link
Author

scrap-worker commented Apr 26, 2019

@Thraka
This isn't a problem with Docker. This is a problem with the way Windows Networking identifies networks. I get that this isn't directly related to .Net itself but it is a problem that your user base is dealing with. Can you give some guidance as to how we can get this problem resolved?

@scrap-worker
Copy link
Author

scrap-worker commented Apr 27, 2019

@Thraka
Furthermore the issue you linked is unrelated to the issue I'm describing. The issue you pointed to is about allowing external machines to connect to containers through the docker host machine. That isn't the problem being described here. Honestly I'm a bit disappointed that I put so much work into describing what's going on but it doesn't seem like you took the time to read it before summarily dismissing and closing the issue.

@mvelosop
Copy link
Contributor

Thanks @CyrexCore2k,

This is certainly a pain point for eShopOnContainer users, so I'll add this to a new networking page in the wiki.

We are currently revamping the README and Wiki pages of eShop, and I'll let you know when it's public, so you can take a look and add content if you like, it'd be much appreciated.

In the meantime, I'll add the PR sumbitted by @gababu with your proposal.

Cheers.

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

No branches or pull requests

6 participants