Problem accessing the configurator page

Configuration
1

I’m having trouble accessing the configurator page.

Here’s my options:
{
“username”: “admin”,
“password”: “removed”,
“certfile”: “fullchain.pem”,
“keyfile”: “privkey.pem”,
“ssl”: false,
“allowed_networks”: [
“192.168.0.0/16”
],
“banned_ips”: [
“8.8.8.8”
],
“banlimit”: 0,
“ignore_pattern”: [
“pycache”
],
“dirsfirst”: false
}

When I start the add on, I get this:
starting version 3.2.4
INFO:2018-01-12 16:22:53,317:main:Starting server
INFO:2018-01-12 16:22:53,319:main:Listening on: http://0.0.0.0:3218

I feel like the “Listening on: http://0.0.0.0:3218” part might be important. Why would it be all zeros?

With this open setup, I get the following responses depending upon how I try to access:

http://hassio.local:8123/configurator:
a unending spinning dot and “Policy not fulfilled” if I leave the page and go back.
error log:
INFO:2018-01-12 16:29:13,326:main:123.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 16:29:18,121:main:123.30.32.1 - “GET / HTTP/1.1” 420 -

duckdns:
a unending spinning dot and “Policy not fulfilled” if I leave the page and go back.
error log:
INFO:2018-01-12 16:30:07,364:main:123.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 16:30:12,683:main:123.30.32.1 - “GET / HTTP/1.1” 420 -

