Redoing home network: how to prepare openHAB and what to update afterwards

Setup, Configuration and Use Migration
1

Hey guys,

I have been using openHAB for several years now, and love it! I have also received a lot of help from you all on here over that time. I really appreciate it.

Currently, my home Wi-Fi net work is fairly simple using the cable companies router. I am getting ready to upgrade to my own router with a PF Sense firewall to take advantage of VLANs, firewall rules, etc. With that, I will be changing my 192.168.1.X addresses to something different. Probably 10.something (haven’t fully figured out what the new IP subnet will be).

Anyway, I want to get ahead of things and make sure that this goes smoothly specifically with openHAB.

I am running OH3 on a Linux virtual machine and installed it via openHABian. I do have some devices that are connected to openHAB and are on Wi-Fi like my Philips Hue lights. But the majority of my devices are connected via Z wave.

I am well aware that I will have to update any IP addresses that are related to any wifi items that are in openHAB.

I have a few questions:

  1. Can y’all help me with what config files I would need to change in the virtual machine itself related to openHAB? If any of y’all have done this before and ran into some snags, please post any of your favorite tips below.
  2. As stated above, I have a fair amount of Z wave devices. If there’s anything special I need to do before or after migration, please advise.
  3. Lastly, any general tips are appreciated!

Thanks!
JM

2

If it’s not too late I strongly recommend OPNsense instead. I ran PFSense for a number of years and their support and the quality of the product gradually got worse and worse. What finally forced me to leave them was when they basically announced that they were doing nothing more with the community FOSS version. All new features would only be released to paying subscribers. But that was before I learned about the shenanigans they got up to when OPNsense forked.

Netgate is pretty hostile on their forum and support and as a company have done some pretty awful things. Even if PFsense were superior (one could argue either way), as a matter of principal I personally want nothing to do with Netgate. (e.g. OPNsense.com - OPNsense® is a true open source firewall and more). But in my experience, OPNsense looks better, is easier to use and understand for someone who isn’t a network engineer and BSD expert, and for the packages I care about (e.g. HAProxy) are kept up to date much better.

Not necessarily. You can (and should) assign static IP addresses to each device in your firewall. Capture the IPs your devices are using now and you can pin those devices to the same IP when you set up the new network.

If you do decide to change the IP addresses, you should still pin them so they don’t change unexpectedly. This also can give you flexibility later (e.g. set different firewall rules or DNS rules (OPNSense has AdGuard support) on a per device basis).

You don’t need to pin all of them. You can set up a pool of dynamically assigned addresses for those devices you don’t care about (e.g. laptops) and only assign an IP to those devices you need to access via IP from OH (or elsewhere).

If your end devices keep the same IPs, nothing needs to change. If not, you’ll have to modify the IP addresses in the Things that represent those devices in OH.

Nothing needs to be done here. Zwave is completely independent of WiFi.

Just like with OH, start slowly and get the basics working first. Then gradually add features as needed. Many of the tutorials you find about PFSense will also apply to OPNSense. And be careful if you plan on running this on a VM.

I got into trouble because I underprovisioned my PFSense VM on my ESXi server. But, when I shut it down to increase the RAM my entire network stopped working. :scream: I couldn’t even access ESXi to start the VM again because it needs the networking to access it. Luckily I was able to restart the physical box and the VM was configured to boot on start. So pay close attention to what depends on what.

I’ve since moved the firewall to it’s own passively cooled machine with an independent UPS and a serial connection I can use access and troubleshoot when all else fails.

1 Like
3

Just wondered what the rationale is for changing your local IP Range? You could save yourself a fair bit of work by just keeping it the same and ensuring that the addresses used for static devices (openHAB, controllers etc) are reserved in DHCP (or outside Address Pool/Scope) on your new router

1 Like
4

I had this same question and would also advise to leave the IPs as they are to remove a pain point.

1 Like
5

I knew it would come with some extra works but my plan all along was to change it. Right now the devices on my network are at random IPs and I think I will end up changing them all anyway even if I keep the same 192.168.1.XXX subnet so that I can group similar devices together and leave room for dynamically issued address. e.g. cameras are addresses 1-15 servers are addresses 16-30, etc.

