I have an issue where I cannot run the emulated hue bridge because port 80 is already used by my Synology. I was told I can create a “network” to run my container on, but I just dont understand the process to do it.
Anyone done this before and can point me in the right direction?
That will change HA from running “host” vs you publishing individuals ports.
This however will not change hue issue. I cannot remember but I don’t think emulated hue work unless using host and external devices not discovering emulated hue but I may e wrong. Haven’t used that integration in a while
Anyway docker documation explains ports and networking
If you generate a MACVLAN and assign a unique address to your container, it will become a standalone device on your network.
It can also communicate with other devices on the network without any problems.
But be careful: It can no longer communicate with the Docker Host, because the host network and possible MACVLANS or other Docker networks are decoupled.
For this you have to set up a loopback an tell your host machine how to cummincate with your macvlan containers.
This is a confoguration example for docker macvlan with host connection how I did it:
docker network create -d macvlan -o parent=eno1 \
--subnet 192.168.178.0/24 \
--gateway 192.168.178.1 \
--ip-range 192.168.178.192/27 \
--aux-address 'host=192.168.178.223' \
mynet
ip link add mynet-shim link eno1 type macvlan mode bridge
ip addr add 192.168.178.223/32 dev mynet-shim
ip link set mynet-shim up
ip route add 192.168.178.192/27 dev mynet-shim
The first command generates a Docker MACVLAN with the reserved IP address 192.168.178.223, so that it is not used by Docker when creating containers.
The second command generates a MACVLAN interface named mynet-shim on the Docker host
The third and fourth commands assign the host MACVLAN interface the previously reserved IP address and start it
The fifth command tells the host how to use that interface when communicating with the containers
These where only the commands with which you can create your docker network and tell your host how to communicate with your macvlan containers.
You can then set the IP address of your Homassistant Container for example in your docker-compose.yaml.
I have assigned two networks to my Homassistant Container. The previously created MACVLAN and a proxy network for Traefik. You can ignore the proxy network and all the labels part, if you don’t use it.
The Homassistant ip in this example is 192.168.178.203
Be aware that Synology native packages such as VPN-server and Surveillance-Stations not play well with network interfaces created outside of Synology’s Docker UI.
I’ve been in contact with support trying to understand what parts that are missing when using the CLI but they just say that we must use the GUI (i.e. I don’t get past 1-2nd line support).
Have you heard any more on this? When you say don’t play nicely, when using VPN, is it not able to see the IP used from macvlan for HA? I am new to HA (first week) and have started to implement a lot. I planned on using VPN to access from remote rather than the cloud service.
I’ll go search the Synology forums, but while on the topic of port 80 in DSM, anyone know why its forwarded to the port you choose in DSM setup? Perhaps break this forward. Would solve OP.
##Update. Read up on the need for port 80 on synology. Would require a hack to alter. Use macvlan.
Sorry for the post digging up but I have a similar problem than I’m not able to solve. I hope @CM000n could help me
I have a server (OMV) on which run Docker and Portainer. This server have only one physical network interface (enp7s0)
I have also an Unifi network with different Vlans (CORE, IOT, SEC) and the server OMV is installed on the CORE Vlan.
I would like to install HA on Docker with an access to the different Vlans by using MacVlan but I have not sufficient competences to do that. I would create different virtual interfaces with specific MACaddress and specific IPV4 (One per Vlan)
After following the approach presented above by CM000n (macvlan shim network), I had problems with asymmetric routing. Writing here to present how I fixed it, in case others encounter the same issues.
TLDR;
sudo ip route add YOUR_IP_RANGE via YOUR_GATEWAY_IP dev YOUR_PARENT_INTERFACE
Where:
YOUR_IP_RANGE → the IP range in CIDR notation containing the IP you want to target. F.x. 192.168.178.192/27 from CM000n example. In my case, this was corresponding to a
YOUR_GATEWAY_IP → the IP address of the gateway you expect the response to be provided through. So not “192.168.178.1”.
YOUR_PARENT_INTERFACE → the name of the interface you expect the response to be provided through.
More details, my concrete case:
docker network create -d macvlan -o parent=eno1.40 --subnet=192.168.40.0/24 --gateway=192.168.40.1 --ip-range=192.168.40.208/28 home_iot_macvlan
sudo ip route add 192.168.40.208/28 via 192.168.50.1 dev eno1
As can be seen, I have set a VLAN “40” for Home Assistant, the interface I expected to provide the response was “eno1” and the gateway IP of it was “192.168.50.1” (tagged in the switch with VLAN 50)
Also, I use PfSense for the routing and firewall, so inside it, I created allow rules for the traffic between HOST and the containers using macvlan.
Basically what I observed in my case was that MACVLAN container could reach the HOST, but HOST did not know how to route the response back to the container. As such, I added the above static route to instruct on how to route the packets.
With the approach presented here, even if it worked apparently, there were a lot of packets blocked in PfSense due to asymmetric routing (basically, Host → HA packets were routed locally, but HA → HOST was going through Pfsense).
Could you please describe more detailed what you’re doing here?
I would really like to use this, however I don’t really understand which IPs I would have to use in which commands in order to fit into my network (192.168.10. …).
Hello, I just generated a MACVLAN to use it with my containers.
What a MACVALN is, would go here too far to explain it. You can find more information here: Introduction to MacVLAN | dockerlabs (collabnix.com)
Somewhere in the thread should be the adaptation for other networks.
I assume 192.168.10.1 is the address of your gateway/router? So in your case it would be:
But in the meantime I don’t use that myself anymore, because I found a much easier method. Homeassistant is now running on the host network and I found a way to let Traefik (my proxy) communicate with the host network.
If you also use Traefik as proxy, you can simply pass this parameter in your yaml for Traefik.
Yes I’m using Traefik, but I’m not sure if your example helps me.
I have multiple services running behind Traefik, with Traefik exposing all services at port 80.
Home Assistant is the only container that is using network_mode: host
Now the hue emulation also needs port 80, that why I think I need a separate IP for the Home Assistant Container
I don’t think all your services and containers are running on port 80.
Traefik only receives requests through port 80/443 and forwards them to the corresponding Docker containers with their respective addresses.
For example, I have a container for Adguard Home running over the host network that also requires port 80. This runs without any problems.
But of course you can also go the Mscvlan way if it suits you better
You‘re right, in the container they run on different ports. However, Traefik exposes all services on port 80 and forwards the requests according to a subpath.
Example:
<IP>:80/grafana/…
<IP>:80/piwigo/…
<IP>:80/api/…
Now the hue emulation of homeassistant would also need port 80 and I‘m pretty sure this can only work on a separate IP.
However, I‘ve got it to work with MacVlan, but included it directly into my docker-compose file:
In the homeassistant-service:
With all these workarounds the easiest one actually is:
Join Home Assistant not only to macvlan, but to a second docker network: bridge.
This way you can address host via 172.17.0.1.
My Home Assistant instantly discovered Kodi host it was running on.
And it could reach MQTT container via 172.17.0.1:1883, although it was running with some other IP.