Windows Server 2019 publish ports in swarm not working

[darrensteadman]

Description

When running a container in a single node swarm on Windows Server 2019 you can not access the published ports.

Steps to reproduce the issue:

1. Create a fresh VM on Azure using the Windows Server 2019 Datacenter with Containers image
2. Fully patch the VM.
3. Install latest docker update 18.09.6
4. Run swarm init
5. Use the following service yml file

version: '3.5'

services:
  webtest:
    image: mcr.microsoft.com/dotnet/core/samples:aspnetapp
    deploy:
      replicas: 1
      endpoint_mode: dnsrr          
    ports:
      - target: 80
        published: 8000
        protocol: tcp
        mode: host

6. Run the following to deploy the service

docker stack deploy -c .\service_test.yml service_test

7. Try and browse to http://localhost:8000 or http://local ip of machine:8000

Describe the results you received:

The browser sits there forever and never makes a connection. If you look in the resource monitor in Windows you see that dockerd.exe is listening on port 8000 on all interfaces.

When you point a browser at that port you can see in resource monitor that dockerd has accepted a connection on port 8000 but it just doesn't appear to be doing anything with it.

If you just run the command

docker run -it --rm -p 8000:80 --name aspnetcore_sample mcr.microsoft.com/dotnet/core/samples:aspnetapp

I.E just run is as a container by itself and not on the swarm then everything works fine.

If I do the same steps using the following yml

version: '3.5'

services:
  webtest:
    image: mcr.microsoft.com/dotnet/core/samples:aspnetapp
    deploy:
      replicas: 1      
    ports:
      - target: 80
        published: 8000
        protocol: tcp    

It still fails but this time I don't see any listening ports for dockerd in resource monitor.

If I restart the docker service I find that the following events are logged in event viewer

HNSNetwork Request ={"Name":"uzjewd94ge9hi38jqzpseo0zx","Type":"overlay","Subnets":[{"AddressPrefix":"10.255.0.0/16","GatewayAddress":"10.255.0.1","Policies":[{"Type":"VSID","VSID":4096}]}],"AutomaticDNS":true}

followed by

Failed creating ingress network: hnsCall failed in Win32: An adapter was not found. (0x803b0006)

I found some comments online indicating this had something to do with only one physical network adapter being available on the machine so I added another network adapter in Azure and this error disappears but I still can't access the container when it is in a swarm.

Describe the results you expected:

I'd expect to be able to access the website inside the container.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client: Docker Engine - Enterprise
 Version:           18.09.6
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        1578dcadd2
 Built:             05/04/2019 02:34:11
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          18.09.6
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       1578dcadd2
  Built:            05/04/2019 02:32:24
  OS/Arch:          windows/amd64
  Experimental:     false

Output of docker info:

Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 3
Server Version: 18.09.6
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: active
 NodeID: z59hrmf76s22pnnjo3t8xz7vt
 Is Manager: true
 ClusterID: lp7wuobnabi7rj0eow628k2x5
 Managers: 1
 Nodes: 1
 Default Address Pool: 10.0.0.0/8
 SubnetSize: 24
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 10
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 10.0.5.5
 Manager Addresses:
  10.0.5.5:2377
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.475)
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 4GiB
Name: docker2019
ID: T6FB:4SLL:ASKC:YHC6:3CP3:N2Q6:ULCQ:GAWL:PSEZ:3REE:GYFM:CJ7X
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Azure

[darrensteadman]

Looks like this is very similar to #39065

[olljanat]

@daschott PTAL is this actually broken again on Win Srv 2019?

[daschott]

Thanks @olljanat & @darrensteadman we will take a look at this and related bugs.

@pradipd FYI

[93Kamuran]

can anyone say how can solution of ''hnscall failed an adapter was not found'' I cannot run portrainer and stefanscherer/traefik-windows in my docker swarm.. I waste two days about this.

[93Kamuran]

@olljanat my friend ım following your pieces of advice that you say my after a few weeks ago, for my company. ı have new issues as ı says above.. ı cannot use portrainer and stefanscherer/traefik-windows ım trying your new advices right now ı hope ı can deploy the stack..
thank you for the answer.

[93Kamuran]

@olljanat can you share some example compose-file include portrainer(ubuntu 18.03 worker) and portrainer agent(windowsserver 2019 master) please ..
because ı could not achieve to deploy

[thaJeztah]

/cc @ddebroy

[93Kamuran]

@olljanat ım very confused I just would like to use portrainer not agent just portrainer an traefik for windows for modern reverse proxy and let's encrypt on my swarm . For now, I have nothing on my hand, treafik says "hnscall fail in win32 .an adapter was not found" portrainer says same too if run it my master (windows). This is my situation please give me an advice which way should I use?

[93Kamuran]

if ı use docker run command will portrainer as been part of the swarm ? and should I use this workaround for use traefik? I want to run it in master node. How can I specified node placement in run command like . "--placement-pref spread=node.labels.win treafik " ?

[olljanat]

@93Kamuran this is not right place to discuss about it. Plz contact me on Docker community or Portainer Slack!

I removed my unrelated to keep this clear. Plz do same.

[darrensteadman]

Just an update.

I've updated my VM to the latest of everything this morning and still no difference.

Client: Docker Engine - Enterprise
 Version:           18.09.7
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        b81f47481d
 Built:             06/27/2019 17:58:58
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          18.09.7
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       b81f47481d
  Built:            06/27/2019 17:57:09
  OS/Arch:          windows/amd64
  Experimental:     false

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 6
Server Version: 18.09.7
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: active
 NodeID: utkz8l4zul3e4chfvof4p42gv
 Is Manager: true
 ClusterID: tscdfu2b2zbbyvfvlckf538ub
 Managers: 1
 Nodes: 1
 Default Address Pool: 10.0.0.0/8
 SubnetSize: 24
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 10
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 10.0.5.5
 Manager Addresses:
  10.0.5.5:2377
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.593)
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 4GiB
Name: docker2019
ID: T6FB:4SLL:ASKC:YHC6:3CP3:N2Q6:ULCQ:GAWL:PSEZ:3REE:GYFM:CJ7X
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
mcr.microsoft.com/dotnet/core/samples   aspnetapp           032f695b63fc        2 weeks ago         404MB
mcr.microsoft.com/dotnet/core/samples   <none>              97a66668a373        5 weeks ago         404MB
mcr.microsoft.com/dotnet/core/samples   <none>              36d768fe0b46        5 weeks ago         404MB
mcr.microsoft.com/dotnet/core/samples   <none>              406d5117a277        2 months ago        405MB
mcr.microsoft.com/windows/servercore    ltsc2019            954d1507112f        2 months ago        4.43GB
mcr.microsoft.com/windows/nanoserver    1809                e9bbec97e222        2 months ago        250MB

Any chance any progress has been made on this?

[drnybble]

In a multi-node Swarm cluster ingress routing only seems to work if you do not access it from localhost!

[darrensteadman]

After some more playing around I can confirm that while nothing works if you try to access the swarm from the host machine it appears that accessing the machine from an external address works.

So if I take the above setup and expose it to the internet in azure then hit the external IP it works ok.

It would appear there is just a problem with communication from/to the local host machine.

[drnybble]

One really nice benefit of accessing a service on localhost is running a Docker registry that all engines in the Swarm can access via the localhost insecure registry configuration. Since this doesn't work you have to expose one using the host port option and either add it as an insecure registry or copy a certificate around.

[pradipd]

@drnybble: In Windows, we made a design decision to not allow the host to access the overlay network (swarm).
However, it seems like the community wants/expects host to overlay network connectivity. Also, Kubernetes requires this. I believe we added a flag to enable this in RS5.
Let me check the flag and the OS and see if I can hook it up.

[seanschneeweiss]

@pradipd Any news on host to overlay network connectivity?

[daschott]

@Schneereich @drnybble Besides accessing a local container registry, can you outline any additional of your scenarios that rely on localhost access for overlay services in Docker Swarm?

As @pradipd indicated, we made this scenario light up in Kubernetes first here, but not in Docker Swarm yet.

Based on your feedback, we will prioritize working on this against other feature requests. Thank you in advance!

[seanschneeweiss]

@daschott Thank you for including this feature in your priorities.
I think there are several cases when the container host has to access the service offered with Docker Swarm mode. Even though the access via localhost is available with containers running by the docker run or docker-compose commands, for production use, Docker swarm mode is the prefered solution, as the others don't offer all the automation for availability.
Examples:

• running a Git repository in containers, which should also be accessible by the host
• if the host would be used as a remotedesktop server / terminalserver some applications might need access to the containers inside the swarm on the same host. (might be the case in small setups)
• there might be some legacy applications that cannot run in containers (e.g. GUIs) and they need access to a service available on localhost
• access a VNC server running inside a container from the host

Probably there are more scenarios but this came into my mind.

Thank you!

[vitaliy-leschenko]

@darrensteadman try to upgrade to docker 19.03. it works fine for me.

[ordinaryorange]

@darrensteadman @vitaliy-leschenko @daschott I just spun up a VM on Azure and stack deployed the following compose to a single node Win2019 server with containers.

services: 
    testsvc :
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        command: ping localhost /t

Whilst I did not test the port access issue @darrensteadman reported, I was more interested in the error

hnsCall failed in Win32: An adapter was not found

On the azure VM the service and task start just fine.

However on a fully patched Win10 desktop with docker desktop community 19.03.05 the single node swarm service continually terminates the task and attempts to restart it every 5 seconds, citing the error above.

@daschott Will whatever fixed this in Enterprise trickle down to community version ?
Would be nice to keep testing locally.

[djarvis]

@pradipd @daschott I am also interested if this is ever resolved in Windows 10 Docker Desktop Community. I cannot deploy any docker stack as I get the dreaded "hnsCall failed in Win32: An adapter was not found. (0x803b0006)" for each container. Everything works fine on Windows Server 2019/Docker EE.

All of this talk about adding and removing network adapters and bindings and so forth really confuses me so if there is an answer to all of this and if anyone is willing to hold my hand and walk me through it like I'm a 6-year old, then I'd surely welcome it.

Thanks!

@darrensteadman @vitaliy-leschenko @daschott I just spun up a VM on Azure and stack deployed the following compose to a single node Win2019 server with containers.

services: 
    testsvc :
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        command: ping localhost /t

Whilst I did not test the port access issue @darrensteadman reported, I was more interested in the error

hnsCall failed in Win32: An adapter was not found

On the azure VM the service and task start just fine.

However on a fully patched Win10 desktop with docker desktop community 19.03.05 the single node swarm service continually terminates the task and attempts to restart it every 5 seconds, citing the error above.

@daschott Will whatever fixed this in Enterprise trickle down to community version ?
Would be nice to keep testing locally.

[olljanat]

@djarvis there is no difference on code between CE and EE. But there is big difference on default settings between desktop and server version because on Win 10 default isolation mode is hyper-v and on server it is process.

So if you want to be able test same way than on server you need use --isolation=process switch on docker run (or change default behavior from daemon.json).

NOTE that OS build must match which means ltsc2019 tagged image can only run on 1809 build of Win 10.

[djarvis]

@olljanat Thanks, every little bit helps.

I can run my images normally using docker run, so I know the image is OK. I tried adding additional network adapters to the DockerDesktopVM HyperV instance but that didn't seem to do anything.