The openHAB VM will be part of that change as well as all other wifi devices connected with OH.

That’s a very good point. Hope that answers your question.

6

My brother owns an IT firm which services small businesses in the area and will be leaning on him for the initial set up but want to learn from him along the way. I will look into that with him. Thank you!

Yep. This is the plan. I want to reserve an IP block each for cameras, servers, etc. and then leave a large pool open to by dynamically assigned.

Understood. Thanks.

That’s what I thought but always good to confirm because Z-wave can be a PITA! :sweat_smile:

Ooof! I bet that was a panic moment! Locked your keys in your car in a sense. Smart thinking on the reboot.

Thankfully this will be its own bare metal machine that lives on its own by my switch and internet gateway on a UPS. I’ve lived with a firewall that wasn’t independent and it comes with several challenges like you have described.

Thank you for taking the time to write such a detailed response!

7

One thing I’ll add: if you have any securely included devices (e.g. a door lock) and start a fresh openHAB installation, make sure to copy the Network Security Key from your old system. You can find it in the thing for the Z-Wave controller. You need to paste it into the new system, or else your secure devices won’t connect.

If you don’t have any secure devices, you can just let openHAB generate a new key.

@rlkoshak, since you work in cyber security and this seems like a good time to ask: do you have any general concerns about the security of ISP-provided routers?

I’m inclined to think that ISP routers aren’t automatically “bad”, since millions of people are using them without getting compromised (as far as anyone knows), but expect that some ISPs are better about upgrading firmware than others. The ISPs have a vested interest in ensuring their devices are secure.

I recently played around with OpenWRT, but quickly determined that I’m not interested enough to dig deeply into it, and it’s not something that can be done half-heartedly. If people think the openHAB community is technical, then the OpenWRT forum is another level. So, I’m trying to find the right balance between “don’t get breached” and “don’t spend more time than I have to” (both for myself and for others).

Maybe a better way to phrase this is: what’s the minimum recommendation that you would make for a home network from a security standpoint?

8

I have opinions but they are only slightly more informed than the average public on this specific topic. Most of my active work is niche and most of the generic stuff I mention here on the forum comes from my degree (MS Security Engineering), personal experience at home, and keeping an eye on the computer security press and academic publications.

In general you are correct, the routers are not automatically bad. And they come with the advantage that your ISP can usually reach into them and fix things that are broken. But that also means your ISP can reach into your router and do anything else they want to too, like get a map of all your devices and services, enable/disable features without asking, etc. YMMV depending on the ISP in question.

In general, I recommend treating any hardware provided by the ISP as “outside your network”. Put your own device, even if it’s just an off the shelf WiFi router, even if it duplicates capabilities provided by the ISP’s device, between the ISP hardware and your LAN. It’s a little more expensive but provides some protection in case the ISP router is compromised or your ISP likes to snoop.

Internet <--> ISP Router <--> Your Own Gateway <--> LAN

In my case the “Your Own Gateway” is the OPNsense box and my WiFi routers are set to just AP mode so all the network stuff (DNS, DHCP, etc.) is implemented by the OPNsense box.

Internet <--> Cable Modem <--> OPNsense <--> WiFi AP Mesh Network <--> LAN

I started with OpenWRT but moved to PFsense because OpenWRT is way low level and primitive in comparison and I didn’t want to work that hard to implement parental controls. Updates for individual gateways is hit and miss as well.

It might be worth spinning up an OPNsense VM and playing around if you still have some needs beyond what your ISP can provide. Even out of the box you can get some nice monitoring and protection on your network with very little effort and it’s way more user friendly compared to OpenWRT, Tomato, and all the other alternative firmware.

Treat any hardware you don’t “own” as the Internet. If the ISP can log into it, you don’t own it. Note often cable modems end up running firmware pushed by the ISP even if you bought it in which case you don’t own it. Even though I bought it myself, you’ll notice in the diagram above that the Cable Model is on the other side of my OPNsense. There are technical reasons for doing that too (it’s hard to buy an off the shelf machine capable of running OPNsense that also includes a cable modem) but even were it not so I’d put it outside the LAN rather than on the gateway because of that ISP pushed firmware. So put some sort of controlled interface between it and your LAN.

Don’t do NAT. Use a VPN instead. Tailscale is super simple to set up (supported on both PFsense and OPNsense BTW).

The general advice is to put all your IoT devices into their own VLAN. I’m ambivalent on this. On-the-one-hand it’s recommended for good reason. Many vendors are super insecure or bad actors. Putting that stuff into it’s own VLAN protects your “data” LAN from attack. However, it greatly increases the complexity of the network setup and OH setup too and it can often be far beyond the average user. If you don’t do VLANS, be sure to be vigilant and monitor the network and carefully research devices before buying them to see if the vendor has a good reputation.

3 Likes
9

Thanks, as always, for the thoughtful answer! My provider (Telus in Canada) hasn’t given me reason to think they’re sketchy in the decade I’ve been with them (plus two more decades at my parents’ house), so I’m not too concerned, but OPNsense sounds interesting.

I’m with you on this due to the complexity of VLANs. If I was concerned about TP-Link, I’d block the Internet access for my Kasa devices. Realistically, I think that most (not all) tech companies grasp that any benefits from intentionally compromising their customers’ security are not worth the huge risks to their reputations and livelihood.

10

The problems are not always intentional. Sometimes it’s just laziness and bad security practices. Some IP cameras are an example. They are not trying to attack you, but they certainly are not going out of their way to prevent their stuff from being compromised to attack you by others.

11

This discussion is very informative! I am learning a lot.

That’s a good point. I have a few Hikvision cameras and immediately blocked them from accessing the internet via my ISP router.

12

I recently went through a similar process - replacing my router and splitting my network into LAN, Guest, and IOT networks. My lessons learned were:

Save the UID from the Serial Controller’s Thing (e.g. “zwave:serial_zstick:39d51d11b2”) in addition saving the security key. If you use the same UID when your recreate the Thing you don’t have to recreate the items.

It was helpful for me to have a spreadsheet of each network device’s host name, mac address, and IP address before I began the transition.

Although it may be extra work at the beginning I recommend configuring all of the network devices that need fixed IP addresses (e.g. servers, IOT devices, etc.) to use DHCP reservations, not static IPs. Devices configured using DHCP reservations while you are on the “old” router allows moving the devices to new networks/IP addresses just by entering the DHCP reservations in the new router instead of needing to log into each device to change each device’s IP address. I added another column containing the new IP address that I wanted assigned to each device to the spreadsheet, which was helpful when keying the DHCP reservations.

I would leave all of the devices on the same network when I installed the new router, whether or not network is in the new 10.x.x.x subnet instead of 192.168.x.x. Verify everything is working as expected for a week or two before moving devices to the IOT & Guest networks. Once you are confident that everything is working properly on the new router splitting some devices onto a new network is “just” a matter of updating the DHCP reservations of those devices and adding firewall rules.

Finally, make sure you have a good backup of the router’s configuration before attempting to implement the VLANs so that you can easily fall back if things don’t go as expected.

HTH,
Jim

1 Like
13

I perceive this as intentional behaviour. Belkin took a year to patch an exploit in their Wemo firmware.

14

Good clarification, as these terms often get tossed around interchangeably. I always use DCHP reservations.

15

Thank you for the thorough response. Why did you have to recreate all of your Z-wave Controller’s Things?

Just went and made that last night!

16

I needed to recreate all of the things because I was a noob and didn’t realize I wouldn’t need to recreate the things if I set the correct value when recreating the controller :slight_smile:

17

Recreating the controller? Did you wipe your openHAB instance and start over? All my Things should stay the same - I just need to change any hardcoded IPs in the respective WIFI Things’ settings.

18

Yes, I was moving OpenHab to new hardware and since most of my configuration is in text files it was easy to start with a clean installation. For Z-wave I use the UI to create the Things, but use a text file for the Item definitions.