Monocle Gateway throws Proxy error at startup on Win2012R2 Server [SOLVED]

Monocle

Here I am using the nslookup utility to validate the DNS hostname.

Here I am testing against my networks default DNS server/resolver:

pi@rpi3bp:~ $ nslookup 6d8e9885-afd1-461a-9857-8e9cbf14bf49.mproxy.io
Server:		10.1.1.1
Address:	10.1.1.1#53

Non-authoritative answer:
Name:	6d8e9885-afd1-461a-9857-8e9cbf14bf49.mproxy.io
Address: 10.0.0.6

Here I am testing against Google’s public DNS server (8.8.8.8) :

pi@rpi3bp:~ $ nslookup 6d8e9885-afd1-461a-9857-8e9cbf14bf49.mproxy.io 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	6d8e9885-afd1-461a-9857-8e9cbf14bf49.mproxy.io
Address: 10.0.0.6

So the record is there and valid for the IP address 10.0.0.6

Monocle

@spicymikey said in Monocle Gateway throws Proxy error at startup on Win2012R2 Server:

Regarding the local IP address. Yes I was throwing crap against the wall in the end and trying everything. Thanks for noticing that. I put it back to the public dns name registered on a GoDaddy DNS server.

No problem and once we have your local gateway working, you can certainly use private IP’s for the cameras.

Bad news is my local camera still doesn’t display the video stream from that camera. Not sure if you need to turn your gateway off first, but I turned mine back on, renamed the rtsp url back to using the public DNS name, and said “Show frontyard camera”. No joy.

I look in the log of the cloud hosted gateway and found your camera requests for “Front Yard”. Basically it was unable to connect to the RTSP port (554) at address frontyard-cam.kressahq.kressa.com. Is port 554 open on your router for public access and routed to the camera on your local network?

Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]: -------------------------------------------------
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]: INITIALIZE RTSP STREAM:  Front Yard
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]: -------------------------------------------------
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - NAME  : Front Yard
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - LABEL : PRIMARY
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - URL   : rtsp://frontyard-cam.kressahq.kressa.com:554/h264Preview_01_sub
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - UUID  : STREAM:64214234-714b-4f8d-8c7d-b381716d4957
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - SESS  : c3cf62fa-b8b8-4465-97f1-7872cac523c4
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - MODIF : Fri Jul 26 2019 15:54:40 GMT+0000 (Coordinated Universal Time)
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]:  - TAGS  : @tunnel
Jul 26 15:57:27 ip-172-30-0-231 monocle-gateway[13677]: -------------------------------------------------

Jul 26 15:57:28 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:28.385Z [INFO]  [107.130.182.161:48074 <BJglXiuzH>] RTSP CLIENT SOCKET CONNECTED
Jul 26 15:57:28 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:28.513Z [INFO]  [107.130.182.161:48074 <BJglXiuzH>] RTSP CLIENT ATTACHED TO STREAM: Front Yard (STREAM:64214234-714b-4f8d-8c7d-b381716d4957)

Jul 26 15:57:58 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:58.514Z [WARN]  [107.130.182.161:48074 <BJglXiuzH>] RTSP CLIENT SOCKET TIMEOUT
Jul 26 15:57:58 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:58.519Z [WARN]  [107.130.182.161:48074 <BJglXiuzH>] RTSP ENDPOINT SOCKET TIMEOUT [107.130.182.161:48074 <BJglXiuzH>]
Jul 26 15:57:58 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:58.519Z [INFO]  [107.130.182.161:48074 <BJglXiuzH>] RTSP ENDPOINT SOCKET CLOSED [107.130.182.161:48074 <BJglXiuzH>]
Jul 26 15:57:58 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:58.575Z [INFO]  [107.130.182.161:48074 <BJglXiuzH>] RTSP CLIENT SOCKET CLOSED
Jul 26 15:57:58 ip-172-30-0-231 monocle-gateway[13677]: 2019-07-26T15:57:58.575Z [INFO]  [107.130.182.161:48074 <BJglXiuzH>] RTSP CLIENT DETACHED FROM STREAM: Front Yard (STREAM:64214234-714b-4f8d-8c7d-b381716d4957)

You mentioned about this DNS entry you are creating, and i read that white paper you suggested. Your hunch is correct. I tried to ping that FQDN and it failed. Where are you trying to create this DNS entry? If you are putting it on your own public DNS server then I’ll need to add that to my DNS search list. if you are trying to inject it into my local DNS server, well, thats not going to work. You don’t have authority. I guess we have narrowed it down and this DNS entry issue must be the problem! Give me more direction on this

Its registered to public upstream DNS servers, so the DNS record should propagate to all public and ISP DNS servers. No, not trying to register anything into your private DNS – in fact, per Amazon’s requirements it must be a public DNS record.

Thanks. Robert

spicymikey

I do run part of my business from home and I have some test servers with company IP on them, so I do indeed have things locked down with a commercial grade Cisco ASA firewall. But i confirmed the rtsp port is opened for all devices behind the firewall.

I think it is the DNS issue you suggested ealier. An NSLookup to that domain name fails from inside my network. But I believe you when you say it is there. In fact, I checked it from my phone on an LTE connection and it did indeed respond with 10.0.0.6.

I have to dig some more, unless you have some hints. It indeed could still be the ASA blocking this local IP address. This PC has a publicly registered Static IP. Is there a way to use the public IP on your DNS entry and let my firewall do the NAT for us?

Monocle

@spicymikey

I do run part of my business from home and I have some test servers with company IP on them, so I do indeed have things locked down with a commercial grade Cisco ASA firewall. But i confirmed the rtsp port is opened for all devices behind the firewall.

Both RTSP and HTTPS (443) need to be able to route on your local network. The Alexa devices will connect to the gateway instance on port 443 and the gateway will connect to your IP cameras on their RTSP ports (554 by default).

I think it is the DNS issue you suggested ealier. An NSLookup to that domain name fails from inside my network. But I believe you when you say it is there. In fact, I checked it from my phone on an LTE connection and it did indeed respond with 10.0.0.6.

I agree. At least this is the first roadblock we have to overcome before trying to diagnose/test anything else.

I have to dig some more, unless you have some hints. It indeed could still be the ASA blocking this local IP address.

I suspect its your DNS server for your network. It probably secures against DNS REBINDING (DNS hosts resolving to local IPs), especially if its a commercial system.

This PC has a publicly registered Static IP. Is there a way to use the public IP on your DNS entry and let my firewall do the NAT for us?

Absolutely. As long as port 443 is exposed to the Internet, you can override the default detected IP address using a custom configuration properties file.
See: https://monoclecam.com/monocle-gateway/custom-configuration

Basically you will change the rtsp.register.host line to rtsp.register.host=X.X.X.X where X.X.X.X is your public IP address. When you restart the service, it will register your public IP address for that DNS host. It may take a few minutes for DNS propagation changes to occur. By default there is a 5 minute cache expiry on these DNS records. Then after a few minutes, do a nslookup on the host and see if its working for your public ip.

Thanks, Robert

Monocle

@spicymikey

I went ahead and disabled the cloud gateway server to avoid any conflicts or confusion for further testing.
We know the Alexa devices on your network will work with a publicly resolvable gateway server and we did validate the demo stream is working using this hosted gateway. So I think we are to the point of just getting your local gateway working now.

Thanks, Robert

spicymikey

The eagle has landed. :)

You had posted a few messages that I had to review. One of them suggested adding a local DNS entry to resolve this name. I did that and the stream is now displaying.

Thanks so much for the help. I would not have been able to navigate through this without your help. I’m still thinking the problem is the ASA rather than the local DNS server. The DNS server is a non-authoritative server for our company domain name. I use it to resolve devices that must be accessible from inside and outside the firewall. It is programmed to just pass requests out to 8.8.8.8 for any zones it does not manage. Clearly myproxy.io was not on my DNS Server so I’m not sure how it could have interferred. BUT, I will pursue further to find out the difinitively what blocked us.

Unfortunately, I doubt the average person has a local DNS server running behind their firewall. So creating a Primary Zone on my local DNS server for your MyProxy.io, and adding an A record for that FQDN, will not be an option for most.

Monocle

@spicymikey

Great News! Glad to hear its up and running!

These more complex networking issues mostly come into play with more sophisticated and commercial (secure) network environments. The typical home user does not often have this issue unless they are running a custom/advanced router like PFSense or Fritzbox. And those types of routers often have some provisions for overriding DNS hostnames.

It’s perfectly fine to leave it as-is with the custom DNS entry – the only thing to remember is to update it if you change the token file or if the local IP changes. Of course figuring out the root cause sounds like a fun little exercise just to fully understand it :-)

You should also now be able to go back to using the local IP for the camera streams and not have to expose it over your Internet connection.

Thanks, Robert

spicymikey

If I figure out the root cause I will post it here for you and others.

I actually don’t normally use the local IP. I just did that for testing. The goal is to be able to monitor the property from anywhere, not just inside the house.

I just made a $50 donation on your home page as a thanks for staying with me on this one. Thanks again!

Monocle

@spicymikey

Thank you for your generous support!

Here are some other threads on support for Monocle Gateway across multiple homes (remote locations)

If you want to access camera’s via Alexa from remote locations, basically, you will want to use the public IP you had mentioned and allow Monocle Gateway to host on port 443 on that public IP. See my previous post in this thread for more details.

Thanks, Robert

spicymikey

Hey Robert,