http://192.168.1.180:3218:
Within the larger hass.io interface it returns the above error (http://192.168.1.180/configurator). If I l go straight to the port, it works fine (http://192.168.1.180:3218)

If I change my options to this:
{
“username”: “admin”,
“password”: “removed”,
“certfile”: “fullchain.pem”,
“keyfile”: “privkey.pem”,
“ssl”: false,
“allowed_networks”: [
“192.168.0.0/24”
],
“banned_ips”: [
“8.8.8.8”
],
“banlimit”: 0,
“ignore_pattern”: [
“pycache”
],
“dirsfirst”: false
}

http://hassio.local:8123/configurator:
a unending spinning dot and “Policy not fulfilled” if I leave the page and go back.
error log:
INFO:2018-01-12 17:34:21,367:main:123.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 17:34:48,004:main:123.30.32.1 - “GET / HTTP/1.1” 420 -

duckdns:
a unending spinning dot and “Policy not fulfilled” if I leave the page and go back.
error log:
INFO:2018-01-12 17:35:45,171:main:123.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 17:35:50,787:main:123.30.32.1 - “GET / HTTP/1.1” 420 -

http://192.168.1.180/configurator :
a unending spinning dot and “Policy not fulfilled” if I leave the page and go back.
error log:
INFO:2018-01-12 17:36:31,740:main:123.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 17:36:37,440:main:123.30.32.1 - “GET / HTTP/1.1” 420 -

I believe my router IP is 192.168.1.1.

So, long story short, I can access configurator via the pi IP, but only when “allowable networks” is set to “192.168.0.0/16”, other other ways of access fail.

All means of access were working yesterday, I’m unaware of what changed to make this all break. Any ideas?

THanks!

2

That just means it should be accessible via all interfaces on port 3218.

3

The reasons why Policy not fulfilled can happen are:

  • Client IP is banned
  • Client IP is not within the allowed networks

The problem I see is, assuming you have not modified the log, that the client IP form which you access the configurator is 123.30.32.1, which does not fall into the allowed networks (0.0.0.0 would allow everything). This seems to be an external IP. Do you have the configurator exposed to the internet and access it via some hostname?

I’ll add some warnings that indicate the reason for why the 420 error gets raised in the next version in case others need to fix such a problem. But for now I assume the problem lies within the path your client-device takes to reach the configurator.

4

That’s how mine works on tablets and phones where I can’t edit the hosts file. I’ve just accepted that’s how it is.

On Windows, adding an entry in the hosts file worked for me, like…

192.168.1.100 myname.duckdns.org

5

ahh, I thought that was my external IP, so I changed it to something else… I can see how that’d be annoying on my part. Sorry!

I just checked and it’s actually not my external IP… so, I replaced “172” with “123”

Here’s the real log:
starting version 3.2.4
INFO:2018-01-12 23:03:58,216:main:Starting server
INFO:2018-01-12 23:03:58,217:main:Listening on: http://0.0.0.0:3218
INFO:2018-01-12 23:04:04,408:main:192.168.1.162 - “GET / HTTP/1.1” 200 -
INFO:2018-01-12 23:04:05,294:main:192.168.1.162 - “GET /api/listdir?path=. HTTP/1.1” 200 -
INFO:2018-01-12 23:04:24,618:main:172.30.32.1 - “GET / HTTP/1.1” 420 -
INFO:2018-01-12 23:04:37,041:main:172.30.32.1 - “GET / HTTP/1.1” 420 -

So, the requests coming from 192.x is when I access it by IP and port, the 172.x requests come from hassio.local.

This was just working last night!

6

Maybe there was an update for hassio which changed some details about the networking. Add 172.30.0.0/16 to the allowed networks. So make it say:

"allowed_networks": [
    "192.168.0.0/16",
    "172.30.0.0/16"
],

I saw you have changed the 192-net to 24. When doing that, it should be 192.168.1.0/24. Otherwise you shouldn’t be able to connect directly via IP now as well because you’re clients are on the .1.x subnet, not .0.x.

1 Like
7

Adding ", “172.30.0.0/16"” did it. All working again.

Much appreciated!

8

Hi,

See you have helped others and I am looking for a solution to remote access to the configurator. I have the following setup.

{
  "username": "redacted",
  "password": "redacted",
  "ssl": true,
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem",
  "allowed_networks": [
    "192.168.1.0/24",
    "172.30.0.0/16",
    "0.0.0.0/8"
  ],
  "banned_ips": [
    "8.8.8.8"
  ],
  "banlimit": 0,
  "ignore_pattern": [
    "__pycache__"
  ],
  "dirsfirst": false,
  "enforce_basepath": false,
  "notify_service": "persistent_notification.create"
}

When I try to access remotely I get the following in the log:

WARNING:2018-10-18 12:19:43,127:main:Client IP not within allowed networks.
INFO:2018-10-18 12:19:43,131:main:79.102.138.161 - “GET / HTTP/1.1” 420 -

I do not understand the reason why.

Thanks for any help!

9

The correct network to allow access from anywhere would be 0.0.0.0/0, not .../8. And with that setting you don’t need the 192... and 172... anymore.
Allowing this though isn’t ideal in terms of security. For initial testing it would be ok. But in the long run you should leave the list of allowed networks empty and use the SESAME feature to whitelist your IP on demand.

10

Perfect. Now I have access. I agree that the door is wide open and will look att Sesame.

11

Hi,

Setup Sesame as follows:

{
  "username": "redacted",
  "password": "redacted",
  "ssl": true,
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem",
  "allowed_networks": [],
  "banned_ips": [
    "8.8.8.8"
  ],
  "banlimit": 0,
  "ignore_pattern": [
    "__pycache__"
  ],
  "dirsfirst": false,
  "enforce_basepath": false,
  "notify_service": "persistent_notification.create",
  "sesame": "redacted"
}

Made no other changes.

I then tried accessing from Mac on separate tab while on my network - worked fine.
I then tried accessing from Mac from panel_iframe while on the network - worked fine.
I then tried accessing from iPad on separate tab while on my network - worked fine.
I then tried accessing from iPad on separate tab remotely - worked fine.

In none of the cases above did I have to use the sesame code. Maybe the ip-adresses I accessed from were already whitelisted. But this seems strange.

I then tried accessing from iPad from within Home Assistant app - black page and no error message. I believe this is a problem with the app. This try does not generate anything on the configurator Addon log.

My setup in configuration.yaml is:

panel_iframe:
configurator:
title: Configurator
icon: mdi:wrench
url: https://192.168.xxx.xxx:3218

What am I doing right? What am I doing wrong?

12

I also tried accessing:

https://redacted.duckdns.org:3218/mysesamecode

The result was:
File not found

13

The panel_iframe won’t work this way. The link has to be https://yourdomain.whatever.com:3218/yoursesamesecret. At least if you want to use the panel from outside.
Besides that, put back your local network (192.168.0.0/16 and 172.30.0.0/16 if your using hassio) into the list of allowed networks. This will allow your local devices to directly connect to the configurator.
Then open the configurator and have a look at the currently whitelisted IPs. You can see them if you click on the menu-dots on the upper right and then on Network Status. Everything listed there will have access. You can remove entries from there. When that’s done switch your smartphone to use mobile data and try to access http://yourdomain.whatever.com:3218 (without the sesame) and you should get an error. Then try it with appending the sesame and it should work.

Of course you have to restart the onfigurator to make the changed settings (sesame, IPs etc.) effective.

14

New problems :slight_smile:

38
38782×562 30.7 KB
Skärmavbild 2018-10-18 kl. 17.23.38

Results:

  1. Accessing from separate tab on Mac/Safari on network using https://redacted.duckdns.org:3218 - works fine
  2. Accessing from panel_iframe on Mac/Safari on network using https://redacted.duckdns.org:3218 - file not found
  3. Accessing from separate tab on iPadMac/Safari on network using https://redacted.duckdns.org:3218 - works fine
  4. Accessing from separate tab on iPadMac/Safari on network using https://redacted.duckdns.org:3218/mysesamecode - file not found
  5. Accessing from separate tab on iPadMac/Safari remotely using https://redacted.duckdns.org:3218 - policy not fulfilled
  6. Accessing from separate tab on iPadMac/Safari on network using https://redacted.duckdns.org:3218/mysesamecode - policy not fulfilled

Settings in Addon:

{
  "username": "redacted",
  "password": "redacted",
  "ssl": true,
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem",
  "allowed_networks": [
    "192.168.0.0/16",
    "172.30.0.0/16"
  ],
  "banned_ips": [
    "8.8.8.8"
  ],
  "banlimit": 0,
  "ignore_pattern": [
    "__pycache__"
  ],
  "dirsfirst": false,
  "enforce_basepath": false,
  "notify_service": "persistent_notification.create",
  "sesame": "mysesamecode"
}

Settings in configuration.yaml:

panel_iframe:
  configurator:
    title: Configurator
    icon: mdi:wrench
    url: https://redactd.duckdns.org:3218/mysesamecode

Sorry for being such a pain

15

At this point it would be helpful to see the logs of the configurator so we can see why it made such decisions.

Scenario 2. doesn’t make sense though, except if you don’t have valid certificates OR your HASS frontend does not use https. If the configurator uses https, then HASS has to as well and vice versa. It can not be mixed.
Scenario 5. is like it should be. Scenario 6. indicates that whitelisting didn’t work. Which doesn’t make sense because your in the allowed network.

You should also check the banned IP status in the Network Status section of the configurator. If an IP is banned, then it can’t access the configurator, even if it’s within the allowed networks.

16

Before sending the log, could it be that characters l ä, å or ö are not accepted? I see in the log “%C3%A4” instead of “ä”.

There are no banned IP dresses.

17

Much better :smile:

18

Big thanks for your help. This has been bugging me for a long time, and now all modes work. For the first time I can access the configurator from within the app!!!

19

One last question - now I get an enormous amount of notifications about white list even if an ip adress already is on the white list. Can I avoid these notifications.

08 Skärmavbild 2018-10-18 kl. 19.08.08

20

Yes, URLs can’t contain special characters in general. They are always encoded in some way ( %XY...), and the configurator won’t translate that back into the original characters.

As for the other question: no, when using the sesame this warning is always shown. And it does not update an existing notification because if it was an attacker, a following legitimate sesame-usage whould hide the warning about the attack.

My personal opinion on this topic:
Your panel_iframe should only work internally (by using https://192.168.x.x:3218). Modifying the configuration when not at home always includes a certain risk-factor. If you do something that breaks your configuration and restart Home Assistant, then you’re possibly not able to revive your Home Assistant remotely. Of course I understand the benefits of being able to fix something as well. But for that purpose I would simply bookmark the sesame-URL instead of going through the HASS UI, which also eats up quite some space on your screen. This way using the panel-link won’t generate these warnings.