When I leave my swarm and try to do just a plain "docker swarm init" it comes back with "Error response from daemon: could not find the system's IP address - specify one with --advertise-addr". Now something I read suggests that I shouldn't have to specify an --advertise-addr. Is the fact that this error is coming back indicating something is generally awry?

When I do specify --advertise-addr with my IP address, it works but when I deploy a simple swarm I get the "hnsCall failed in Win32: An adapter was not found. (0x803b0006)" when I "docker ps xx --no-trunc".

[daschott]

HNS network creates vSwitch. vSwitch needs network adapter. This error means you have no available adapter to create vswitch. Likely you have a Vswitch already present.

Can you run:

1. remove any containers running on the system and execute docker swarm leave --force on the node
2. Then run get-hnsnetwork | remove-hnsnetwork
3. Then confirm there are no networks present using get-hnsnetwork
4. now try to init again

[djarvis]

@daschott

Hi!

I did step #1. Left the node, all is well.
I did step #2.
I did step #3, and it first it reported no networks. Then after a second or so it reported a "Default Switch", which I always see in Hyper-V's Virtual Switch Manager. I cannot remove it here.
I did step #4, a simple "docker swarm init" and I got:

Error response from daemon: could not choose an IP address to advertise since this system has multiple addresses on different interfaces (10.234.202.141 on Ethernet and 192.168.0.129 on vEthernet (Default Switch)) - specify one with --advertise-addr

So, this is different behavior, which is promising.

When I choose my ethernet adapter (--advertise-addr=10.234.202.141) and deploy the stack, things are better, I can see my one container starting, but then it fails, and it tries to start it again, and then it fails, and then it tries to start it again, etc. until I remove the stack.

[daschott]

Can you re-run the steps above again and during init step #4 ensure you use syntax:
docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377

Before doing so please also make sure that following ports are open:
TCP port 2377,7946
UDP port 7946,4789

[djarvis]

Hi @daschott

I opened up the ports in the fire wall and re-ran the steps. When I remove all hnsnetworks and get them all again, it shows none, but only for like 5 seconds or so. Then the "Default Switch" network gets recreated again.

Nonetheless I init the swarm with the aforementioned advertise/listen parameters and deploy the simple stack.

The same thing happens- the container gets created, then 10 seconds later it fails, and it creates another one. At any given time I'll have 2-4 of them running.

What's noteworthy is that ever since I started messing with get-hnsnetwork and remove-hnsnetwork, my regular network shows (in the icon tray) the network intermittently coming up and going down WHILE my stack is deployed. When I bring down the stack my network shows steady on.

My yaml file:

_version: '3.7'
services:
  mgmt:
    image: "mysimplecontainer:latest"
    networks:
      - test

networks:
  test:
    driver: overlay_

[djarvis]

docker stack ps shows this for the failed containers

starting container failed: hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

[djarvis]

@daschott Ok here's a fun little piece of information.

When I have my service like:

services:
  mgmt:
    image: "mysimplecontainer:latest"
    networks:
      - test

and I bring up the stack, my network icon disconnects for a bit then comes back up after maybe 5 seconds or so, but then the container gets created and stays up. I only ever have one container running, so all seems well now.

HOWEVER,

When do this:

version: '3.7'
services:
  mgmt:
    image: "captureappliance.azurecr.io/infuseproxy:latest"
    networks:
      - test
    secrets:
      - mysecret
      
networks:
  test:
    driver: overlay

secrets:
  mysecret:
    file: ./mysecret.txt

My network my network icon disconnects for a bit then comes back up after maybe 5 seconds or so, but then I run into the multiple container fails/starts with "starting container failed: hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)".

So in short when I use secrets I run into this bizarre situation.

[djarvis]

Nuts.

I knew this too.

I had OneDrive running on this particular box, which has adverse effects when building windows docker containers. Since it was the same error I figured it was the problem. I removed OneDrive, which presumably makes ExpanDrive (cbfs6.sys) not load, which no longer results in this error.

