Unreliable SSL connection with GH

Hello,

I am running a HA install with port 8123.

I am also running an Apache proxy server on port 8124 with SSL. It works; I can reach https://URL:8124, login and perform actions in the HA web page. I’m using dyndns instead of DuckDNS.

I have created the Google Action, the API key and was successful in adding the [test] to Google Home. The single light I exposed is now available in GH.

The problem is that most of the commands (both voice using GH Mini and using the GH app directly on a phone) get lost. Some get through and execute properly, but many don’t.

Wireshark gives varying results, but one case is where a single packet is received from Google servers and no response ever comes from Apache / HA. Since I can wireshark on eth0 (8124) and lo (8123), I can see that some traffic (including the single packet) is not forwarded from eth0 to lo. I’m suspecting a SSL problem, but I don’t know how to debug this. Neither Apache nor HA provide any debug output.

I also tried directly connecting to HA with SSL, i.e. removing the Apache proxy and hooking up HA to port 8124. Interestingly, I get the same result.

As a side note: I use Apache as proxy because the SSL prevents local access to HA with local DNS names.

I am a bit out of ideas and I’d like to have some tips, suggestions (or maybe even the solution…).

Thanks,

I found the problem.

Assuming it was a TLS / SSL issue, it could only have been caused by missing packets from a particular server. A quick look at iptables -v showed that one rule acting on 66.249.0.0/16 was causing packets to be dropped from 66.249.93.210.

(This entry was automatically added several years ago as a result of an attempt to access the system. Probably it was in good faith, i.e. robot, but that got him banned forever.)

Combine this with Google’s distributed architecture / fallback strategy that uses multiple IP addresses and there’s trouble that’s hard to diagnose. (66.102.9.186 was used for commands that were successful.)

Sorry for the noise.