I have two openHAB installations that are 1,500 miles apart. I was able to use the Remote Binding to let them communicate with each other. But at least the way I did it, it required me to open and forward port 8443 on my modem, which I didn’t think was a very good idea, and this recent post Thousands of OH installations accessible from everywhere seems to confirm it. And so I have removed the port forwarding from my modem, but would like to find a way for my installations to talk to each other securely.
I have Wireguard VPN set up on both of them, and that works great for remotely access them. I used PiVPN to load Wireguard before OpenHABian added it. I also tried setting up the NGINX reverse proxy, which works fine, but I think I will stick with the VPN. And I also use openHAB Cloud. But I don’t see how I can use any of these approaches to use the Remote Binding to let them communicate.
I may be wrong, but I don’t think I want to combine both networks and have all of their traffic going across the Internet. At both locations there is only one network. I have seen it suggested that it is better to have all IoT stuff on a separate network or subnet, but I think the lines aren’t that bright between IoT and other stuff. Some devices (openHab Things) are controlled through the network, but also stream through the same network.
But I could be wrong. I’m open to trying different approaches.
The way to connect 2 devices safely over an untrusted network IS by using a VPN. Wireguard gives you an interface on both sides and you simply route whatever you want over that tunnel.
The safest type of service is one that isn’t available at all on the internet, so if you have the option of just tunneling everything you need over WG (or any other VPN tunnel for that matter) and not have anything else exposed, then that’s definitely the recommended option.
Not that this needs to turn into an advertisement for wireguard, but it will allow you have multiple tunnels and therefore interfaces. So you could use your home firewall to connect either directly to the device on the other side or the firewall on the other side as well as having your personal device(s) create separate tunnels when you’re not at home.
You could use anything else (OpenVPN, tailscale, tinc, IPsec) but if you have wireguard running, stick to that.
@BigGeorgeTx since your installations are pretty far from each other I doubt if they have anything in common. Why you try to get remote connection between these?
Some services that I use both places that are used by some bindings get cranky if they are polled too frequently, and having two different instances polling doubles the load and increases the risk they will time out.
I want them to have a health check on each other, so that I can tell or be notified when one system is down.
There may be better ways to address each of those issues, but the Remote openHAB Binding seems to open the door for both of them.
Thanks @pacive . This looks like the solution I had in mind.
After skimming it and playing Duck Duck Go with it, the lightbulb moment for me was that all Wireguard connections are peer-to-peer, so I just need to add the configuration for one more peer on each machine, with the new peer being the other machine. I already have the port open and forwarded for Wireguard that I use with my laptop, tablet or phone.
I will study the DigitalOcean How To and my existing Wireguard configuration and see if I can figure out how to add the new connection.
I will turn this into an advertisement for Tailscale. It is a network overlay on top of wireguard and it’s super simple to set up and use. If setting up wireguard or any other VPN system on your own feels daunting, I recommend giving them a look. And it works without opening any ports on the firewall.
One “thinking outside the box” solution could be to use MQTT with a cloud MQTT provider (e.g. CloudMQTT). Using the MQTT EventBus you could link the two instances over the internet without opening any ports and messing with VPN.
You’ve already got Wireguard going so definitely go with that as it offers other benefits but I wanted to mention this option for future readers.
If you have myopenHAB cloud setup for your remote server, I believe you just have to use your myopenHAB URL (and HTTPS) when setting up your thing for the remote openHAB binding. This is the easiest way which is secured too.
The myopenhab.org approach though gets a bit more complicated because there might be two layers of authentication to get through. First authentication with the myopenhab.org service and second authentication with the openHAB REST API itself.
I tried to help someone do some REST requests through myopenhab.org and we got stuck on that part. Though the Remote openHAB add-on has more ability to handle that than curl does.
Thanks. I missed that option, which sounds very simple. Though adding a peer to Wireguard looks like it won’t be too difficult. I may try both and report back.
Thank you for this! I previously had port 443 forwarded to my OH server (protected by client cert auth through nginx), and also port 500 open for L2TP/IPSec on my router for when needing ssh access etc. After reading up on Tailscale however, I decided to go with that instead and close down all ports. Will keep the IPSec open a while longer until I have tested it thoroughly, but initial tests seem promising!
I’d say that main thing of tailscale is orchestration they built on top of wireguard. Normal wireguard requires you to keep configs and forwarding rules in sync. It is manageable for semi static setups. You can route VPN traffic through one coordinator node.
The NAT hole punching which tailscale do can be avoided with wireguard tunneled over TCP. It does limit its maximum speed, but that’s in practice what I had to do in order to get wireguard working with installations I have beside cellular network.
Well its prime benefit is to ease setup and maintenance to an extent that you don’t even have to care about IP addressing or firewalling.
Which is even more beneficial to people that “just” want to run OH and don’t know how to handle all of that themselves. It is even comfortable for those who do, and it avoids human errors in doing so.
And just on a sidenote, it can do a lot more like routing control, DNS and centralized user specific VPN wide filtering. That latter I like a lot.
FWIW, tailscale can be installed from openHABian menu.
?? at the cost of some statically exposed port and the need to configure forwarding
I wouldn’t know how to overcome any firewall without some entry hook, and these are prime targets for the bad guys out there.
And the ‘hole punching’ is just to open the wireguard-protected channel.
If you’ll have a closer look on what tailscale does - they do TCP as well, cause this is most reliable way for clients to establish initial connection to their server. You can’t rely on UDP as first touch in multiple cases cause it will fail due to multiple reasons (hence whole hole punching idea).
I don’t get whole mysticism of why opening a port on an VPN server is a danger. This is what servers were made for. It is important for clients to stay hidden. With TCP it works even without hole punching.
Well … my understanding is that the “hole punching” (which you seem to consider something insecure and bad per se ?) is only temporary and an additional layer just needed to establish the wireguard-protected channel.
I don’t want to turn this into some sophisticated security discussion but the thing is without this layer, the port on the VPN server is a visible entry hook.
Yes clients should be hidden but (also) hiding the VPN server (router) is even better.
Note my assumption in the most common setup with wireguard VPN server = VPN router (tunnel endpoint, port usually forwarded on firewall which BTW also is hole punching) while with Tailscale, there’s an external VPN server (not a tunnel endpoint) for the initial preparations like key exchange and tunnel creation.
If you run any such peer-2-peer setup in the wild and have an IPS then you will notice many attack attempts on ports 59000 (wireguard) or 500 (IPsec) (port numbers are from memory, too lazy to lookup).
And the main looming danger is the admin user.
In our home automation context it’s often amateurs to configure the VPN server/router, doing all sorts of amateur errors like keeping default passwords or demo certs or fully expose the server IP.
Plus it’s a lot to configure, lots of room for errors, plus human mistakes are common, even for pros.
All of this Tailscale protects you from simply because a) it does most stuff automatically and b) there is no amateur-operated entry point for attacks.
I can add that I took the very big risk of switching a remote machine (over 100 miles away) from OpenVPN to Tailscale and it worked like a champ. I sshed to the machine over OpenVPN, installed Tailscale, ran tailscale up, verified that it was online and reachable via the Tailscale IP and closed down OpenVPN. Very smooth and pain free.
This is why I recommend it. Even reading the sentences…
will scare away a whole bunch of users. It’s well beyond what many users are capable of or are willing to learn how to do.
VPNs are great! If you have the time and the skills to set it up and manage it at that low of a level more power to you. In fact Tailscale may be to confining for you and may not be a good fit. But software/services like Tailscale brings all the benefits of VPN with none of the complexity which is huge. It’s really as simple (on Linux) as installing it and running tailscale up.
Indeed, I meant to mention that. If I didn’t I apologize because it’s a very important point.
I don’t think it’s mysticism but it is a security “low hanging fruit”. If one exposes a port, even a VPN port, to the Internet, then the automated attack systems will wee that port and commence the attacks. If one uses a different from the default port that provides a little bit of protection against those sorts of automated attacks. If your port doesn’t appear at all then that’s even better. If there is no port detected then there is no way to probe it to see what’s running there. There is no way to deploy metasploit to try out the known vulnerabilities for that service.
It’s not perfect security by any means but it’s reasonably effective against some of the most common attacks vectors.
