Managing ESPHome devices across VLANs using Mikrotik Router with mDNS relay and Docker container setup behind Reverse Proxy

Managing ESPHome devices across VLANs using Mikrotik Router with mDNS relay and Docker container setup behind Reverse Proxy

After several network adjustments and optimizations, I recently faced the challenge of correctly discovering and managing ESPHome devices across different VLANs. Typically, ESPHome Device Builder and other IoT devices reside in their own VLAN for security reasons. However, this creates an issue since ESPHome relies on multicast DNS (mDNS) for device discovery, a protocol that doesn't typically travel across subnet boundaries.

Fortunately, Mikrotik routers recently implemented a simple yet powerful solution to relay mDNS packets between VLAN interfaces. By using a newly released feature from Mikrotik (available from RouterOS 7.17+), deploying and managing services such as ESPHome across multiple VLANs became simpler and cleaner.


mDNS Relay Between VLANs on Mikrotik Router

To enable mDNS relay, you can simply execute this command on Mikrotik's command-line interface:

/ip dns set allow-remote-requests=yes mdns-repeat-faces=vlan200_private,vlan100_iot servers=8.8.8.8

In this example:

  • allow-remote-requests=yes: Enables DNS queries from your network devices.
  • mdns-repeat-ifaces specifies VLAN interfaces that the mDNS traffic will be relayed between. Adjust interfaces according to your VLAN interface names.
  • You'll be able to use external DNS server (8.8.8.8 in this case).

This setting makes devices from different VLANs (such as your IoT devices in VLAN100 and your servers in VLAN200) correctly discoverable using mDNS.


ESPHome Docker Deployment and Reverse Proxy with Nginx-Proxy-Manager

I also deployed ESPHome as a Docker container for easier management and automated updates using Watchtower. Additionally, I enabled secure HTTPS access via nginx-proxy-manager configured as a Reverse Proxy, which is both secure and user-friendly. Be warned though, ESPHome requires enabling "Websockets" on nginx-proxy-manager to function correctly. Without Websockets enabled, programming and reading ESP devices through the Web UI will fail.

Docker-compose example for ESPHome and mDNS Repeater

My Docker-compose setup, stripped from sensitive information, looks similar to this:

version: '3'
services:
  esphome: #Listening on default Port 6052
    container_name: esphome
    image: ghcr.io/esphome/esphome
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: always
    privileged: true
    network_mode: host
    environment:
      - VIRTUAL_HOST=esphome.example.com #Replace with your domain

  mdns-repeater:
    image: monstrenyatko/mdns-repeater
    container_name: mdns-repeater
    restart: unless-stopped
    command: mdns-repeater-app -f SERVER_INTERFACE DOCKER_INTERFACE # Replace these network interfaces with your actual interfaces
    network_mode: host
  • ESPHome container is accessed via a domain (esphome.example.com) routed by nginx-proxy-manager. Replace it with your actual domain.
  • The additional container (mdns-repeater) will repeat mDNS broadcasts within the Docker host, ensuring ESPHome can discover devices and services. Ensure to carefully select your network interfaces specific to your Docker setup.

Important nginx-proxy-manager Setup for ESPHome

Don't forget enabling Websockets in your proxy host in nginx-proxy-manager, otherwise you’ll have connectivity issues. You must do it explicitly:

  1. Open nginx-proxy-manager web interface.
  2. Edit your configured proxy host for ESPHome.
  3. Under "Details" tab, ensure "Websockets Support" is enabled.

Advanced mDNS proxy with docker (mdns-repeater)

If your router or switch doesn't support mDNS relay reliably enough (or in addition to Mikrotik's native feature), an alternative is using the Dockerized mDNS-repeater (monstrenyatko/mdns-repeater). This lightweight container effectively forwards mDNS traffic between two interfaces on your host, very helpful for setups with multiple VLANs or complex networking schemes.

Reference: