Reverse tunnel for Home Assistant (no public IP, firewall/router config required)

Share your Projects!
, ,
1

Hello, I am creator of webhookrelay. I have initially built the project for developers or engineers to automate CI/CD pipelines and receive webhooks in internal networks, although since then the project matured and gained some features.

Recently I started using Home Assistant and thought it would be nice to have an easy access to it without configuring router/having public IP so I thought I will try to get my service working for this. Luckily, the only thing I had to do was building an arm image (as I run Home Assistant on a Raspberry Pi).

I chose Docker deployment method as I am the most comfortable with it:

docker run -d --name assistant --net host -v /home/pi/home_assistant:/config -v /etc/localtime:/etc/localtime:ro --restart always homeassistant/raspberrypi3-homeassistant:0.76.2

Although it doesn’t really matter how you are deploying it, as long as you have Docker for the next steps :slight_smile: You will need a token from here https://my.webhookrelay.com/tokens.

Then create a new tunnel here https://my.webhookrelay.com/tunnels:

create tunnel
create tunnel1524Ă—998 104 KB

Now, start a tunneling daemon:

docker run --name whr-relayd --net host --restart always -d webhookrelay/webhookrelayd-arm:latest --mode tunnel -t rpi -k your-key -s your-secret

That’s it, you can now access it remotely on your public subdomain. Just don’t overuse it, I made it free for one tunnel but obviously it would be nice if you supported my project! :stuck_out_tongue:

I have written a more detailed guide in webhookrelay blog with installation instructions.

I am also thinking of writing a plugin for this, to make installation easier if it makes sense. Feedback is welcome :slight_smile:

P.S. If you are not running ARM, use webhookrelay/webhookrelayd:latest image

11 Likes
2

Definitely going to give it a try :grinning:

Nginx is still giving me headaches to get external access configured properly (get some js related errors).

1 Like
3

Interesting, bookmarking so I can read up on this later.

4

I see in the instruction that it’s for Home Assistant running in Docker, so have to setup that config first as I am running hassio.

Maybe this is something for @frenck to check if it can be added to the hassio addons.

5

since in the example I start webhookrelayd container with the host networking (–net host):

docker run --name whr-relayd --net host --restart always -d webhookrelay/webhookrelayd-arm:latest --mode tunnel -t rpi -k your-key -s your-secret

It would connect to it as long as it’s running on the localhost (or at least it’s reachable through the internal network). How do you deploy your Home Assistant?

Agent itself is written in Go, size is around 13MB so can be run without the Docker if you are using some other supervisor :slight_smile:

6

Hassio is actually running in Docker as well. I have hassio installed on Ubuntu Server.

7

This is so easy and super amazing. Thank you so much!

8

That’s great waiting for the hassio addon!!!

9

Thanks! :slight_smile: What would you want to see in the addon? In order for the plugin to work it would need:

  • Get a token and secret
  • Tell it on which port your HA is running (I guess this can have a reasonable default)

Would it make sense to have a lightweight UI from the webhookrelayd container that would let users add these details? Or is it better to leave this for the plugin json config?

10

@rusenask has sent me an email on 1 September about creating an add-on, but I’m currently on a vacation/holiday with my family. So I promised to get back to him as soon as I am back home again.

:warning: I do have some concerns about this service. :warning:

  • This is a commercial service. There is nothing wrong with that, but I think that is should be clear from the get-go. They kindly offer a free tier, with a max of 1 tunnel. That is great, but will be insufficient for most users. Their goal, of course, is for you to upgrade. Again fine, nevertheless, I still think this should be more clear.

  • The Docker container runs on the host network. Why the hell is that needed? I cannot think of a reason why you would need that in this case.

  • :warning: My biggest concern is the way things get controlled. So you run a container, go to their website, and can control remotely what to expose. Nice! But here is the catch: For this to be possible, it means the client has access to everything in your network! The way this works, it sure as hell is not limited to the localhost, but could access your network full blown.

Let me be extra transparent (and honest) myself as well now. I’ve been working on a similar service for Home Assistant the past few weeks, which will be offered totally free of charge, uses different techniques, does not require you to install anything, and is currently in testing phase. So I’m very aware at this point on the risks and setups, but I’m biased because of this reason.

8 Likes
11

Thanks @frenck, that’s a very clear response.
For now have a pleasant holiday :palm_tree:

12

thanks for replying! :slight_smile:

This is a commercial service. There is nothing wrong with that, but I think that is should be clear from the get-go. They kindly offer a free tier, with a max of 1 tunnel. That is great, but will be insufficient for most users. Their goal, of course, is for you to upgrade. Again fine, nevertheless, I still think this should be more clear.

At the moment yes, the ideal user would convert, although as a developer that’s using other free services I had to have a free tier too.

The Docker container runs on the host network. Why the hell is that needed? I cannot think of a reason why you would need that in this case.

Absolutely no reason to, just wanted an example that would run with an existing non Docker (as I could use Docker networking to connect directly) HA installation. If HA is running in a docker you could connect via http://ha:8123

My biggest concern is the way things get controlled. So you run a container, go to their website, and can control remotely what to expose. Nice! But here is the catch: For this to be possible, it means the client has access to everything in your network! The way this works, it sure as hell is not limited to the localhost , but could access your network full blown.

Yeah, this was required to make it configurable remotely, especially for Kubernetes case where network topology can change at any time. If users do want something like this I could implement a “lock down” on the agent, to allow only certain destinations and open source the agent itself :slight_smile:

13

Just a heads up that because of the way this works, webhookrelay.com will be able to access all interaction between you and your instance, including tokens to access your instance.

4 Likes
14

In theory - yes, especially since I am doing TLS termination. However, this is not a free service where “you are the product” :slight_smile: Only webhook requests are recorded for debug/resend https://webhookrelay.com/v1/examples/receiving-webhooks-on-localhost.html.

Tunnels are not logged in any way and the connection from the agent to the public service is encrypted.

I could offer TLS pass-through functionality if anyone wanted to supply their own certs. Then traffic through webhookrelay would be encrypted and you could only trust your own certificates :slight_smile:

15

That’s awasome, waiting forma this addon

16

Have you even read my post? :roll_eyes:

17

The nice man on the internet says he isn’t doing anything with my data, so it must be OK.

1 Like
18

Looks like this is all I need to know, thanks for saving me time on reading how this service works.

19

Yes, dont you said you been working of similar service?

20

Yep, I work on a lot of things, nevertheless, depending on the results it will be out (or cancelled). Some add-ons simply don’t make it into the public.