I have a followup issue I wanted to report. Maybe I should open another thread, but the camera fails to stream sometimes. it’s more than once in awhile. Pretty much 1 in 3. I can’t attach a text file. It says I don’t have enough privileges. I don’t want to just dump it in the post. Too much text but I have it here if you need it.

The only thing I can say is that when it fails, the “end point” throws a 401 and “unauthorized”. The debugger is showing the IP address of the Echo Show 5, but not certain if that is the endpoint throwing the error. See below

2019-07-27T16:24:20.675Z [DEBUG] [10.1.0.11:45270 <SyTnclcGH>] [ENDPOINT RESPONSE] <-- [401 (Unauthorized)] <cseq=1> (session=undefined)
2019-07-27T16:24:20.679Z [TRACE] [10.1.0.11:45270 <SyTnclcGH>] [ENDPOINT RESPONSE] <-- [HEADERS] {
“cseq”: “1”,
“date”: “Sat, Jul 27 2019 16:24:16 GMT”,

Monocle

@spicymikey

See if you can upload the log now. I adjusted some forum permissions.

Thank, Robert

spicymikey

@Monocle said in Monocle Gateway throws Proxy error at startup on Win2012R2 Server [SOLVED]:

@spicymikey

See if you can upload the log now. I adjusted some forum permissions.

Thank, Robert

Same error. “You do not have permissions for this action”

Monocle

@spicymikey

Well, the settings look correct … maybe try logging out then back in. I’m too familiar with the forum admin yet so it could still be an issue on my side.

Thanks, Robert

spicymikey

Here’s the log…

[0_1564258669283_EchoShow5_Reolink420_Success followed by failure.txt](Uploading 100%)

spicymikey

@Monocle
By the way, I think I understand what is happening, although not why it’s happening. The closing process is not resulting in a clean termination of everything. Maybe a connection is being left open, etc. The failures are occuring when I try to say “show camera” again right after closing it. Something i was doing a lot trying to test things. But if I wait 5 minutes, it seems to show the camera again reliably.

If this is a bug on the Amazon side then not much we can do about it, but if its a flaw in Monocle, hope that is a clue to help track it down.

Monocle

@spicymikey
I don’t think the upload made it. If it won’t work, then you could also use Pastebin, I have used that service before then just copy the link to the forum thread:
https://pastebin.com/

Thanks, Robert

Monocle

@spicymikey said in Monocle Gateway throws Proxy error at startup on Win2012R2 Server [SOLVED]:

@Monocle
By the way, I think I understand what is happening, although not why it’s happening. The closing process is not resulting in a clean termination of everything. Maybe a connection is being left open, etc. The failures are occuring when I try to say “show camera” again right after closing it. Something i was doing a lot trying to test things. But if I wait 5 minutes, it seems to show the camera again reliably.

If this is a bug on the Amazon side then not much we can do about it, but if its a flaw in Monocle, hope that is a clue to help track it down.

I have seen some camera’s behave this way. Are you using @tunnel or @proxy for this camera? @proxy will try to leave the connection open for a few minutes just in case a new request comes in for the stream.

Thanks, Robert

spicymikey

@Monocle
I’ve tried it with @proxy-tcp, and without it. I’m ALWAYS using @tunnel per the documentation on the website. I can mess around with different combos and see what happens

Monocle

@spicymikey

If using one of the @proxy tags, then you can also combine that with @hangup to forcefully disconnect immediately with the Alexa device disconnects the TCP socket. However, @hangup has no impact on @tunnel connections.

I noticed on another thread you mentioned this was a Reolink camera. I have seen that behavior before on Reolink cameras. It could simply be some bug or issue with the camera itself. But yes, it only manifests when making back to back connections and seems to work fine under normal use when your only periodically ask for the stream.

Thanks, Robert

spicymikey

@Monocle said in Monocle Gateway throws Proxy error at startup on Win2012R2 Server [SOLVED]:

@spicymikey

If using one of the @proxy tags, then you can also combine that with @hangup to forcefully disconnect immediately with the Alexa device disconnects the TCP socket. However, @hangup has no impact on @tunnel connections.

I noticed on another thread you mentioned this was a Reolink camera. I have seen that behavior before on Reolink cameras. It could simply be some bug or issue with the camera itself. But yes, it only manifests when making back to back connections and seems to work fine under normal use when your only periodically ask for the stream.

Thanks, Robert

Thanks for the advice. I think adding the @hangup solved it. Is that documented anywhere? First I’ve heard about @hangup, but I may have missed it.

For me with the Echo Show 5, a Reolink RLC420, and the Monocle Gateway, changing to these tags worked to eliminate the problem. A few combinations worked, but the most minimalistic combo is what I will stay with

FROM: @ntpnow, @tunnel, @proxy-tcp

TO: @hangup, @proxy