WireGuard IO addon? Is this a good idea? Have a better one, lets hear it

Is anyone working on or have any thoughts on a WireGuard addon for Openhab? It seems to be a good way forward due to it being a faster than other forms of VPN and since it is not a fully finished project the idea is to limit the time it is running to lower the risk.

What do people who have more knowledge and actually have tried it before think of:

  • Start and stop WireGuard on demand. Only need it for 5 minutes a week, then only start it for that period of time.
  • Ability to auto start WireGuard only when the server has lost its connection to myopenhab for X minutes. Able to turn this feature on and off. If myopenhab goes down for 4 hours you still have a way in.
  • Kill switch that openhab can use to shutdown WireGuard.
  • Ability to filter out and restrict what WireGuard can give access to, ie not allowing REST API to create new rules on your system. If an attempt is made, lock out the IP that the request came from and log the attempt.
  • Display warning in the logs when your version does not match the latest version to encourage you to upgrade.

Have any thoughts?

What does this proposed add-on do that isn’t essentially what Exec binding would do to solve this? Would this add-on be platform independent (i.e. work with Linux, Windows, Mac, various NAS platforms)?

This sounds like something that is better handled by Rules. Don’t predefine the “if this happens do that” because there will be far more use cases, more “if this” and more “do thats” than you can ever think of.

I admit that I’m not an expert on WireGuard, but isn’t this a firewall function more than VPN function? I thought that the whole point of WireGuard was to make the VPN part simpler. Adding in firewall functions is definitely not going to make it simpler.

Honestly, I’m skeptical that this is needed. I’m already a bit biased though. I’m a strong advocate to use tools that are built for the task at hand. Managing WireGuard seems like more of an IT/Network administration task, not a home automation task. I’d only consider integrating anything to do with WireGuard with OH only so far as it may impact my home automation. For example, I might do something different in a Rule if WireGuard were down. Though I can detect that now with the SystemInfo binding, the SNMP binding, or Network binding.

But it’s just one opinion.

Exactly the point of a killswitch channel. Any rule can then turn off Wireguard as easy as turning off a switch. Common rules could be hardcoded in Java with a config or channel based switch to turn them on and off.

The perfect example of how a single addon can make life more simple for people without your excellent knowledge. The complexity of using three addons and multiple rules to hack together what could be an easy to use solution.

Seems I am not the first to think it is a good idea and perhaps I am working on the wrong project if automation and making things simple (perhaps not a good thing when it is security related) is not a goal to work towards. Perhaps this video shows what is possible to be done.

Not three add-ons at the same time. Any one of those add-ons could be used on it’s own to detect whether or not wireguard is down without a ru I listed three different ways to achieve this today, not a requirement to use three add-ons to achieve one way to do it.

Mine is just one opinion. So far you’ve not convinced me this is actually simpler. It seems like a special purpose binding to do what can already be done.

You asked for thoughts. If you only wanted positive ones you should have specified that in the first place.

Exactly, a special binding that can do what can already be done, only advantage is it could make things easier for the average user ‘if done right’. Just about every binding that gets released you could say the same thing, enough scripts, rules and hacks and why bother making any of them? I often get told that about Openhab, a light switch turns a bulb on and off so why bother with automation?

I can already do it your right and I have never setup Wiregaurd so perhaps it is so simple when I try you will convince me.

My frustration is not aimed at you, simply it is annoying to see how much of what I want is already implemented and green on the other side of the fence.

All I can offer is go try the other side of the fence. Lots of people are happier and/or HA provides a better fit for them than OH does. There is nothing wrong with that. And there are a number of people who straddle that proverbial fence and run more than one home automation system because there is no one that meets all of their requirements.

I said up front I’m pretty down on making OH do IT jobs. It’s not good at it. It’s never going to be good at it. And there are lots of existing tools that are good at it. So a binding that may make it easier to do IT management things just doesn’t seem like a good idea to me, especially if there are already easy ways to do it using existing bindings.

