I have moved my Home assistant from a Pine64 that was on my LAN over to my FreeNAS in a jail on a different VLAN. The problem I now have is Homekit will not discover Home assistant.
I have setup in pfsense firewall rules so the LAN can access the VLAN that Home assistant is on but homekit can still not find it. If I watch the firewall logs at the time of my Iphone homekit app trying to discover Home assistant I do not see anything been blocked.
Has anyone have a setup like this? Maybe a port I need to open on my LAN?
I don’t have any experience with your exact setup, but sometimes layer 2 network connectivity is required for certain services - meaning they are on the same subnet. I thought long and hard about segregating my home network into vlans, but decided against it to avoid headaches like this.
I tried this but had a lot of issues with certain components like LIFX bulbs that require a lot of broadcast traffic. The workarounds started becoming a pain and I moved all my Hass stuff back into the same VLAN. Most things works OK with the proper firewall rules, but some components are just a pain to get working properly and reliably.
EDIT: To clarify, I have an IoT VLAN, I just dont segregate things like Google Homes, LIFX bulbs, etc, into a seperate VLAN from Hass.
I’m not sure if you have a Mac on your network, but I use https://github.com/agg23/BonjourBroadcaster running on my Mac Pro where my Mac Pro is always on and situated on my main LAN; my HA install is on a VLAN.
I then have the following setup to basically re-broadcast HomeKit discovery.
So many different issues come up with such a mix of hardware that I have personally found running any components on different subnets just causes way too many headaches. I do not recommend it.
It is possible to have multiple tagged/untagged vlans (with different network ranges) inside the HA container. If you have several network ports/interfaces available on the host you could assign them to the HA assistant guest container/jail and configure each to its vlan (switch with vlan support is required of course).
If you only have one network interface/card/port available inside the HA container, first you will have to create virtual interfaces and tagged vlans inside this HA guest/container (I did it inside an RP3 with Hassio that only has one physical network port (VLANs with hassio)), second you set up the switch to support these vlans and separate traffic accordingly (vlans and lan) and third configure all IoT device to connect to this new vlan in the same ip range as the HA tagged vlan interface.
In order to achieve this, given the fact that most IoT device communicate through wireless, I had to create a dedicated SSID (which was then bridged to a physical port on the AP, set to the appropriate vlan and connected via cable to the switch) and configure the switch accordingly (only HA and IoT devices should share this vlan network range).
If you really are security paranoid you could make different SSID’s and vlans per groups of IoT devices (lamps, climate, etc…) so that they don’t see each other, but can use HA as a bridge/connection between them. You can then even set up firewall rules in HA to filter what can reach it. Effectively, HA is listening to IoT devices in all its network interfaces at the same time.
If what you want is to have the HA container working as a lonely member on its own ip range (as a typical DMZ server would), different than the one any IoT device belongs to, you might have lots of problems (like I did) crossing subnets, because of broadcasting issues.
It is not an easy solution (setting up multiple tagged vlans inside the HA container), but allows for a much better segmentation of traffic and so enhances security in my opinion.
If you are truly paranoid, you could have your HA host live outside your LAN (as in a DMZ) physically or virtually (if you use containers), but the IoT devices have to, in order to avoid the before mentioned broadcasting issues, live in network(s) that has/have direct (non-routed) connection to the HA host.
So the HA host would need 3 interfaces (physical or virtual) with 3 assigned IPs inside the DMZ/IoT vlan1/IoT vlan2. This way the HA host would have restricted by firewall (whatever would route traffic between networks) access to LAN and direct access to IoT devices. IoT group devices would be segregated in vlans, having only HA as a point of contact between them.
I’ve tried this and its doesn’t work properly the way you say. Even if you have inter-VLAN trunking on your switches and everything configured to communicate over GVRP/L3, some communications fail the cross the inter-VLAN connection. I tried with 5 VLANs but it always selects one as “Default” with a next to it. It only picks up mDNS traffic over that IP and binds all ports to that IP from what I can see.
I have a PowerEdge R620 40 core\256gig with a 4 port gigabit NIC setup with LACP to the switch and tagging all VLANs. It’s running HA in VMWare ESXi 7.0.3. What it looks like is I’m going to have to get all of the IP-based devices on one subnet that Home Assistant sees as “Default”. Then use the command line to add VLANs to that interface
Maybe I am not following, but the purpose of this is to segregate/segment networks to specifically avoid anything from crossing networks and interact directly with a HA ip that is in this vlan/network segment. If you want mDNS to cross VLANs, that’s not HA’s task, but the firewall’s. You can use PFsense/OPNsense for this purpose. Anything originating from HA itself will obviously take a default route/gateway, via firewall/router, if not targeting a VLAN subnet ip to which HA has a direct connection.
That’s all setup correctly on my firewall. I have a mDNS reflector on each of the subnet/VLANs. And the primary reason to segment the network is not to block HA from accessing other things, it’s to limit the broadcast traffic on the networks that matter. IoT devices constantly broadcast and can clog up your network. If you run your primary client devices on a different VLAN/subnet, you won’t have that issue.
But I digress, the main issue is the inability to choose which interface HA uses by default. Under a VMWare environment such as mine, the interfaces are randomly named and it appears that HA takes the interface with the lowest starting value. But once that been added to the VM, it’s static in the image and the mac wont change unless you manually change it. So what I’m really hoping is that the folks at HA give us the ability to put that little where we choose instead of it defaulting to whatever interface happens to be autogenerated first.
Again, why would you need to have a default gateway assigned in every virtual interface? My HA has 1 network interface not vlan’ed, plus 6 vlan’ed virtual interfaces = 7 network ips and only the “main”/default/not vlan’ed one has a default gateway assigned, so that all default traffic / not directed to specific networks goes through it. This would solve your problem, I guess.
I updated the vlans inside HA tutorial and added some more information on how to manage or disable default routing altogether on every vlan’ed additional interface inside HA container hope this helps everyone looking for a solution to that
So your saying by removing all the default gateway settings that the only one with it set goes default. Also, default gateways are not just for access to the internet. It’s where it sends traffic that is not in its subnet. So I think, unless you have all your devices on one network. You’d have routing issues
This need to be a toggle or selection inside the network control panel to tell it which to use for Internet traffic. Without having to reconfigure the docked environment by hand. And that will only work partially especially when in a VMware environment with its own vswitch and LAGd NICs
By definition, a default route is set to connect a system to any destination that is not one hop away, meaning that you do not have a network interface configured with a direct connection to that network.
The problem here is that every additional network interface that you create (VLAN or not) with a default gateway configured/set, not only wants to be a member of its own network but advertises itself to the system as a gateway to all other networks that not its own, so you get multiple exits (one per interface) configured to any one destination.
If you need specific routing, meaning internal networks that are not know to your gateway/router (or that you don’t want to access them via router, ex. a closed network non-routable internal IP camera systems), you’ll obviously need to configure these routes/accesses individually per interface.
If you have multiple network interfaces, each with a given ip/network, you don’t need to configure routing for those network, only for the non-existing in your system
That is what layer 3 of any good managed switch will do. Thats why we call them a Router-on-a-stick. You have to set your SVIs for each layer 3 device with a unique ip address on each vlan it needs access too. You then setup your route statements on your primary router like a Fortigate or Firewalla to point anything staying into the network to the SVI of the VLAN your communing with. So if my device has an ip of 192.168.10.5 and I’m using a class B your subnet mask becomes 255.255.0.0 or 192.168.0.0/16. You have your main router set that anything requesting ips in this range to the SVI of your primary distribution switch. Only other route you need is 0.0.0.0 pointed to the primary default gateway you want your internet to go out through. It also depends on how you setup your wireless infrastructure and weather you allow intra-VLAN communication. And that can be configured at multiple levels. My network is huge. Starts at Starlink, then to a Firewalla Gold. I then have the remaining 3 interfaces LAGd to my primary distribution switch which does not have clients directly attached. It’s strictly to connect to other managed switches and Aurba Canpus IAPs on my property. So in some aspects your correct but not fully. But each network can be so unique or horribly mis configured you’d have to wireshark it to see what’s really going on.
Main issue. Get a good IDS/IPS Firewall not a cheap Netgear or Linksys router, you just inviting attack. My Firewalla blocks over 2 million “door knockers” and port scanners everyday. Most people think they are safe and are so wrong. Second and I cannot stress this enough. If you’re doing a whole home or business. Dedicate a good managed switch as a distribution switch. You can hang all the unmanaged you want off of it while still keeping network cohesion.
As some back ground I’ve worked on some of the largest networks on the planet for over 25 years. In that time I’ve seen some doozies. Most “techs” don’t know networking as well as they should. Learn the ISO model and how its layers interact and it will go a long way to serve you in the future.
next to it. It only picks up mDNS traffic over that IP and binds all ports to that IP from what I can see.
hope this helps everyone looking for a solution to that 
