CloudFlare Argo

Third party integrations
6

No, I run it on a NUC.

1 Like
7

was probably much easier on NUC than hassio based Raspberry PI.

I cloned the repo to:

Made the changes required to get it to compile on ARM and then added in a config.json / build.json to allow it to build for Hassio.

I was then playing around to see if i could get a config to work, thinking that the labels were applied to the hera container! Oops!

When i tried to build the repo directly in portainer it wouldn’t work, however building in Hassio worked, so i just built it and in portainer duplicated hera into another project. It then needed to be edited to use the “host” network which homeassistant uses.

I then had to run portainer in “leave_front_door_open”: “true” mode to be able to edit the homeassistant container (Yes i know we shouldnt).

And also made a slight tweak to the configuration is suggests. Within the homeassistant container I put the .pem key into SSL and then mounted /mnt/data/supervisor/ssl to /certs and also /var/run/docker.sock mounted to /var/run/docker.sock

I’d love to be able to build a module to make this easy, but from what I can see you cannot apply labels onto docker containers via a HASSIO addon.

8

Also because you are doing things manually when you update you have to re-add the labels.

9

Looks like for HASSOS Hera isnt really great unless its rewritten quite a bit.

I updated my addon to allow hostname2 and hostname3 (if they are present it runs other tunnels, if they arent it doesnt bring them up).

Hopefully at some point in the future i’ll have time to make it work in a much more pretty way!

10

My ISP recently switched to CG NAT, and I lost my ability to route the traffic to my homeassistant server.
This addon saved me a lot of hassle and time. Great job @latic!

1 Like
11

I stopped using Argo awhile back since I started using using Nabu Casa, but before I did, I was using this Docker container.

It added some flexibility for me that I couldn’t get to work with Hera. Just throwing it out there as another option.

1 Like
12

Happy it helped!

I’ve noticed an issue which can happen when rebooting it, so at some point i’ll get less lazy and do some development on it. Another user on github has also made vast improvements to how much space this will use (by using the right image) and really made it much less hacky, i’ve asked to merge in their changes.

1 Like
13

Converted the App over to Alpine so install is much quicker and it runs much lighter.

14

Hi! Your add on works great, thanks. Is there a way to reduce the cpu usage of it? I’m running it on a raspberry pi4 and it’s using 30%of the cpu, which I thought was a bit excessive

1 Like
15

Never saw this. It was actually really bad coding causing this (I’m not sure if you submitted the github issue, but I got it solved).

I had 2 other tunnels running and when they weren’t used the services werent disabled, which meant they continued to load and die (hence CPU).

Just converted the app over to the new “Named” tunnel and ensured nothing like this happens now. It means using one version of the tunnel you can export out multiple names etc.

1 Like
16

@latic

Many thanks for the argo tunnel add-on. I use it extensively. Having a bit of a hard time with the upgrade, and while trying to troubleshoot ran into a bug. I submitted it on github in case you don’t see it.

Question:
Am I seeing correctly that the tunnel created will always be named ‘homeassistant’?
Do you have plans to tie the configuration values to this tunnel name in the near future?
Reason I’m asking is because I use a single domain with to tie multiple HA installations together. Example:

ha1.domain.com
ha2.domain.com

Previously this worked fine with the same cert.pem at each location because the tunnels could be named differently. I think with the upgrade this will only work with a different cert at each location because a single cert couldn’t do multiple tunnels named “homeassistant”. No big deal if that’s the case, just wanted to see if this was in the cards near term.

1 Like
17

On further investigation it seems like tunnel names are global to an entire cloudflare account and not just per domain. No matter how many domains you own you can only have one tunnel called “homeassistant” from what I can tell.
A configuration value that allows the setting of the tunnel name would fix my problem.
I’ll probably fork the repo and add the config value. I’ll send a pull request if you have any interest in adding to the main repo.

1 Like
18

@latic thanks for the Addon, I’m in a CGNAT and with this I have remote access to my HA.
Anyone have this working with Alexa??

1 Like
19

What should i write in tunnel_name , hostname , services?

my config-

certificate: /config/cert/argo.pem
tunnel_name: homeassistant 
hostname: home.example.com 
service: http://192.168.1.100:8123
hostname2: 'null'
service2: 'null'
hostname3: 'null'
service3: 'null'
addconfig: 'null'

i am getting error

[14:52:55] INFO: Starting CloudFlare Argo
error parsing tunnel ID: homeassistant is neither the ID nor the name of any of your tunnels

it runs perfectly if i do via cmd
cloudflared tunnel --hostname home.example.com --url http://192.168.1.100:8123

20

Try deleting your cf-argo directory and starting it again. There’s code in there that creates the tunnel, but it only runs once when the add-on is initialized. If something went wrong during the initial startup it will never work. I put some detailed setup notes here:

1 Like
21

Another thought: if it works when you run the command manually, but not in the add-on, its possible you are using two different keys.

An additional thing to look at: the add-on uses the config file form of the command, you can try emulating it to find the problem. Here’s what it looks like in the code:

cloudflared --origincert=${certificate} tunnel --config=/config/cf-argo/config.yml run
1 Like
22

I run Home Assistant container on a Debian VM and have it working with Cloudflare Tunnel (used to be Argo). I moved to this a few months back after some of the older non-Cloudflare maintained containers stopped working properly without workarounds.

Here are some basic instructions on how I got it working. There are probably easier ways, but throwing this out there in case it points someone in the right direction. This does not cover setting up Cloudflare Teams / Access rules. It only gets the tunnel working.

Install
On any computer, install cloudflared, login (to get a cert.pem file), and create a tunnel (to get a .json). This only needs to happen once and you can use the login (cert.pem) to manage your tunnels (create/delete). The tunnel file and a config are really the only files you need on your Docker machine.

Install
Login
Create Tunnel

Pay attention to where your .json file lives. You will have to move it to your server. It will look something like this:

12345678-1234-1234-1234-123456789012.json

On your Docker host, make a folder for the docker container, in my case this is /srv/docker/cftunnel

Move your tunnel json there and create a config.yml.

Inside /srv/docker/cftunnel:

  • config.yml
  • 12345678-1234-1234-1234-123456789012.json

config.yml

tunnel: 12345678-1234-1234-1234-123456789012
credentials-file: /etc/cloudflared/12345678-1234-1234-1234-123456789012.json

ingress:
  - hostname: "homeassistant.mydomain.com"
    service: http://<machine ip>:8123
  - service: http_status:404

Note: Dont use the docker container name in place of local ip. Since Home Assistant container usually runs in host mode, you have to specify the local machine ip. Also note that Cloudflare tunnel will not route to a host outside of the local machine, so it has to be installed on the same machine as Home Assistant.

docker-compose.yaml entry - I call mine cftunnel

  cftunnel:
    container_name: cftunnel
    hostname: cftunnel
    image: cloudflare/cloudflared
    restart: unless-stopped
    volumes:
      - /srv/docker/cftunnel:/etc/cloudflared
    command: tunnel --config /etc/cloudflared/config.yml run 12345678-1234-1234-1234-123456789012

Start your container with docker-compose up -d. Check log output to make sure it started correctly.
Final step, make a CNAME entry on Cloudflare to point to the tunnel.
There are multiple ways to do this:
LINK

Access your Home Assistant instance from https://homeassistant.mydomain.com

This doesnt make dynamic tunnels like some of the other containers out there, but you do have a lot of flexibility in the config.yml to create additional ingress rules for other services on the same machine if you like (SEE HERE). Anything on a different machine requires a new tunnel (and associated .json file).

23

I followed your tutorial but I have 400: Bad Request, this seems related to HA when accessed from a external http/https address. Do you had the same problem?

This HA log:

A request from a reverse proxy was received from 172.19.0.2, but your HTTP integration is not set-up for reverse proxies

10:03:31 – (ERROR) HTTP

24

Solved adding in configuration.yaml

http:
use_x_forwarded_for: true
trusted_proxies:
- 172.19.0.2

25

@Tony2k sorry didn’t see this, that setting is part of the instructions.

Closing this down now.

GitHub - brenner-tobias/addon-cloudflared: Connect remotely to your Home Assistant instance without opening any ports using Cloudflared. has come a long way and is way better to use:

2 Likes