Google TTS with split DNS in the LAN

I’m running HA in a docker container under https://home.mydomain.com:8888. I’ve purchased an externally trusted certificate and I’m using split DNS running an internal DNS server, so that:
At home on my LAN: home.mydomain.com --> 192.168.123.123
Away from home: home.mydomain.com --> 82.123.123.123 (external IP router)

Next to that I have forwarded port 8888 on my firewall/router, which is a solution that works for everything I make externally accessible.

I couldn’t get my head around why Text-to-Speech with my Google devices isn’t working, since the mp3 files are nicely created in the /config/tts folder and are playing using a browser. But then I figured out that Google devices have hard coded (external) DNS servers, so that now:
At home on my LAN: home.mydomain.com --> 82.123.123.123 (external IP router)

So that’s why my Google Home device ‘bleeps’ when it starts playing, but no text is heard. My Google Home is knocking on the outside interface of my router from the LAN, which is obviously not accepted by my router. When I make it play the mp3 file using the internal IP of HA, it works, but that is no option for TTS, as I cannot bind an externally trusted certificate to an IP-address or internal domain.

That leaves me thinking; how is it possible that this is even working with the duckdns.org standard solution? In my logic, the ha.duckdns.org is registered with the external IP of the internet connection, which results in the same issue I am having right now (Google Home knocking on the outside interface)?

Ok, I’ve solved it. This phenomenon is called hair pinning or loopback. Traditionally a firewall doesn’t allow this and you have to allow this. For my Sonicwall, this was done using the following article:

https://www.sonicwall.com/support/knowledge-base/170505780814635/

Oh, and blocking the Google device from accessing external DNS servers using a deny firewall rule works as well :smiley: That forces it to use the internal DNS server, supplied by DHCP :slight_smile: