search

brenner-tobias / addon-cloudflared

Connect remotely to your Home Assistant instance without opening any ports using Cloudflared.
MIT License
874 stars 54 forks source link

HTTP 400 after login #299

Closed dwahdany closed 1 year ago

dwahdany commented 1 year ago

The problem

I've (hopefully) setup everything according to instructions, tried both automatic and manual tunnel, even changed the tunnel service to 'localhost:8123' but to no avail:

I can open https://<domain> in my browser and see the login screen. Upon entering credentials, I see "Unable to connect, retrying in ...". Pressing retry now doesn't help, I can't get past the login. The only problem in the browser I can identitfy is a HTTP 400:

Request URL: https://<domain>/auth/token
Request Method: POST
Status Code: 400

which returns {"error":"invalid_request","error_description":"Invalid code"} Entering wrong credentials fails the login, so some communcation is happening.

What version of Cloudflared has the issue?

4.0.8

What was the last working version of Cloudflared?

No response

What type of installation are you running?

Home Assistant OS

Add-on YAML Configuration

additional_hosts: []
external_hostname: <domain>
log_level: debug
tunnel_token: >-
<token>
tunnel_name: hassio-remote-mgmt

Anything in the logs that might be useful for us?

-----------------------------------------------------------
 Add-on: Cloudflared
 Use a Cloudflare Tunnel to remotely connect to Home Assistant without opening any ports
-----------------------------------------------------------
 Add-on version: 4.0.8
 You are running the latest version of this add-on.
 System: Home Assistant OS 9.4  (aarch64 / raspberrypi4-64)
 Home Assistant Core: 2022.12.8
 Home Assistant Supervisor: 2022.12.1
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
Log level is set to DEBUG
[16:46:56] DEBUG: Cloudflared log level set to "info"
[16:46:56] INFO: Using Cloudflare Remote Management Tunnel
[16:46:56] INFO: All add-on configuration options except tunnel_token will be ignored.
2023-01-17T15:46:57Z INF Starting tunnel tunnelID=12926c6f-15b2-40a5-90e5-e7832ee65d6b
2023-01-17T15:46:57Z INF Version 2023.1.0
2023-01-17T15:46:57Z INF GOOS: linux, GOVersion: go1.19.3, GoArch: arm64
2023-01-17T15:46:57Z INF Settings: map[loglevel:info metrics:0.0.0.0:36500 no-autoupdate:true token:*****]
2023-01-17T15:46:57Z INF Generated Connector ID: de5dd319-650b-4043-80f8-c1e3a6add8d5
2023-01-17T15:46:57Z INF Will be fetching remotely managed configuration from Cloudflare API. Defaulting to protocol: quic
2023-01-17T15:46:57Z INF Initial protocol quic
2023-01-17T15:46:57Z INF ICMP proxy will use 172.30.33.4 as source for IPv4
2023-01-17T15:46:57Z INF ICMP proxy will use :: as source for IPv6
2023-01-17T15:46:57Z INF Starting metrics server on [::]:36500/metrics
2023-01-17T15:46:57Z INF Connection 3ae2bbb5-ceb2-4281-8c44-77224818dcd9 registered with protocol: quic connIndex=0 ip=198.41.200.13 location=BRU
2023-01-17T15:46:57Z INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"<domain>\",\"originRequest\":{},\"service\":\"http://homeassistant:8123\"},{\"service\":\"http_status:404\"}],\"warp-routing\":{\"enabled\":false}}" version=3
2023-01-17T15:46:57Z INF Connection 8031b0b8-b87e-47ad-88a6-14a85ef3c895 registered with protocol: quic connIndex=1 ip=198.41.192.227 location=TXL
2023-01-17T15:46:59Z INF Connection 1acff3e8-ef89-45bd-a22f-6d0de4685596 registered with protocol: quic connIndex=2 ip=198.41.192.37 location=TXL
2023-01-17T15:47:00Z INF Connection c7300f8d-225e-4fbd-96e9-58a59fe8469b registered with protocol: quic connIndex=3 ip=198.41.200.113 location=BRU

Steps to reproduce the issue

  1. Install addon
  2. Configure tunnel
  3. Start addon
  4. Try to connect

Hassio Config

# Loads default set of integrations. Do not remove.
default_config:

# Text to speech
tts:
  - platform: google_translate

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

http:
    use_x_forwarded_for: true
    trusted_proxies:
      - 172.30.33.0/24

binary_sensor:
    - platform: ping
      host: 1.1.1.1
      name: "Quad1"
      scan_interval: 30
    - platform: ping
      host: 9.9.9.9
      name: "Quad9"
      scan_interval: 30

blueprint:
    name: Philips Wall Switch Light
    description: Toggle a light based on Philips Wall Switch
    domain: automation

    trigger:
        platform: state
        entity_id: !input wallswitch

    action:
        service: >
            {% if trigger.to_state.state == "on" %}
              light.turn_on
            {% else %}
              light.turn_off
            {% endif %}
        target:
        entity_id: !input light

Hassio Logs

Hassio shows failed login attemps, where <myIPV6> is my public IPv6 address.

Logger: homeassistant.components.http.ban
Source: components/http/ban.py:81
Integration: HTTP ([documentation](https://www.home-assistant.io/integrations/http), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+http%22))
First occurred: 16:24:33 (48 occurrences)
Last logged: 17:03:28

    Login attempt or request with invalid authentication from <myIPV6> (<myIPV6>). Requested URL: '/auth/token'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0)
    Login attempt or request with invalid authentication from <myIPV6> (<myIPV6>). Requested URL: '/auth/token'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Safari/605.1.15)
    Login attempt or request with invalid authentication from <myIPV6> (<myIPV6>). Requested URL: '/auth/token'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36)
    Login attempt or request with invalid authentication from <myIPV6> (<myIPV6>). Requested URL: '/auth/login_flow/62bbe401e193afb6474b66f25daba011'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36)
brenner-tobias commented 1 year ago

Your add-on and HA configurations look fine, also the logs of Cloudflare look good. Just to make sure that you have done nothing wrong with setting-up the remote tunnel, I suggest that you set-up the local tunnel again and follow the instructions, without introducing any additional_hosts or other options. So really just setting the tunnel name to something new and entering your (sub)domain that you are managing in Cloudflare.

brenner-tobias commented 1 year ago

Also: Are you using a domain from Freenom?

dwahdany commented 1 year ago

Thanks for the response, I've tried setting up everything again, but I get the same error. I didn't comment again, since I'm currently figuring out whether this is even related to your addon. Manually exposing :80 works. Using nginx-proxy-manager breaks, resulting in the same error. To answer your question, the domain is a paid TLD.

Edit: Enabling websocket support in nginx-proxy-manager fixes the manually exposed port and allows for SSL remote access.

dwahdany commented 1 year ago

Current status:

The issue seems to be that during login a websocket connection fails: wss://<domain>/api/websocket I guess that results in an invalid access token and all consecutive failures. This is the same error I observed when using nginx-proxy-manager without websocket support.

brenner-tobias commented 1 year ago

Can you let me know where NPM is used in you set-up? I suggest that you set everything up without any additional hosts or NPM or anything to test the tunnel connection with only HA exposed. Then you can move from there to see whats going on. So very simply close all ports on your router, delete all DNS records related to HA from Cloudflare. Configure the add-on with any subdomain you want to use, start it, open the logs and copy the link to authenticate with Cloudflare, wait for a couple of minutes and check the URL

arnold-c commented 1 year ago

I'm afraid that I'm getting exactly the same error on a fresh install (HAOS on Proxmox), without NGINX proxy manager set up. I can access home assistant at https://homeassistant.local:8123, but not using my subdomain. The domain is hosted with cloudflare and works as expected.