For security, administrative convenience and downtime mitigation I would anticipate most people keep network services (eg DNS, DHCP, TFTP, BOOTP, NAT, FW etc) on devices that are separate from their home automation controller. As such it seems more natural to configure VPN capabilities on the same device as handles the rest of the home’s network services (as opposed to via OpenHAB).

Plus over the coming years more and more devices will add IP capabilities, meaning users will have more and more reasons to wish they could connect to them remotely. It would be tedious to abstract every monitoring and control capability of every new device into OpenHAB, even if it were possible or desirable. This means users will often have a desire to connect to their IP-enabled devices remotely, and this desire will only increase as they acquire more devices.

Given the ever-increasing adverse consequences to security and network availability if network services fail, I think it’s more helpful to encourage and guide users into installing dedicated network servers instead. A VPN add-on in OpenHAB implies it’s a good thing to host a VPN on the same box, and I think strong arguments can be made that it isn’t.

1 Like

Thanks Ben for the helpful reply as I am learning from your reply. I am going to have to have a bit of a play to see what is possible.

Sadly I believe I have been convinced to do what everyone else seems to do, not contribute to the Openhab framework, nor try to change anything and just create scripts to make it easier to jump ship. Invest time in something that can move.

I believe the HA way is to run both inside containers so they are isolated, just on the same box and then it allows for automatic upgrades and tighter integration. A framework that goes much further than Openhab does.

I don’t think there is anything in the original proposal that requires Wireguard to be on the same host. I agree, that would be a suboptimal approach.

There are plenty of people jumping shop to OH too. And there is a pretty healthy amount of contributions. If asking for opinions and getting a couple you don’t like is making you jump ship there must be something else going on or you are overly sensitive. Ask for some opinions and if you don’t like them …


I could be wrong. Ben could be wrong. You clearly see a use for this. So go build it and maybe others will to. Or don’t. Go try some other system that’s a better fit for your requirements.

For future users:

How to see if wireguard is active, here are several approaches that can work, each bullet is a separate approach:

  • Set up Network binding Thing to ping a device that can only be reached through wireguard linked to a Switch Item
  • Set up a Network binding Thing to ping the external address/port for wireguard linked to a Switch Item
  • If you know SNMP you can configure that and use the SNMP binding to monitor it
  • If the OH machine is directly connected to wireguard it can use the SystemInfo binding network Channels to monitor that connection

Starting/stopping wireguard:

  • This is going to depend on how and where WireGuard is installed so I can’t provide a simple universal approach. But issuing a command through ssh, using an HTTP API call (e.g. if pfSense ever get’s WireGuard support), etc are likely what would be required.

Final note. That video is about hass.io plug-in, not a Home Assistant add-on. So if that is what you want to do you are not even talking about the right things. What you want is to add to openHABian the ability to install and configure WireGuard. You are not talking about creating an openHAB add-on.

If that is what you want to do than I don’t have any serious problems with it. It’s not the best idea but honestly it’s better than setting up a reverse proxy and encouraging users to expose that to the Internet which openHABian already does.

I watched the linked video and that’s what was shown, so I assumed that was the inspiration. I’m wondering why anyone would want to configure a remote WireGuard installation via OpenHAB though (especially given the additional configuration elements required: IP of the host, SSH keys for the host, package manager details for the host, sudo password for the host etc).

The natural way to offer turnkey VPN capabilities is via an OS distribution of some type. This also allows it to be hardened and made compatible with the rest of the network services included in that distribution. For example on my network I use Shorewall with OpenVPN, but there’s specific configuration required to make them work together. Figuring out how to securely integrate multiple network services (VPN, FW, NAT, DHCP etc) on a single box is complicated and error-prone even for those with lots of experience, so making that turnkey is a big help.

I’d respectfully suggest you take what you read on the internet with a grain of salt, especially when it’s being hyped up by companies with an angle (eg claiming mass adoption / growth / popularity as you want / need to attract VC funding / conference slots / influencers / followers etc). A working, stable, mature, open source and commercially independent technology like OpenHAB is rare, valuable and worth supporting. There’s lots of ways to contribute to OpenHAB and perhaps asking for suggestions given your interests, experience, location and time availability might uncover something encouraging?

