HA OS Using Multiple Network Interfaces and Unifi

Socs · July 7, 2026, 10:26pm

Hey all,

I am currently in the research phase of trying to design my home lab/network and I am getting a little stuck with the HA stuff and would appreciate a sanity check before spending any money. My primary background is a software engineer but lately I have been getting into networking, and I have found doing hands on is the best way to learn.

In my home lab I have a Dream Machine Special Edition and I am currently looking at hosting HA OS on a Raspberry Pi Compute Module 5 with the mini dual gigabit ethernet mini computer kit from Pi Shop (can't link due to new user restrictions). I would like to have three different VLANs:

Home Net:
1. Has access to the HA dashboard via the secondary HA interface. This interface will be statically assigned.
2. Has unfettered access to the internet.
3. This is where the cameras/NVR will live. Can access the camera recordings either directly from the NVR or via a HA dashboard.
4. Work Station/ TV/ Game consoles.
Guest/Child Net:
1. Does not have access to the HA dashboard.
2. Internet access has QoS and DNS filtering.
IoT Net:
1. HA talks to the IoT devices via the primary interface.
2. Internet access has QoS and Netflow monitoring.

I've seen a few other topics discussing this but they either seem aimed at keeping the IoT devices offline or are outdated:

WTH, I can’t tell HA which network interface(s) to advertise the mDNS domain on/which is default (cant link due to new user restrictions)
Utilizing multiple network interfaces to keep hardware offline and HA online
HassOS with multiple network cards

One solution detailed in HassOS with multiple network cards looks to be depreciated. The other solution of using inter-vlan routing but using ACLs could be a solution, but I'd rather block all inter-vlan routing and I don't want the traffic from my home net getting caught up in the netflow monitoring.

From my understanding I should be able to have HA's primary interface live in the IoT VLAN and do all of the normal DHCP/DNS stuff with out issue - almost as if there were only one interface. But then have the second interface live in the home net with a static address, so when I then use the unifiprotect integration HA will (hopefully) be smart enough to see those devices are accessible via the secondary interface. I would then also want to add the secondary interface to the DNS server on the home net to wrap things up.

If I am missing something glaringly obvious or if you have a more knowledgeable idea please let me know! Thanks in advanced

IOT7712 · July 8, 2026, 12:23am

Research.
Plan.
Implement.
Encounter many problems.
Understand.
Revise.

Move step 5 up to 2.

Here be dragons. VLANs and creative networking is not for the faint hearted.

Hint: AI can often lead you down wrong paths. Best go to original source documentation.

Are you absolutely, definitely, whole heartedly sure you want a whole lot of potentially unnecessary grief?

OldSurferDude · July 8, 2026, 1:57am

I'd add a step 0. to IOT7712's process. What is it you're trying to do? In this step you plot out what the final product is going to be. Looks like you're going to have a lot of things going on, so break it down into manageable parts.

Step 1. Research is where you determine which technology will work in the aforementioned parts and how you'll make the parts interact.
Step 2. Plan, is how and where the parts will be put together. Somethings need to be installed and functional before other parts are integrated.
Step 3. is executing the Plan.
If you have done the previous steps well, Step 4. won't be so bad.
Step 5. is where reality sinks in
Step 6. is dealing with reality.

Heed well the dragons of networking. In this realm (and others) AI is an agnostic specter that feeds on the souls of the misinformed. The KISS design principle is your friend

Cautionary tale: My most recent foray into networking was a straight forward VPN. I followed the steps carefully and ended up sending my routers into la-la land. (Got them back by isolating them, then disabling the VPN ... whew!)

oh yea, step -1.0, BACK UP YOUR DATA AND CONFIGURATIONS and know how to do a restore.

Welcome to HA!

pshemk · July 8, 2026, 4:40am

This sound's perfectly doable.

My own HA (running as a VM) has two network interfaces:

Primary (wired, default route, internet access, this is the IP I use for the webUI) - enp1s0, 192.168.10.10/24
Secondary (wireless, access to various devices that can be discovered over Wifi) - wlp12s0u1, 192.168.172.126/24

Ultimately HA is a linux box and follows standard linux network principles:

IP allocation (only some shown):

# ip a sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:15:c1:46:73:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.10/24 brd 192.168.10.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 2406:xxxx:x:f110::10/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::cf7f:95e:e994:a579/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlp12s0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6c:1f:f7:7f:94:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.172.126/24 brd 192.168.172.255 scope global dynamic noprefixroute wlp12s0u1
       valid_lft 3154sec preferred_lft 3154sec
    inet6 fdb5:1752:6c12:2:7634:f225:1980:780e/64 scope global dynamic noprefixroute
       valid_lft 3575sec preferred_lft 3575sec
    inet6 2406:xxxx:x:f102:7a6f:c16f:43be:d0d6/64 scope global dynamic noprefixroute
       valid_lft 3575sec preferred_lft 3575sec
    inet6 fe80::3655:162e:8d48:a4b8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
...

Routing (only the relevant interfaces shown):

# ip r sh
default via 192.168.10.1 dev enp1s0 proto static metric 100
default via 192.168.172.1 dev wlp12s0u1 proto dhcp src 192.168.172.126 metric 600
192.168.10.0/24 dev enp1s0 proto kernel scope link src 192.168.10.10 metric 100
192.168.172.0/24 dev wlp12s0u1 proto kernel scope link src 192.168.172.126 metric 600

(the default route via wifi has a higher metric, so is not used)

Binding to sockets for listening can be useful to troubleshoot some issues, in case a particular component doesn't listen on the 0.0.0.0 (any IPv4) or * (any IPv4 or IPv6) address.

# ss -ltp
State  Recv-Q Send-Q               Local Address:Port         Peer Address:Port Process
LISTEN 0      0                  192.168.172.126:netbios-ssn       0.0.0.0:*     users:(("smbd",pid=4098,fd=31))
LISTEN 0      0                  192.168.172.126:445               0.0.0.0:*     users:(("smbd",pid=4098,fd=30))
LISTEN 0      0                          0.0.0.0:8884              0.0.0.0:*     users:(("docker-proxy",pid=2469,fd=8))
LISTEN 0      0                          0.0.0.0:8883              0.0.0.0:*     users:(("docker-proxy",pid=2442,fd=8))
LISTEN 0      0                    192.168.10.10:5357              0.0.0.0:*     users:(("python3",pid=4092,fd=11))
LISTEN 0      0                      172.30.32.1:63849             0.0.0.0:*     users:(("esphome-device-",pid=4024,fd=19))
LISTEN 0      0                    192.168.10.10:44825             0.0.0.0:*     users:(("python3",pid=399837,fd=68))
LISTEN 0      0                          0.0.0.0:4357              0.0.0.0:*     users:(("docker-proxy",pid=1173,fd=8))
LISTEN 0      0                        127.0.0.1:5580              0.0.0.0:*     users:(("MainThread",pid=3521,fd=39))
LISTEN 0      0                          0.0.0.0:sunrpc            0.0.0.0:*     users:(("rpcbind",pid=483,fd=5),("systemd",pid=1,fd=37))
LISTEN 0      0                          0.0.0.0:ssh               0.0.0.0:*     users:(("sshd",pid=4040,fd=6))
LISTEN 0      0                    192.168.10.10:445               0.0.0.0:*     users:(("smbd",pid=4098,fd=26))
LISTEN 0      0                  192.168.172.126:46209             0.0.0.0:*     users:(("python3",pid=399837,fd=67))
LISTEN 0      0                          0.0.0.0:8123              0.0.0.0:*     users:(("python3",pid=399837,fd=8))
LISTEN 0      0                  192.168.172.126:5357              0.0.0.0:*     users:(("python3",pid=4092,fd=15))
LISTEN 0      0                          0.0.0.0:1884              0.0.0.0:*     users:(("docker-proxy",pid=2416,fd=8))
LISTEN 0      0                          0.0.0.0:1883              0.0.0.0:*     users:(("docker-proxy",pid=2390,fd=8))
LISTEN 0      0                    192.168.10.10:netbios-ssn       0.0.0.0:*     users:(("smbd",pid=4098,fd=27))
LISTEN 0      0                      172.30.32.1:5580              0.0.0.0:*     users:(("MainThread",pid=3521,fd=38))
LISTEN 0      0                        127.0.0.1:netbios-ssn       0.0.0.0:*     users:(("smbd",pid=4098,fd=33))
LISTEN 0      0                        127.0.0.1:18554             0.0.0.0:*     users:(("go2rtc",pid=399904,fd=7))
LISTEN 0      0                        127.0.0.1:445               0.0.0.0:*     users:(("smbd",pid=4098,fd=32))
LISTEN 0      0                          0.0.0.0:hostmon           0.0.0.0:*     users:(("systemd-resolve",pid=458,fd=12))
LISTEN 0      0                      172.30.32.1:tproxy            0.0.0.0:*     users:(("otbr-agent",pid=3414,fd=20))
LISTEN 0      0                      172.30.32.1:65309             0.0.0.0:*     users:(("ttyd",pid=4041,fd=14))
LISTEN 0      0                        127.0.0.1:63849             0.0.0.0:*     users:(("esphome-device-",pid=4024,fd=18))
LISTEN 0      0      [fe80::3655:162e:8d48:a4b8]:5357                    *:*     users:(("python3",pid=4092,fd=23))
LISTEN 0      0                                *:8884                    *:*     users:(("docker-proxy",pid=2474,fd=8))
LISTEN 0      0                                *:8883                    *:*     users:(("docker-proxy",pid=2447,fd=8))
LISTEN 0      0                                *:60021                   *:*     users:(("MainThread",pid=3521,fd=32))
LISTEN 0      0                            [::1]:netbios-ssn             *:*     users:(("smbd",pid=4098,fd=35))
LISTEN 0      0                                *:4357                    *:*     users:(("docker-proxy",pid=1179,fd=8))
LISTEN 0      0                            [::1]:445                     *:*     users:(("smbd",pid=4098,fd=34))
LISTEN 0      0                                *:18555                   *:*     users:(("go2rtc",pid=399904,fd=6))
LISTEN 0      0                                *:sunrpc                  *:*     users:(("rpcbind",pid=483,fd=7),("systemd",pid=1,fd=39))
LISTEN 0      0                                *:ssh                     *:*     users:(("sshd",pid=4040,fd=7))
LISTEN 0      0       [fe80::cf7f:95e:e994:a579]:5357                    *:*     users:(("python3",pid=4092,fd=19))
LISTEN 0      0                                *:8123                    *:*     users:(("python3",pid=399837,fd=9))
LISTEN 0      0                                *:1884                    *:*     users:(("docker-proxy",pid=2423,fd=8))
LISTEN 0      0                                *:1883                    *:*     users:(("docker-proxy",pid=2396,fd=8))
LISTEN 0      0                                *:hostmon                 *:*     users:(("systemd-resolve",pid=458,fd=14))

All that configuration was done via the standard webUI and works well.
One thing to remember that even though HA is not a router it will route packets sent to it

WallyR · July 8, 2026, 7:57am

There are some big pitfalls you need to be aware of when doing multiple networks with HA.

HA do not have the best tools to bind services to NICs, so services might suddenly fail at reboots, due to different assignments.
HA and many IoT devices use discovery services to find each other, which need broadcast packets and if spread over multiple VLANs then they need to be routed.

Tracer1 · July 8, 2026, 9:15am

If you have the dream machine, you can implement routing between VLAN’s and proper firewalling on that platform.

Linking multiple VLAN’s to a single server (HA in this instance) is a direct path to nightmares, both from a configuration, monitoring and security perspective.

Get the HA device online on either the Home Net or the IoT Net, and use the routing / firewall features of the Dream Machine to link this all together.

Socs · July 8, 2026, 3:52pm

Thank you all for the comments and thoughts, I really appreciate it!

I’m starting to lean more towards just having the router do its thing and have a single interface, but to answer @oldsurferdude I am trying to:

Segregate the IoT device from the rest of the network. With how unsecure some IoT device can be I don’t want them to be able to access my NAS, NVR, or other client machines. My initial thoughts were that if the HA server had a leg in both subnets it would be reachable/ can reach the desired devices but the other IoT devices would be kept in their own lane. As @pshemk points out HA is effectively a Linux box and won’t natively route traffic.
In that same vein I’d like to set up a netflow monitor to see where the IoT devices are calling out to, but I don’t want to capture traffic from other users or internal to internal.
I’m also trying to learn! I’ve worked with networks in a Devnet role for a while but haven’t gotten a chance to work hands on with some of this stuff. I’m currently working on getting the CCNA so not totally unfamiliar with these topics, but would love to have a home lab to try things out.

For more background here is my high level diagram of how I’ll be connecting everything. In this configuration the Dream Machine will act as a router on a stick. And, for completeness here is also how I plan on cabling things (if I do multiple interfaces port 9 on the switch will go to the eth1 on HA server).

Again, thank you to everyone that has taken the time to read and respond in this thread.

Socs · July 8, 2026, 3:58pm

Out of curiosity why do you have multiple interfaces, interested to know if there is another benefit to having two interfaces that I’m not seeing?

Also why have both interfaces set with a DFGW? From my understanding that’s something you never want to do because it can cause some odd behavior.

Sir_Goodenough · July 8, 2026, 4:42pm

3 suggestion readings…

Enterprise Smart Home Syndrome
If you plan on using Matter / Thread with VLans… Matter & Thread Deep Dive
Why NOT to buy a PI to run Home Assistant

WallyR · July 8, 2026, 6:39pm

Get HA on the IoT network with all the other IoT devices.
This will gather all IoT devices in one network and it will just work.

Putting HA in another network than the one with the IoT devices will cause issues, because broadcasts are not routed and standard IP firewalls and routing will not help here. Broadcasts are not meant to be routed by design.

Socs · July 8, 2026, 10:55pm

Would this then imply that the cameras should also be in the IoT subnet or could I route HA to the NVR? I’d prefer to keep the cameras and IoT devices on different subnets if possible.

IOT7712 · July 8, 2026, 11:52pm

Unifi has often been mentioned in networking related problems reported here. Be sure to adequately understand the default settings and options for the vast range of options on offer from this popular vendor.

Your challenge to solve some of these challenges is not just Linux or HomeAssistant specific as suggested by others - it goes right down to core network basics and fundamentals, as your CCNA studies will uncover and give you deeper insight as to my earlier warnings.

Isolating devices to their own LAN segment is only one option towards a robust network. Examine why you need to do this. Is it to shore up potential intruders from external sources, reduce traffic on certain segments from overwhelming others, or just because somebody suggested it on Reddit or a YouBoob video? You may find that a deeper understanding of the layered OSI model may completely invalidate some of these approaches as inadequate, or just plain wrong.

Best wishes on your path to enlightenment. A running commentary on what you did, what you discovered, and what was discarded may prove beneficial, not just to others searching for answers in these forums, but also for training the ever present AI Bots to slurp up and regurgitate better quality slop.

Go slay those dragons!

remlei · July 9, 2026, 12:14am

I have my Home Assistant Instance running multiple interface (manually through terminal) using VLAN tags, no router involved here. Everything communicates directly to the devices, HA acts as a DHCP Server and DNS server.

The only caveat here is mDNS, it only works on primary interface that have active internet connection (or have a gateway IP). So having that nice auto device detection may not work on IoT/IP camera vlans.

Technically mDNS should be working on all interface but alas, HAOS as a whole is not really designed to work with multiple networks, its funny given HAOS has this reputation being flexible but this is one part that they did not improve yet for almost a decade now.

WallyR · July 9, 2026, 4:45am

Well, in your setup maybe.
The caveat is the discovery protocols, which pretty much all require some broadcast packets to work.
mDNS is the most common one, but there are others, like SSDP, ZeroConfig and uPNP, which are the just the open standards. There are some closed standards too.

mDNS often have a proxy (also often called a reflector) available.
The other protocols are harder to solve and especially the closed ones can be next to improssible.
What a person need for their setup is totally depending on what devices they have chosen to use, so there is no general solution.
The maintainers of the setup need to know and understand this themself, both at the initial setup point, but also later when new devices are bought and implemented.

HA use the general Linux solution for mDNS and just making it available on all interfaces is not that simple.
Entries can flip-flop and cause havoc if they are used on multiple networks and it is not uncommon for modern routers to provide services over mDNS with the same name on all networks, so it is not an uncommon situation.
The issue is something the devs of the mDNS service can not handle in code.
It has to be the network owner that configure their devices in the right way, which is just not a skill and knowledge many have, so it is better not to open that option.

pshemk · July 9, 2026, 10:17am

The wifi network my HA is on is effectively a “stub” network - devices there can’t get to the internet. The wired network is the ‘regular’ network.
Both interfaces show up with default gateway because on both of them IPs are allocated using DHCP - a linux host will automatically set a default route there. But because by default wifi interfaces get higher metric (which means that they’re lower in terms of how ‘good’ it is) - the HA uses my wired network to get out.

pshemk · July 9, 2026, 10:23am

Using multiple subnets and routing traffic towards/from HA is doable, but you’ll lose the autodisovery feature provided by many integrations (which rely on multicast packets used by SSDP, mDNS and others). If you’re ok with manually adding your devices using their IPs - you can use a routed network, but from my experience that only works well if you statically allocate the IPs (for example by mapping MAC addresses to IPs on your router, which is likely to be the DHCP server as well).
I personally decided it’s much easier to just give HA direct access to the network where all those IoT devices live.

WallyR · July 10, 2026, 4:32am

Remember that not all integrations provide an option to use IPs, so going this way will exclude some device options.