HassOS: Multiple Network Adapter Settings

Feature Requests
1

Would it be possible for HassOS to let me specify multiple network configurations when setting up a virtual machine? What I mean is I have two subnets dedicated to wired and wireless home automation devices and I want to keep wireless devices separate from wired devices. So I have two subnets: 172.20.3.0/26 for wired devices and 17.20.3.64/26 for wireless devices (except my laptop, phone, and tablets).

And for those who do not know, HassOS can be installed in a virtual machine, such as VirtualBox or in my case, KVM as VDI can be converted to qcow2 format. Look under “Virtual Appliance.”

With that in mind, will it be possible to specify multiple network interfaces for a virtual appliance?

2

I’ve decided to revive the topic and say that Home Assistant OS can’t be configured with multiple network interfaces in mind, so those who want to use multiple interfaces such as myself must go with standard Home Assistant Core and forget about addons for good.

I would simply go with a standard Home Assistant Core as you get a lot more flexibility than running Home Assistant OS. The only problem is you have to have a hands-on experience with Linux command line, so I’d recommend going with Debian and modify /etc/network/interfaces as follows (using your favorite text editor such as vi, vim, emacs, or nano):

auto eth0
iface eth0 inet static
    address 172.20.5.4
    netmask 255.255.255.0
    gateway 172.20.5.1

auto eth1
iface eth1 inet static
    address 172.20.10.3
    netmask 255.255.255.0

You’ll only need one gateway for Home Assistant to access the Internet.

Or if you want to go with Arch Linux or CentOS with systemd-networkd, you can configure as follows:

/etc/systemd/network/eth0.network

[Match]
Name=eth0

[Network]
Address=172.20.5.4/24
DNS=172.20.16.16
Gateway=172.20.5.1

/etc/systemd/network/eth1.network

[Match]
Name=eth1

[Network]
Address=172.20.10.3/24

Or if you want to use Network Manager, you can use an ncurse-based nmtui, which is easy for most people as it’s menu-driven. As root, simply type nmtui in the terminal and you can configure your interfaces from there.

From there, I recommend installing Home Assistant Core in virtual environment. Upgrading Home Assistant Core is easy to do inside a Python virtual environment.

Do note that you won’t have access to add-ons in Home Assistant Core. Home Assistant IO and Home Assistant OS is very restrictive for Linux power users anyway. But it’s nice that add-ons such as UniFi Controller and Samba are just a click away. Would be nice to get the best of both words, though.

And why multiple network interfaces? Those of you (including myself) who setup multiple networks would benefit from having multiple interfaces that do not need to go through a router to get to another internal isolated network. For instance:

  • 172.20.0.0/27: pfSense, UniFi Controller, wireless APs, switches, etc.
  • 172.20.1.0/26: Computers, smartphones, tablets, laptops, printer, HDHomeRun, etc.
  • '172.20.5.0/30`: Home Assistant for it’s own subnet
  • 172.20.7.0/30: ISY-994i
  • 172.20.7.16/29: Konnected Alarm Panel Pro
  • 172.20.7.96/28: Other wired home automation devices
  • 172.20.23.0/24: Isolated Wireless IoT devices
  • 172.20.40.0/23: Virtual machines

Home Assistant can have it’s own IP address for each subnet. For some devices that require Internet access, you could let Home Assistant be a default gateway for the subnets and have your VM block access to other subnets as well. In this case:

  • 172.20.5.2: Home Assistant’s own subnet for allowing 172.20.1.0/26 access to the web interface; 172.20.5.1 will be a default gateway for communicating with the Internet.
  • 172.20.7.1: Home Assistant for communicating with ISY-994i
  • 172.20.7.17: Home Assistant for communicating with Konnected Alarm Panel Pro
  • 172.20.7.97: Home Assistant for other wired home automation devices
  • 172.20.20.0/24: Home Assistant for isolated IoT devices – some may need Internet access; some may not.

