WOL inside Docker behind proxy (Traefik)

I’d love a button to turn on another PC (Windows 10) from inside my Docker instance of HASS running behind Traefik. So far I’ve checked:

  • Documentation of the “wake_on_lan” feature built into HASS
  • WOL configured correctly for my media server
  • Working WOL commands from my router (dd-wrt)
  • Working WOL commands (wakeonlan) from the command line of host machine (Ubuntu 18.04)
  • Nonworking “wake_on_lan” switch inside HASS
  • Nonworking “command_line” switch inside HASS

I’m very new to mostly everything I’m working on, so I’ve done a lot of digging to try and find answers, but I can’t seem to figure out how to interact with the host network without breaking ties with Traefik.

I understand that the whole point of Docker and containers is to isolate these things, but is there a way to get the wake_on_lan function working from inside Docker (behind a proxy)? If not, I seem to have the same problem with Node-Red’s node-red-node-wol palette (also contained in the compose stack), but maybe there’s a better solution there?

docker-compose.yml snippet:

version: '2'
...
  homeassistant:
    container_name: homeassistant
    image: homeassistant/home-assistant:latest
    restart: always
    volumes:
      - ${DIR}/docker/hass:/config
      - ${DIR}/docker/hass:/homeassistant/data
      - /etc/localtime:/etc/localtime:ro
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    labels:
      - traefik.enable=true
      - traefik.backend=homeassistant
      - traefik.frontend.rule=Host:homecontrol.${DOMAINNAME},ha.${DOMAINNAME}
      - traefik.docker.network=web
      - traefik.port=8123
    networks:
      - local
      - web
    depends_on:
      - mosquitto
      - zigbee2mqtt
...
networks:
  local:
    external: false
  web:
    external: true

Any help appreciated!

Please pardon my copy/paste of snippets of docker-compose files here and there to hodgepodge something together that works, but I am open to any improvements anyone would suggest to that snippet of the compose file along the way…

Your docker host has access to the computer you want to WOL? If so, the reverse proxy means nothing in this case. Your WOL packet would come directly from the host machine to the other machine.

Thanks for the response.

The host machine and the machine I want to wake are on the same home network, yes. It seems logical that it should be able to reach the local network, but I guess maybe Traefik isn’t the issue as much as the Docker structure in general combined with Traefik making the “network_mode=host” solution not an option (from what I’ve read).

Are there ports that need to be exposed or some other “networks:” setting that I need to add to let it send that command?

This is the most recent attempt at the wake_on_lan integration I have in my configuration.yaml file:

wake_on_lan:

switch:
  - platform: wake_on_lan
    name: "Media Server"
    mac_address: 'XX-XX-XX-XX-XX'
    host: '10.10.10.12'
    broadcast_address: '10.10.10.255'

This should be used on the Home Assistant docker container.

No. All ports are mapped through as needed using net=host, and subsequently, you don’t need to “open ports” to make an outbound connection, which you are doing in this instance.

I’m new to this, so thanks for your patience. I may have stumbled upon what I was looking for in my attempt to quickly find a specific explanation for why you should avoid using “network_mode: host” when running things behind Traefik. This post seems to have a good workaround for what I’m talking about.

I just tried replacing the “networks” section with “network_mode: host” in the docker-compose file (which has traefik and hass included), and it broke my Home Assistant accessibility from outside the network, though I can access it locally through localhost:8123.

I have home assistant docker running as network=host behind traefik.

I do NOT run traefik in host mode, because it isn’t needed.

image

Your reverse proxy is only for accessing Home Assistant, not Home Assistant accessing other things.

I understand that the reverse proxy is for external connections, when I changed it to “network_mode: host” it was unreachable and gave a 502 bad gateway error during my first attempt at that.

I was able to get network_mode: host working with HASS by looking through Trouble getting Traefik play nice with HA in docker (using network_mode: host), which was similar in content to that previously linked reddit thread.

Resolution:

  • Home Assistant set to network_mode: host in docker-compose.yml
  • Traefik still on proxy/local networks through the networks: section of docker-compose.yml
  • Removing all labels that I had included for Traefik in the docker-compose file for HASS
  • Including rules that I put directly in my traefik.toml file (see below)

I did successfully get WOL working now that it’s on the host network, which is awesome. I suppose my problem was mainly that I was trying to solve the WOL solution without realize the greater problem being that I had isolated my HASS install fully–despite MQTT and other features working fine.

Thank you for your input, flamingm0e!

[backends]
  [backends.homeassistant]
    [backends.homeassistant.servers]
      [backends.homeassistant.servers.homeassistant1]
        url = "http://10.10.10.XX:8123"
        weight = 0

[frontends]
  [frontends.homeassistant]
    backend = "homeassistant"
    passHostHeader = true
    [frontends.homeassistant.routes]
      [frontends.homeassistant.routes.route-homeassistant-external]
        rule = "Host:homecontrol.<yourdomain>.com"

Code modified and copied from aforementioned post.

Care to share entirely your docket-compose and traefik.toml? Please
I’m trying to do something similar but without results thanks

I can see if I can get it posted here sometime… I haven’t adjusted it in a long time, but it did break momentarily about a month ago when Traefik pushed an updated. My docker-compose was set to “latest” for the version to fetch for Traefik and they adjusted the way you should be using the TOML file and how it allows for passing frontend rules, from what I could tell. I rolled it back to alpine and it worked again.