So as far as I can tell everything is working as it should, albeit from the little network blips I see when deploying a swarm, but perhaps that's expected.

[djarvis]

@vitaliy-leschenko

@darrensteadman try to upgrade to docker 19.03. it works fine for me.

I'm running 19.03.5 and still cannot access the swarm nodes locally.

It's quite a nuisance.

[djarvis]

My next issue is that I cannot access the Internet from inside my deployed containers in Swarm mode when using a Windows Server 2019 VM in Azure. I try to init the swarm against the two adapters that I see available but still can't ping 8.8.8.8 from in a container.

[daschott]

Instead of ping, can you try to curl some external site like google.com e.g. run iwr -useb google.com from inside the container?

[djarvis]

No, it does not work from within an overlay network.

When I do:

docker run --rm mcr.microsoft.com/dotnet/core/runtime:2.2 curl google.com

It works, I get a response.

When I do:

docker network create mynet -d overlay --attachable
docker run --rm --network mynet mcr.microsoft.com/dotnet/core/runtime:2.2 curl google.com

I do not get a response. Neither when I use an IP address:

docker run --network mynet --rm mcr.microsoft.com/dotnet/core/runtime:2.2 curl 13.90.143.69

ipconfig /all from within the container:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 64752046c74b
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : 3pqjrsfb5kxubpm0bn2bf4tkfc.bx.internal.cloudapp.net

