It would be really great if HA supported Listen directives that allows to listen on specified interfaces/ports each either http or https.
I have used dozens of services in the last 2-3 decades and I do not remember a single one where this is not possible. HA being the first, sadly.
I was stuck so many times wih this limitation and I can come up with a myriad list of reasons why this is useful.
I know the hack of using a reverse proxy. But this is simply not elegant and adds another piece of sortware that takes resources, can fail etc.
Simple example: My HA instance has two interfaces: LAN and IOT. “LAN” interface is how people access the instance, regardless of from home or the internet. It shall always be SSL. “IOT” is a locked down VLAN without any services/access that houses IOT devices. IOT devices shall not connect via SSL.
Such a basic setup is currently straight not possible without throwing a reverse proxy at it.
A device that connects to two or more networks is per definition a router and HA is really not designed to be a router with all the complications that have.
It simply goes against what is best practice to have such a setup.
The correct way for this is to place the HA box in a DMZ and the IoT and LAN on each their own network/VLAN and then use the normal router and its firewall features to allow/disallow access.
This setup will be the most secure, but will require some mingling with broadcast and multicast domains/routing, because HA use these for discovery over SSDP, mDNS and uPNP.
The other alternative is place the HA on the IoT network and then configure the firewall to use a default drop rule on both incoming and outgoing traffic. Each protocol, host or port will then have to be opened specifically, like outgoing TCP connections on port 123 (NTP) might be open for all devices with a rule and also all devices can make outgoing TCP and UDP connections on port 53 (DNS), HA will be allowed to accept incoming TCP connections on port 8123 and so on.
This will make it possible to control IoT devices very granularly, so some devices can download their updates, like Tasmota firmware from a specific site, while Kasa smartplugs are not allowed to call home in order to avoid a firmware update that cripples the Kasa device in relation to HA.
This was not a support request but a feature request.
I am fairly familiar with networking & stuff. It is plain not true that only “routers” would have multiple network interfaces and per definition everything with >1interface is a router: Hosts can have multiple interfaces, just a few common examples: An iSCSI array, an admin (V)LAN, for KVM etc. Or a backend cluster. Or a P2P link to a hot/cold backup machine. All of these would not go over the same interface where “front end” traffic comes from.
And similarly it’s not correct that using a dedicated router is the “best practice” (it is one way). HA is pretty much the only network service that does not support this notion. Apache does not run a router (usually). Neither does an ftp server or prosody. And of course, not mosquitto. Yet all of them support it.
So, a “good practice” can be to put IoT devices (that conceptually have to talk to HA as back-end nodes, not front-end nodes) in a separate LAN that’s connected via a 2nd interface and completely isolated from the “front-end” network.
And besides, no solution solves the actual issue that I was referring to: One listening directive with SSL, one without. This needs an additional L4 software (a reverse proxy) as a hack.
To close, I am fully aware that this is neither a simple thing to implement nor originally forseen in HA architecture (which never meant to be enterprise but targeted to home LANs). Nevertheless I think such a config provides good value and hence I created the feature request.