Can Monocle gateway work from a 2nd house with appropriate firewall port(s) opened? [ANSWERED]
-
There is a really effective way around this. Consider creating a VPN between the two homes. That way Alexa will think she is dealing with a single contiguous network and your voice commands will work.
-
That is a great idea, but would require me to buy a newer/better/more stable router at the vacation house which would be more expensive than a Raspberry Pi :=) I’d also need to change from using 192.168.1.x at both houses.
In thinking through the complications of my idea, if the myproxy.io URL (today to the local IP address) could be created as a cname dns record to something I control (e.g. through dyndns.org or something similar), would the SSL connection still work from an Echo? If it does, great. If not, then my suggestion is much harder and perhaps not practical since the whole reason we need gateway for the Echo Show 5 is because Amazon requires the SSL connection.
-
Yes it can be made to work with some specialized configuration.
In time we certainly plan on supporting multiple instances of Monocle Gateway running at separate locations to handle your exact use case. At least its in the roadmap … However … at the present time support for multiple gateways is not available. If more than one gateway is detected on your account, the last one connected wins and all requests are sent to it. (as a side note, multiple gateways are supported today to handle failover conditions at a single location.)
I think you have the following options:Option 1: VPN Tunnel
As @vmsman suggested, you can certainly run a VPN tunnel between your two local networks. Clearly this has the advantage of keeping things more secure and limiting the number of open ports you expose over the Internet. This is probably the best option – but is perhaps a bit more complex.Option 2: 2 Separate Monocle Accounts and 2 Separate Gateways
This is probably the least attractive option, but you could create two separate Monocle accounts and configure each of your cameras under each account then have a monocle gateway running at each location each using a discrete account (token). This of course requires duplication of all configuration which could get annoying. You would also have to use separate Amazon/Alexa accounts for each location to link to the separate Monocle account, so this really make this solution ugly.Option 3: Expose Monocle Gateway over the Internet
You could expose port 443 on your router to the Internet and point it internally to your single Monocle Gateway instances. Second you would have to configure Monocle Gateway via a properties file to override the default detected IP address with the public IP address assigned by your ISP. See the configuration details here: https://monoclecam.com/monocle-gateway/custom-configurationIs it possible to have Monocle Gateway specify a URL for an external IP address, such as another dyndns.org address, so that I could open yet another firewall port to allow the Echo Show 5 in one house access the Monocle Gateway running in a second house?
Yes, in theory it should be possible to use a Dynamic DNS provider, however, it would also require you obtaining your own SSL certificate for your custom DNS hostname and configuring Monocle Gateway to use custom certificates. If this is a path that you would like to pursue, please let me know. We may have to make some changes to the Monocle Gateway to allow overriding the certificates.
NOTE:
When attempting to stream over the Internet, if you have any cameras using the@proxytag, those may have to use@proxy-tcpinstead to avoid UDP streaming and force them to use TCP streaming.Thanks, Robert
-
Your
cnamesuggestion is interesting. Basically when you ask Alexa for a camera stream, we provide her with the unique mproxy.io DNS hostname to resolve to your local Monocle Gateway instance (when the camera is tagged with either@proxy,@proxy-tcp, or@tunnel). So you would need the DNS to resolve to your local gateway instance in each location. If the IP address of the gateway were the same (fixed, static) in each location, then maybe you don’t need acnameat all? If the IP addresses were different, you would need each local network to resolve the DNS record to the correct IP for the local gateway instance. Well … you could even pull this off today if your router allows you to override a DNS entry. I know I can do this on my PFSense router. I can put in DNS override hosts and dictate what it will resolve to on each network.There is one caveat. The Monocle API server handles multiple gateway instances connected to your account with failover behavior where one instance gets promoted and all other get demoted until needed. I think we could easily add some new configuration to allow for multiple concurrent gateway instances if this is something you want to pursue and help test out.
ON SECOND THOUGHT
On second thought … the DNS overrides and independent gateway instances still would not allow you to access the IP cameras behind each private network from the other. So I think the single gateway solution is still the best option. (#3 above)
Thanks, Robert
-
@carteriii said in Can Monocle gateway work from a 2nd house with appropriate firewall port(s) opened?:
In thinking through the complications of my idea, if the myproxy.io URL (today to the local IP address) could be created as a cname dns record to something I control (e.g. through dyndns.org or something similar), would the SSL connection still work from an Echo? If it does, great. If not, then my suggestion is much harder and perhaps not practical since the whole reason we need gateway for the Echo Show 5 is because Amazon requires the SSL connection.
I don’t think a
CNAMEwill work unless the SSL certificate included it when it was generated as a secondary name.However, if you wanted to use your own SSL certificate, we could add provisions for you to simply use your own public DNS record and SSL certificates completely bypassing the
*.mproxy.iodomain. This might be useful if you are hosting the Monocle Gateway publicly on port 443 to point to your Dynamic DNS hostname to dynamically handle public IP address changes from your ISP. Otherwise, any public IP address change from your ISP would result in needing to manually re-configure the Monocle Gateway. -
I’m not sure if any changes have been made to Monocle since the previous post, but I did have this working a short while back. My setup is 3 properties all using the same Amazon account, with various Amazon tech and cameras at each. A unique RTSP port is configured on each camera and ALL routers forwarding ALL these ports internally and dynamic DNS being used to accommodate any changes in external ip. This allows me to move cameras between properties without changing any configuration. However I was able to ask Alexa to show me a Hikvision feed on an Echo Show 10 at each location regardless of where the source camera was. I have since implemented the gateway on a RasberryPi at one property to allow tech such as a FireTV 4K Cube to work. With this setup I can still view all cameras from this device, but I suspect now not from Amazon devices in the other properties. I’ve not yet had cause to try it, but came across this post thinking I might need to forward 443 in some way or setup some sort of static routing or use a VPN, but the later requires equipment at each property that I don’t have, in fact there is nothing except routers at the remote properties, so I was hoping some sort of routing and port forwarding could be used. However the point to note is that full flexibility was possible when not using the gateway.
-
On thought is that perhaps I could setup two different feeds in monocle for each camera, one using the gateway and one not. Then in properties that don’t have the gateway, only use Amazon tech that does not require it, and only ask them to display the non-gateway feeds.
-
@VBasys said in Can Monocle gateway work from a 2nd house with appropriate firewall port(s) opened? [ANSWERED]:
On thought is that perhaps I could setup two different feeds in monocle for each camera, one using the gateway and one not. Then in properties that don’t have the gateway, only use Amazon tech that does not require it, and only ask them to display the non-gateway feeds.
Yes, this should work fine. Except you would only be able to access the cameras behind the Monocle Gateway at that location unless you either exposed port 443 to the Internet or had a VPN connection between the properties. If you expose port 443, then you would also need to make some tweaks to the Monocle Gateway properties file to use your public IP address or a public DNS.
Another option would be to setup your Monocle Gateway on a public server such as Linode/Amazon EC2 and have each of the camera’s publicly accessible to this gateway.
If you are deeply interested in finding a solution, in the new year we could experiment with trying to create some concept of multi-location awareness that supported multiple running gateway instances. Or perhaps some inter-gateway bridging/proxy where gateway instances could proxy the camera connection to other gateway instances.
Thanks, Robert
-
@Monocle Many thanks for the response Robert I will certainly have a play with exposing 443 and tweaking the Monocle Gateway properties file to use my public public DNS. I was hoping something exactly like this might be possible. I did think of running the gateway on Amazon EC2 to have each of the camera’s publicly accessible, but got bogged down with all the various features and costings, so thought I would try the port 443 tweak first. However I’ve been looking for an excuse to get into AWS for a while, so may well give that a go later. Amazon do seem to offer a basic signup with various features permanently free and others free for the first year if under certain usage limits, but I couldn’t quite work out if running monocle would be free, cheap or expensive. I am hoping free because I assume there is only a small amount of traffic through the gateway at the start of each request with nothing through the gateway there after. I did wonder if this might even allow yourself to develop some sort of globally shared gateway with little to no running costs but I’m guessing you would have already done that if possible. Anyway I’ll have a play with 443 and report back in due course.
-
I agree on trying to test it out locally before moving to the cloud (if possible).
You could certainly use the Amazon AWS EC2 instances eligible for the free tier (1 year). The Monocle Gateway does not need much in terms of processing power or memory. The network usage would mostly be limited to the active streams when you are viewing them via Alexa. If you decide to go the AWS route, after your free period expires you can use the option to pay for a reserved instance and pay for it all up front (1yr or 3 yr) to save a significant amount over the on-demand instance pricing.
https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/
For example a T3-micro instance can cost as little as $103 for 3 years. A T3-nano is only $51 for three years. I suspect the nano instance would be sufficient but you may just have to try it out to see. The newer T4G series instances are even cheaper.
Thanks, Robert
-
Hi Robert, after much experimentation I am pleased to report that tweaking port 443 actually seems to be working perfectly.
With only a single gateway instance running at one property, I am able to display streams from any Hikvision cameras on any of my Amazon devices, regardless of where the cameras or Amazon devices are located.
As we had hoped, all one needs to do is set the rtsp.register.host entry in the monocle.properties file to ones external IP address and setup a port forward on your router of 443 to the device you are running the gateway on.
Initially I made the mistake of providing a dynamic domain name instead of my external ip, run the gateway and found my local amazon devices worked, and saw (what I thought) was the correct address being resolved in the various debug/traces, which tricked me into thinking it had been accepted. However after travelling around I still found that none of the remote amazon devices worked with gateway streams. So I then played around in the dark a bit and opened a few extra ports that I could see being used, which of course had no effect, but by further studying the traces I gained a better understanding of what was going on and realised I was rather stupidly providing my own dynamic domain as the IP address for the proxy dynamic domain, and the reason why everything still worked locally and looked good in the traces was simply because my domain was being ignored and the last valid setting was still being used. So I then thought well that rtsp.register.fqdn seems appropriately named, maybe that’s exactly what I’m looking for, so I set it to my dynamic domain, but the gateway wouldn’t even initialise properly. So eventually I just used my external IP address for the host value, and everything suddenly worked like a dream.
Of course I will have to keep updating that address as and when my ISP assigns me a different one, but to be honest that’s not very often, and I can always get a fixed IP again (had one for years but dumped it a while back) or I could write a little script to run in the background to update the properties file and restart the gateway as and when necessary. However I wonder if this might not be a very useful gateway feature, and I’m even still thinking the fqdn setting is exactly this, after all it seems to replace the unique.mproxy.io domain which resolves to the same address, but like I said I couldn’t get this to work at all. So if the fdqn setting is indeed for for something else, then perhaps in the future, you could allow us to specify our own dynamic domain for the gateway to use, or at least have the gateway monitor it and update the host value as and when the domains ip changes.
One really useful trick to note, it was a pain to keep travelling between remote properties to test every little change out, until I realised all I needed to do was create a few routines in Alexa to display the various cameras on the various remote devices, then sit back and watch the gateway trace as each routine was run. On that point someone here asked if they could get a stream up on a device without asking Alexa to do it, well you can to a point, by creating routines to mimic what you would say to each device, then running them manually via the app (If I find that post I’ll pop a response up accordingly).
-
For anyone using the gateway that wants to view any camera from any device at any location, this is the setup that works for me…
I use one Amazon account across all properties.
I use a unique dynamic domain name for each camera, note that www.noip.com are the only ddns service I can get working on Hikvision cameras.
On each router (at each property) I configure every camera with a unique fixed internal IP address, say 5 cameras at 101, 102, 103, 104, 105.
On each router (at each property) I forward a dedicated RTSP port for every camera, for example 5441 to port 544 of camera 101, 5442 to port 554 of camera 102, and so on.
In a similar way you may also want to open up some dedicated camera management ports and also restrict this access to certain ip addresses.
I do all the above to allow me to move cameras between properties without changing configuration. If you are not going to move your cameras then you only need to configure the ports on each router for the cameras that are always connected to them.
On each camera I created a special user account with view only permissions for use by Monocle.
In Monocle I created the cameras with their respective RTSP feed urls, for example rtsp://camera1.ddns.net:5441/Streaming/Channels/102.
In the above URL camera1.ddns.net is the dynamic domain, 5441 is the dedicated RTSP port reserved for this camera, 102 specifies the cameras second stream. I use first, second or even third streams on the various cameras, with various resolutions, depending upon the processing power of each camera and the broadband speed at each location. I would suggest you start with 640x360 if available because it’s a nice low resolution with 16x19 ratio that works well on all Amazon devices, then up the resolution later when you have everything working reliably. I would also suggest you disable any sound as well to start with as this can cause issues. Note that on the latest Hikvision cameras with three streams, you don’t have much choice of resolution on the second stream, they limit you to just a few low resolutions, but the third stream is not limited so you can choose say 1080p on that while keeping the main stream at max for other uses. I have a projector with Fire TV Cube so like to keep the streams high for the big screen. However you could always setup a camera in Monocle for each stream and just ask Alexa to show you whichever works best on that particular device.
Once the cameras are configured in monocle don’t forget to add them using the Alexa app.
At this stage, depending upon what Amazon devices and cameras you have, all might work for you. It did for me to a certain extent, some cameras worked fine on some devices, for example I could view them on an Echo Show 10 located at any address, but I certainly could not view any camera on a Fire TV 4K Stick or a Fire TV 4K Cube because these device require the Monocle Gateway.
Initially I installed the gateway upon an Apple iMac but could not get it to work, probably because there are other programs using port 443. However I had a RasberryPi not being used anymore so decided to install the gateway on that instead, which is a much better solution anyway because it can be dedicated to running the gateway (no port conflicts) and run 24x7x365 without sleeping. This turned out to be very easy, I simply followed the Monocle guide and had it up and running in a couple of minutes, so I would reccomend this route.
Next add your @tunnel tags to the camera configurations in Monocle to make them use the gateway.
Now if you only ever want to view camera feeds on Amazon devices located within the same network as the gateway then you’re done.
But if you want to view any camera from any device at any location, then you need to forward port 443 on the gateway’s router to the device that is running the gateway.
Then follow the Monocle guide on a custom configuration and edit the monocle.properties file to set “rtsp.register.host” to your external IP address (don’t forget to remove the # comment identifier at the beginning of the line).
Stop the gateway and restart it to register the change.
You may need to wait a little while to allow this change to propogate across the domain name system. On a RasberryPi you can check this by using the host command to check your unique fully qualified domain has updated. First find your unique fully qualified domain by using “sudo monocle-gateway —tail” to examine the gateways output. You will see an entry under “MONOCLE RTSP SERVICE - INITIALISED” looking something like “FQDN = 6f5eb25a-82e1-3c8f-9a14-bcf1291bdbf2.mproxy.io”. You will also see a HOST entry with your updated address, this should be what you set in the file, but it might not yet have propagated fully. So to be absolutely sure, copy the domain name and exit the trace with Control+C, then type “host “ and paste the domain name just copied. For example “host 6f5eb25a-82e1-3c8f-9a14-bcf1291bdbf2.mproxy.io”. The output from this command should be your external IP address. If not wait until it is.
Once done you should be able to view any camera sited at any location from any device at any location.
If your external ip address changes, then you have to update the monocle.properties file accordingly and restart the gateway. There may be a better way to do this now or maybe in the future but I will let Robert come in on that.
-
With regard to being able to specify ones own dynamic domain, I am not an expert on these things but having read through these posts again, I am wondering if we could alleviate any requirement for a certificate by simply getting the gateway to monitor such a domain and change the host address accordingly?
-
With regard to forwarding port 443 to the gateway running on a raspberrypi I forgot to mention the importance of configuring both your root and user accounts properly with strong passwords and suggest you use something like a managed switch to isolate the gateway device from other more important equipment.
-
A couple of other points worth a mention…
When forwarding an RTSP feed on your router choose the TCP protocol (not both TCP and UDP).
When changing the resolution of a camera you not only need to update the monocle configuration but you also need to delete and re-add the camera in Alexa.