Does this all make sense? I made it sound a lot more complex than it actually is; however, network segmentation can be a very handy tool for keeping devices from talking to each other if one gets infected with malware. If I have a Konnected Alarm Panel Pro, I can connect them via PoE and block them from accessing the Internet. So this is something that can’t be done using Home Assistant OS.

And yes, I do keep mentioning Home Assistant because I can be a bit too lazy to type “Core.” Honestly I would rather want to call “Home Assistant” as “Home Assistant” from now on instead of mention “Home Assistant Core.” Because I can sometimes forget to type “core!” I’ve been a Home Assistant user for so many years since 0.18.

Anyway, I hope I can be of help.

3 Likes
3

then probably is not able to create multinetwork in Hass OS right?
I will use it in Rpi3 with wifi (internet connection) and ETH for wired devices.

4

This is an old post, but I came across this issue recently and found a solution.
I use HAOS.

I could use ACLs and set rules to allow routing inter-vlan traffic, but I wanted to expose HA to the other subnets so that my router has less unnecessary work to do.

Install HAOS with just the main internet facing NIC. Once installed, add the other nics.
I have a total of 3. It’s a good idea to give the MAC addresses a static lease in your DHCP server.

Then log in, go to: Settings >> System >> Network

If everything worked out, under ‘Configure Network Interfaces’ you will have your NICs.
Scroll down and you will also see ‘Network Adapter’.

The first NIC (Main) should be listed here and is what integrations will default to.

If your second NIC is 172.30.1.0/24, then traffic for 172.30.1.10 will still go over that NIC. So no worries there.

Each NIC will have a IPv4 and IPv6 dropdown. I left the first nic (Main) set to DHCP.

The other one, select IPv6 and set it as disabled. Then on the IPv4, set it to static. It should list the IP address it currently has. First, I made a static reservation in the router DHCP server to ensure I don’t hand it out. Then I put that static into the HA settings and left that as the static.

For both Gateway and DNS, it won’t accept a blank input, so put 0.0.0.0
This will stop HA from going out through those other subnets.

If you use ESPHOME, be warned that it will only auto-discover on the first (main) nic. Since integrations will default to the first nic. There may be a way to tell ESPHome to use a different nic, but I haven’t gone down that path.

So any wireless updates, etc, will not resolve unless you dig into DNS. To combat this, I set the IP address in each ESPHome device yaml code manually. Then I also give that a static lease in the DHCP server for that subnet. This may also be true for other devices on secondary or other subnets. You will have to dig a little to solve any network issues.

Then when adding an ESPHome device that is on a different subnet, you may have to head to devices / integrations, click add integration and select ESPHome. Then you will be prompted to add the IP address you set earlier. Auto-discovery doesn’t work for me and this is the way I do it.

Done.

1 Like
5

Hello,
As HAOS allows users to select which NIC integrations should use (see screenshot), it would be nice if it also:

  • allowed users to make NIC selection at the integration level (for integration A to be only local while integration B could go onlline)
  • allowed users to change which NIC is “default”. I believe for now it defaults to the one that was connected during install. Or the only one that is connected to the internet. Not sure.

Anyway, more granularity of choice would be greatly appreciated.

Screenshot from 2022-12-28 23-04-09
Screenshot from 2022-12-28 23-04-091152×676 88.6 KB

1 Like
6

sadly the one default it’sneither the first one nor the one that have internet, because in my case the one selected was added after and don have internet which is my problem.
I think it’s based on multicast.
Still it’s not normal to not being able to choose the default

Edit : Network Configuration - Home Assistant
in fact yes is documented :
Auto detection is based on the system routing next hop for the mDNS broadcast address (224.0.0.251).

If the next-hop has non-loopback, non-link-local, non-multicast addresses, auto detection will use the interface that corresponds to the next-hop (commonly referred to as the default interface).

If the next-hop cannot be detected or is a loopback address, auto detection will use all interfaces with non-loopback, non-link-local, non-multicast addresses.