External access with Android-app suddenly blocked (3.2 w/Nginx, Android beta-606-46b0b87, oneplus 7t pro)

Configuration
1

This hasn’t been the easiest to figure out and I still need help solving this problem completely.
In the last few days the app suddenly stopped connecting to HA externally, only changes I had done to the instance was updating to 3.2. It wouldn’t load HA at all and no obvious failed logins displayed.

First check was that it could connect internally w/ app and yep, all fine, even external address would connect internally in the app, hm, okay. Next check was accessing external address externally with a browser and sure enough, that worked, hm, that’s weird. Cleared the app cache and storage for safe measure and attempted again, no dice, hm. Checked with the wife and she could connect fine through the app on iOS. Next step was checking that no network settings were changed on the Android and nothing is changed. I also made sure to flush all old refresh tokens on the user page, still no change.

As the only change I had made was updating to 3.2 I rolled back to a full snapshot of 2.3, still no change.

So what I knew so far was the following:

  • External access was working fine in browser, not in app.
  • Clearing app cache and storage had no effect on this, still not allowed.
  • Android was not running private DNS or such that would interfere.
  • No new updates that would explain the sudden issue.

After digging around the logs I finally came over this log line:

[homeassistant.components.http.ban] Login attempt or request with invalid authentication from 192.168.87.1 (192.168.87.1). (okhttp/4.9.0)

Okay weird, why is this suddenly happening. A Google-search lead me to this thread on GitHub which perfectly explained the issue. In the thread it’s mentioned that it’s the user agent used by the android app (okhttp/4.9.0) which is a generic one being blocked in some blacklists in Nginx. Makes sense. In the thread it’s mentioned to disabling the user-agent filtering in Nginx, the closest setting for this I’ve found in the web UI of Nginx is block common exploits, there’s no mention of user-agent filtering anywhere. Disabling the common exploit blocking does ofcourse change nothing. Another comment in the thread also referred to /var/log/nginx/permanentban.access.log for troubleshooting, and though /var/log/ exists it’s completely empty for me, I’ve tried accessing it through ssh, smb and the file editor addon making sure all three has “full” access. Actually searching all folders through smb only shows me the \ssl\nginxproxymanager-folder.

Now I’m quite stumped, it seems I have found the most likely fault but I can’t progress on the issue as I’m not sure how to proceed.

Has anyone here experienced the same issue and would be able to help me fix it?

2

Hello @sondreen.

My comment on that GitHub thread specifically mentioned using OPNsense (free, open-source firewall). It has an NGINX plugin, and that plugin is basically using hard-coded values of User-Agents to block to generate its nginx config files:

# block based on User Agents - stuff I have found over the years in my server log
    if ($http_user_agent ~* Python-urllib|Nmap|python-requests|libwww-perl|MJ12bot|Jorgee|fasthttp|libwww|Telesphoreo|A6-Indexer|ltx71|ok
http|ZmEu|sqlmap|LMAO/2.0|ltx71|zgrab|Ronin/2.0|Hakai/2.0) {
      return 418;
    }

so mabye Nginx Proxy Manager that I think you’re using is doing it in some other way, or the issue is different. Might be worth checking on Nginx Proxy Manager forum.

1 Like
3

to anyone finding this issue we have now customized the user agent to avoid this behavior, You will want to be on at least beta 613 for the change which is currently found on github.

1 Like