Ethernet adapter vEthernet (bd1232ac2c7b1a9981cb7a9fa9df509d5f97752a2a3b18fdaf21307bf20a7d79):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physical Address. . . . . . . . . : 00-15-5D-67-FB-A0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::4d4f:f96e:80b7:3128%31(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.8.11(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.8.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

I also tried this:

docker network create -d overlay -o com.docker.network.windowsshim.enable_outboundnat=true mynet

But that didn't change anything.

ipconfig /all on the host:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : dan2
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : 3pqjrsfb5kxubpm0bn2bf4tkfc.bx.internal.cloudapp.net

Ethernet adapter vEthernet (Ethernet):

   Connection-specific DNS Suffix  . : 3pqjrsfb5kxubpm0bn2bf4tkfc.bx.internal.cloudapp.net
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : 00-0D-3A-11-E5-7F
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::f490:a498:e28:115d%8(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.0.7(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, February 27, 2020 5:05:48 PM
   Lease Expires . . . . . . . . . . : Monday, April 5, 2156 12:38:09 AM
   Default Gateway . . . . . . . . . : 10.0.0.1
   DHCP Server . . . . . . . . . . . : 168.63.129.16
   DHCPv6 IAID . . . . . . . . . . . : 134221114
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-E9-27-25-00-0D-3A-11-E5-7F
   DNS Servers . . . . . . . . . . . : 168.63.129.16
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (nat):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-60-FC-83
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::443f:58c8:5234:cfd0%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.18.16.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 201332061
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-E9-27-25-00-0D-3A-11-E5-7F
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

So when I init the swarm I init on --advertise-addr=10.0.0.7, but I have tried the other network as well. Do I need to somehow create another hnsnetwork?

Get-HnsNetwork:

ActivityId             : BDCC1224-0BBA-4744-B4BC-9F2559100748
AdditionalParams       :
CurrentEndpointCount   : 0
Extensions             : {@{Id=E7C3B2F0-F3C5-48DF-AF2B-10FED6D72E7A; IsEnabled=False; Name=Microsoft Windows Filtering Platform},
                         @{Id=E9B59CFA-2BE1-4B21-828F-B6FBDBDDC017; IsEnabled=False; Name=Microsoft Azure VFP Switch Extension},
                         @{Id=EA24CD6C-D17A-4348-9190-09F0D5BE83DD; IsEnabled=True; Name=Microsoft NDIS Capture}}
Flags                  : 0
Health                 : @{AddressNotificationMissedCount=0; AddressNotificationSequenceNumber=0; InterfaceNotificationMissedCount=0;
                         InterfaceNotificationSequenceNumber=0; LastErrorCode=0; LastUpdateTime=132272940699156224; RouteNotificationMissedCount=0;
                         RouteNotificationSequenceNumber=0}
ID                     : C1FE57EA-258F-4849-B625-9950F7525209
IPv6                   : False
LayeredOn              : 0DAA07CA-FD5D-4092-87F7-95C2D722FFA4
MacPools               : {@{EndMacAddress=00-15-5D-60-FF-FF; StartMacAddress=00-15-5D-60-F0-00}}
MaxConcurrentEndpoints : 1
Name                   : nat
NatName                : ICS609D6AAE-A517-44CB-BFFF-D992208A8AF0
Policies               : {}
Resources              : @{AdditionalParams=; AllocationOrder=2; Allocators=System.Object[]; Health=; ID=BDCC1224-0BBA-4744-B4BC-9F2559100748;
                         PortOperationTime=0; State=1; SwitchOperationTime=0; VfpOperationTime=0; parentId=F75F5115-E6AB-4520-867F-8C4A9399611D}
State                  : 1
Subnets                : {@{AdditionalParams=; AddressPrefix=172.18.16.0/20; GatewayAddress=172.18.16.1; Health=;
                         ID=350C5192-26EC-4CE8-8ECD-401C2DD927C8; Policies=System.Object[]; State=0}}
TotalEndpoints         : 4
Type                   : nat
Version                : 38654705666

ActivityId             : F170AD8C-F16F-4742-ADD4-9F0EC026175C
AdditionalParams       :
AutomaticDNS           : True
CurrentEndpointCount   : 0
DNSServerCompartment   : 3
DrMacAddress           : 00-15-5D-EC-0F-71
Extensions             : {@{Id=E7C3B2F0-F3C5-48DF-AF2B-10FED6D72E7A; IsEnabled=False; Name=Microsoft Windows Filtering Platform},
                         @{Id=E9B59CFA-2BE1-4B21-828F-B6FBDBDDC017; IsEnabled=True; Name=Microsoft Azure VFP Switch Extension},
                         @{Id=EA24CD6C-D17A-4348-9190-09F0D5BE83DD; IsEnabled=True; Name=Microsoft NDIS Capture}}
Flags                  : 0
Health                 : @{LastErrorCode=0; LastUpdateTime=132272967464704708}
ID                     : A72D4A38-A708-474B-B715-D6100EA4ADD4
IPv6                   : False
LayeredOn              : B748510C-0D60-4002-A91C-9614F956E7AB
MacPools               : {@{EndMacAddress=00-15-5D-F6-AF-FF; StartMacAddress=00-15-5D-F6-A0-00}}
ManagementIP           : 10.0.0.7
MaxConcurrentEndpoints : 0
Name                   : r46hdjhp98pikok2jb67l5avp
Policies               : {}
Resources              : @{AdditionalParams=; AllocationOrder=1; Allocators=System.Object[]; Health=; ID=F170AD8C-F16F-4742-ADD4-9F0EC026175C;
                         PortOperationTime=0; State=1; SwitchOperationTime=0; VfpOperationTime=0; parentId=D3C26B4D-7DC8-43D7-AE5D-173ACC792246}
State                  : 1
Subnets                : {@{AdditionalParams=; AddressPrefix=10.0.0.0/24; GatewayAddress=10.0.0.1; Health=; ID=1CADAE94-3D55-49F2-B9C8-E939595D9F5E;
                         ObjectType=5; Policies=System.Object[]; State=0}}
TotalEndpoints         : 0
Type                   : overlay
Version                : 38654705666

[djarvis]

I guess in the end what it was was the ingress network being created with conflicting subnets. Simply removing and recreating the ingress network in most cases did the trick.

[psandeep09]

Still facing issue, any update

[sun-rs]

Still facing issue, any update