Echo Show 5 not working.....
-
Couldn’t help myself and installed it now. Working fine on the RPI, so it was the docker networking. Whilst it would have been neat to keep it all together with my other home automation stuff, the RPI works fine and I’ll leave it.
Thanks a lot for your help, the answer was right there staring me in the face the whole time!
-
One snag on the RPi plan. The gateway will need direct access to port 443. Meaning it can’t sit behind an Apache or NGINX server as a proxy. Those web servers won’t proxy RTSP properly as well as the gateway presents it own SSL certificate fully managed inside the gateway. So it will need a dedicated IP interface. You could (via Linux config) add a secondary IP address to the network interface on the RPi and then have Apache use one IP and Monocle Gateway use the other. Some custom configuration for the gateway would need needed, but that is pretty minor.
Seems like the Docker approach could be made to work … somehow?
-Robert
-
My apache server is proxying the gateway no problems (it’s on another box) using the mod_ssl ignore settings:
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyCheckPeerCN offThis tells apache to ignore downstream certificates as my apache server does the SSL termination.
My setup is an apache virtual host with it’s own certificate for monocle --> gateway on the PI --> unifi video container.
I’ve got no doubt I can work around the docker, there’s a bunch of good stuff on various forums on how to hack around the MACVLAN issue but to be honest it’s all just too hard to remember the next time I have to troubleshoot something, compared to the PI.
-
OK, I have not personally fully tested trying to run Apache as a proxy server. So if there is a way to get it fully working, I would love to understand the steps.
If Apache is performing the SSL termination, then are you using a custom FQDN setting in the Monocle Gateway’s properties to override the auto-generated DNS hostname? If not, then I don’t understand how Apache is delivering the correct certs to the requesting Alexa devices.
Thanks, Robert
-
@mattp Will keep watching this space to see if you happen to come across a path forward on this. Fortunately I have enough hosts to run Docker on that one of them has an open port 443 to use against host networking. But it would be nice to define a different port. I expect it also has something to do with the Amazon devices not having any flexibility on that port as well. It’s not expecting to have something in the middle :)
Thanks!!
_DS
-
The ONLY requirement for port 443 is Amazon. They only allow Alexa devices to establish connections to RTSP encrypted endpoints on port 443. This was not always the case, but is now with most current FireTVs and Alexa Shows. They also only allow connections to publicly resolvable DNS hosts, no direct IP addresses or private DNS hosts.
-
I posted more detail about my Docker image using macvlan on a Synology NAS here:
https://forum.monoclecam.com/topic/255/using-synology-surveillance-station-and-dockerHope it helps!
Thanks, Robert
-
@lux4rd0, to Robert’s point my config works because Amazon is expecting a valid certificate and 443 connection.
This is more an Amazon thing as I’ve got the same requirements on some other automation work I’ve written custom Alexa skills for. In each case 443 for any API connections is the go.
To your question, Robert, the Apache proxy works fine as from what I can see in the traffic it’s only accepting http connections to 443 and isn’t proxying the RTSP stream, which is going direct from the echo show to the internal server via the DNS rebind?
I’ve posted a pic of my config to demonstrate…
Apache proxy is working as per the above directives and using a virtual-host for the monocle.<myFQDN> and a valid certificate for that domain.
Either way this setup is functionally the same as docker and macvlan with the relevant work around to attach to my host’s network (as the docker container for unifi, and the apache server run on the same box.) You could do the same with VM’s as well if that’s your cup of tea.
At least this proves the following:
-
Apache Reverse proxy works (providing you use the directives I listed in my previous posts)
-
Docker macvlan can work, but just remember without working around the designed docker behaviour if your monocle gateway is trying to communicate with your RTSP server on the same IP as the host running Docker, it won’t work.
-
Unifi-Video RTSP streams on their weird port work, so the assumption there is that non-standard RTSP ports are ok.
-
Nothing is ever simple and I seem to find a way to complicate everything…
-
Me and Alexa are friends again.
-
-
@Monocle Have added the working reverse proxy conf for my setup in case it helps anyone as well:
#Virtual Host Setup in Apache as Monocle expects to use port 443 #This setup uses LetsEncrypt (https://letsencrypt.org/) and a dynamic DNS setup with a host entry for monocle #Either add to your apache conf file or create a new monocle.conf file and include that in the bottom of your apache conf. <VirtualHost *:443> ServerName monocle.<your FQDN here> SSLProxyEngine On SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off SSLProxyCheckPeerCN off ProxyPreserveHost On ProxyRequests off ProxyPass / https://<address of monocle gateway>:443/ ProxyPassReverse / https://<address of monocle gateway>:443/ # Haven't tested if you need this for Monocle, but in prior experience not changing websocket traffic also plays havoc on API calls. I've left it in but remove # and experiment as you need. RewriteEngine on RewriteCond %{HTTP:Upgrade} =websocket [NC] RewriteRule /(.*) ws://<address of monocle gateway>:443/$1 [P,L] RewriteCond %{HTTP:Upgrade} !=websocket [NC] RewriteRule /(.*) https://address of monocle gateway>:443/$1 [P,L] # The below comes from letsencrypt and should be generated automatically if you follow the instructions on the letsencrypt web site # I've left this in to show where you'd put your certificate files SSLCertificateFile <path to your SSL cert file.pem> SSLCertificateKeyFile <path to your keyfile.pem> Include <your apache ssl conf file here> SSLCertificateChainFile <path to your ChainFile </VirtualHost> #Redirect anything to https <VirtualHost *:80> ServerName monocle.<your FQDN here> Redirect permanent / https://monocle.<your FQDN here>/ </VirtualHost>
-
Thanks for all the details. I’m still sorting it all out in my head, but do have a couple of notes.
When using the Monocle Gateway with a camera that is tagged with any of these:
@tunnel
,@proxy
or@proxy-tcp
the RTSP stream is initiated from the Alexa device directly to the Monocle Gateway. Not directly to the camera or in your case the Docker Unifi Video server. (So it would be the Monocle Gateway that actually communicates RTSP to the Unifi server.)I see now that you are generating your own LetsEncrypt certificate and that is allowing you to terminate it on your Apache server. That makes sense now. Just a note, if you already have your own domain name and SSL certificate, you should be able to override the DNS hostname that Monocle Gateway uses. See the Monocle Gateway Configuration topic here. There is no magic here, you just need a publicly resolvable DNS host entry that points to an IP address where the Monocle Gateway is listening (or via Apache proxy in your case.)
I was under the impression that the RTSP protocol was not able to be proxied via an Apache or NGINX server. But I guess I got that wrong somewhere. Maybe the TCP only streams are OK, not sure it would work with UDP streams. I’ll have to play with this setup again when I have some time. The SSL termination could be difficult for some people, but for advanced users this could be a nice alternative.
You probably don’t need to worry about the proxy handling any web sockets, at least not at this time – that may change in the future as we plan on adding a Monocle Gateway Web GUI with access to logs, etc. Today only outbound secure web sockets are used to communicate with the Monocle servers over the Internet.
Thanks, Robert