Recently, I realized that I can not make a successful connection from a vm to a container.

VM - 192.168.255.19
Container - Bridged - 192.168.255.241:9889

Using curl as an example from the vm to the container: 

curl https://192.168.255.241:9889
curl: (7) Failed connect to 192.168.255.241:9889; Connection refused

The container is reachable on 9889 from anywhere else other than a VM running on the same host. And the VM can get to any other resource on my network other than containers. 

Nmap from the vm to 192.168.255.241 -p 9889 confirms it "closed"
 

9889/tcp closed unknown

However, this feels like a routing issue to me. I did a pcap between my host and the gateway and never saw a packet. I would expect to see at least an ARP for 192.168.255.241 from the VM, but I do not see this. 

A curl from the same VM to a container in the host network is successful:
 

curl 192.168.255.241:8181
This resource can be found at <a href="http://192.168.255.241:8181/auth/logout?redirect_uri=/">http://192.168.255.241:8181/auth/logout?redirect_uri=/</a>.

Thoughts? 

stylophora-diagnostics-20181008-2223.zip

 

On 10/9/2018 at 6:53 AM, jonathanm said:

 

This isn't necessarily what I'm looking for I believe. 

What I am running into is a vm, with its own separate ip from the unraid host on a separate bridge interface, can not communicate to the unraid host ip:port when a container is in bridged mode. 

 

I don't need a container to go out and loopback to the unraid host ip. That I understand as a security implementation from docker itself. 

 

In my case, the vm should be treated as a separate entity and be able to communicate with the unraid host ip just as any other client in the same vlan would. Unless there is an underlying destination check prior to leaving the host to get onto the actual network.