That’s what openHABian is supposed to be.

Hey there, while reading through the posts few thoughts came to mind-
(not sure I’m making any new points, just relating the some of the suggestions)

I guess I can understand what’s the OP was going for-

In the situation of not having a VPN tunnel the my LAN at home, the main option of accessing my OH system is through cloud connector to myopenhab.org. This connection allows, for example, to reach my sitemaps by the iOS or Android apps. If I could have a switch item to turn the VPN server ON and OFF, I could control it from there.
Now, the need for such a function could be to limit the time the server is running and listening to remote requests.
I’m not a security expert but it sounds a reasonable approach.

Now this automatic feature will come in handy if myopenhab.org becomes offline for some reason, because the apps won’t have access to the OH box and won’t be able to turn it on.

Now regarding the excellent points made by Rich and Ben, I absolutely agree to the separation of duties concept and leting every device in the network do its job and be good at it.
Nevertheless I think a good feature would be a binding that controls a separate VPN box. Now obviously there are a lot of VPN solutions out there, so I wonder if there some standard protocol or mechanism to control the main ones. (I’m personally have no expert knowledge about this…)

Personally I’m running OH on a Raspberry Pi, and I have a separate Pi running plain Raspbian and running an openVPN server I installed using PiVPN (which runs 24/7). I imagine a simple way to implement the above features would be nice, although I’m now curious about trying to achieve this with currently available.
First step will be to check if my server accepts any kind of remote commands or something of this sort.

A different question though:

I never could figure out how to ping a device outside my OH’s local subnet. I have two subnets at home and I could only detect the availability of the local devices.
Did I miss anything? Is it as simple as defining a Thing with the desired IP address (which as far as saw didn’t work)?

Thanks, apologies for maybe kind of hijacking the topic…

I haven’t seen this thread earlier but want to let you know that openHABian meanwhile has gotten both built in, wireguard and Tailscale VPN. The latter actually is a commercial service (free for private use though) providing an automated VPN management of what is multiple wireguard tunnels under the hood. So you don’t have to manage an increasing/exploding amount of tunnels when you want to add more peers to the VPN. Their commercial plans also provide all sorts of central management for filtering if you’re after that.

There’s no binding level integration into OH but it shouldn’t be too hard to have exec binding fire up the tunnel interface on OH demand (anyone who did please let me know your config).
I don’t mind running it on the openHAB box as long you only use it to control access to OH instances,
but I’d agree VPN is more of a system management job rather than an OH task.

I want to share with my experience so far.

After reading up on wire guard, installing it and play with it a little- I feel it’s a little over my head. I’m no expert so I absolutely blame myself on this but I just couldn’t get it to work.

Like I mentioned in an earlier post here, I use an OpenVPN server (Installed with PiVPN) on a separate Pi from my OH box.
The installation process went super smood and the first try connecting from my mobile worked like a charm.

With wire guard I am missing something with the configurations because I can’t get access to my LAN after opening the tunnel. I need to do more research (probably update my basic networking knowledge as well) to get it to work.

But for now I am going to focus on a different path.
As far as I could tell, my usecase won’t leverage the advantages of wire guard (and Tailscale) because I only have one tunnel from my mobile used to mainly access my OH box.
So my thinking is to migrate the server to my OH box and then use exec binding to run some scripts to control the server. For now the scripts will start and stop the service itself, unless I’ll find a more elegant approach.
This will let me achieve those features from the OP.


Not sure if you’re aware, but you can use pivpn to install Wireguard - installation will be as simple as openvpn. I did it this weekend and had access to my LAN within a few minutes.

You’re right. I should have be more specific. When I talked about Wire Guard in my post I ment that I installed it through openhabian-config.
Sorry about that…

I am aware of that option of PiVPN, I admit I haven’t tested that one…

Hi there,
I’d like to share my complete solution in case someone will find it helpful.
I’m not sure it’s the most elegant way but it’s what I could achieve with my some what limited knowledge.