For what it's worth, I had this exact problem when I tried setting up HA with docker compose in linux and figured it was an issue with how I set it up, but I don't think it is any more. At times, it also returned the same error as #263 when I first installed the add-on (as well as the container setup), in both Safari and Chrome browsers.

My add-on logs below.

-----------------------------------------------------------
 Add-on: Cloudflared
 Use a Cloudflare Tunnel to remotely connect to Home Assistant without opening any ports
-----------------------------------------------------------
 Add-on version: 4.0.8
 You are running the latest version of this add-on.
 System: Home Assistant OS 9.4  (amd64 / qemux86-64)
 Home Assistant Core: 2023.1.7
 Home Assistant Supervisor: 2022.12.1
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[00:40:19] INFO: Checking add-on config...
[00:40:20] INFO: Checking for existing certificate...
[00:40:20] INFO: Existing certificate found
[00:40:20] INFO: Checking for existing tunnel...
[00:40:20] INFO: Existing tunnel with ID x found
[00:40:20] INFO: Checking if existing tunnel matches name given in config
[00:40:20] INFO: Existing Cloudflare Tunnel name matches config, proceeding with existing tunnel file
[00:40:20] INFO: Creating config file...
[00:40:21] INFO: Validating config file...
Validating rules from /tmp/config.json
OK
[00:40:21] INFO: Creating DNS entry sub.domain.com...
2023-01-24T05:40:22Z INF sub.domain.com is already configured to route to your tunnel tunnelID=x
[00:40:22] INFO: Finished setting up the Cloudflare Tunnel
[00:40:22] INFO: Connecting Cloudflare Tunnel...
2023-01-24T05:40:22Z INF Starting tunnel tunnelID=x
2023-01-24T05:40:22Z INF Version 2023.1.0
2023-01-24T05:40:22Z INF GOOS: linux, GOVersion: go1.19.3, GoArch: amd64
2023-01-24T05:40:22Z INF Settings: map[config:/tmp/config.json cred-file:/data/tunnel.json credentials-file:/data/tunnel.json loglevel:info metrics:0.0.0.0:36500 no-autoupdate:true origincert:/data/cert.pem]
2023-01-24T05:40:22Z INF Generated Connector ID: x
2023-01-24T05:40:22Z INF Initial protocol quic
2023-01-24T05:40:22Z INF ICMP proxy will use 172.30.33.0 as source for IPv4
2023-01-24T05:40:22Z INF ICMP proxy will use :: as source for IPv6
2023-01-24T05:40:22Z INF Starting metrics server on [::]:36500/metrics
2023-01-24T05:40:23Z INF Connection x registered with protocol: quic connIndex=0 ip=x location=IAD
2023-01-24T05:40:23Z INF Connection x registered with protocol: quic connIndex=1 ip=x location=ORD
2023-01-24T05:40:24Z INF Connection x registered with protocol: quic connIndex=2 ip=x location=IAD
2023-01-24T05:40:25Z INF Connection x registered with protocol: quic connIndex=3 ip=1x location=ORD
brenner-tobias commented 1 year ago

I assume this is an issue with your set-up on a VM, in a docker client. I am sorry but I cannot replicate that. Kindly let me know if you have any additional information / ideas that might help.

arnold-c commented 1 year ago

I'm not sure why, but after uninstalling and reinstalling the local tunnel, everything seems to be working. Safari can't find the server, but Chrome can so that's OK.

I think there might have been some interference with NGINX proxy manager because even though I completely remove the linux OS I was using for the docker setup (it was running bare-metal, not within a VM) and replaced the whole SSD with the Proxmox installation so I could try HAOS on a VM, I'm still able to access the NGINX welcome pages. I have no idea how that's happening as my understanding is that is should only persist as long as the docker containers, but I'm very new to NGINX so possibly interpreting this incorrectly. Sorry I couldn't be more help.

github-actions[bot] commented 1 year ago

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!