My setup:

  • Raspberry Pi 4 running OH 3.0.1 on openhabian.
  • An openVPN server running as a service on the same Pi (installed with PiVPN)

First I created two shell scripts inside /usr/bin/:

  1. startService.sh for starting the service:
sudo systemctl start openvpn.service
  1. stopService.sh for stopping the service:
sudo systemctl stop openvpn.service

And added an execution permission for both of them:

sudo chmod +x /usr/bin/startService.sh
sudo chmod +x /usr/bin/stopService.sh

The next steps I’m not sure are necessary but I did them nevertheless. I remember that I had to do them in OH2 (on an openhabian box) in order to execute sudo commands from rules, because the user running those commands would be openhab and not openhabian.

  1. Allow the user openhab to run sudo commands:
    sudo adduser openhab sudo
  2. Create a file with sudo commands that openhab can run without a password:
    sudo visudo -f /etc/sudoers.d/OHAdminPermissions
  3. Add the following lines to the file:
# Allow openhab user to execute commands
openhab ALL=(ALL) NOPASSWD: /usr/bin/startService.sh, /usr/bin/stopService.sh

Next is the OH stuff.
Create the relevant items:

Switch Sys_VPNControlSwitch "System VPN Control"      <vpn>           ["Point"]
String Sys_VPNStatus "System VPN Status"              <vpnstatus>     ["Point"]

Relevant sitemap lines:

        Switch      item=Sys_VPNControlSwitch label="VPN Server Control"
        Text        item=Sys_VPNStatus      label="VPN Server Status [%s]"

And the rule to control the server:

val String filename = "system.rules"
var Timer timer = null

rule "Control VPN Server"
    Item Sys_VPNControlSwitch received command
    logInfo(filename, "Controling the VPN server. Seting to " + receivedCommand)
    if (receivedCommand == ON) {
        if (timer===null) {
            timer = createTimer(now.plusSeconds(1), [|
            val String serviceStatusRaw = executeCommandLine(Duration.ofSeconds(15),"systemctl","status","openvpn.service")    
            val String serviceStatus = (serviceStatusRaw.split("\n").get(2)).stripLeading().split(" ").get(1)
            if (serviceStatus == "active") {
            } else {
            logInfo(filename, "VPN Status is: " + serviceStatus)
    } else if (receivedCommand == OFF) {
        if (timer===null) {
            timer = createTimer(now.plusSeconds(1), [|
            val String serviceStatusRaw = executeCommandLine(Duration.ofSeconds(15),"systemctl","status","openvpn.service")    
            val String serviceStatus = (serviceStatusRaw.split("\n").get(2)).stripLeading().split(" ").get(1)
            if (serviceStatus == "inactive") {
            } else if (serviceStatus == "active") {
            } else {
            logInfo(filename, "VPN Status is: " + serviceStatus)

The logic of the rule:

  1. Run the appropriate script according to the switch.
  2. Wait a second and check the service status.
  3. If the actual status doesn’t match what should be, revert the switch to the right position so the user can switch it back again.

The method I found to check the service status is as follows:

  1. Run a systemctl status command. The result saved into serviceStatusRaw and looks something like this:
● openvpn.service - OpenVPN service
   Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2021-04-01 09:32:07 IDT; 40min ago
  Process: 20069 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 20069 (code=exited, status=0/SUCCESS)

  1. The following manipulation will get the second line of that answer, strip the leading whitesapces and get that second word after Active: which should indicate the status of the service. Should be active or inactive but there could other values in case of an error of something else.

In conclusion:

  1. I now have an openVPN server running on my Pi.
  2. I can control it’s state from the one of mobile apps connected through cloud connector so it’s available also without the VPN connection.
  3. So incase I want to connect to my system from the internet, I start the server from the app and then connect to the server with an openVPN client from my phone.

Again, I’m in no way an expert in these things so I’m sure there are more “correct” methods to do all the things I did. I’d be happy to get any response or ideas to make it better.