Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Cloud Connect Help
-
Hi @cmason
Have you set up a wildcard DNS record for *.subdomain.hostname?
Is your Certificate a wildcard certificate?The proxy basically routes guid.subdomain.domain -> localhost:"client web port" . I have never seen this before where you get a guid.mangoHTS### URL. Probably cause it's not common to set up an HTS as the CC server.
Please go to administration --> system settings -> ES configuration and change the hostname to your public hostname. I believe that will fix the URL issue. -
This post is deleted! -
@mattfox said in Cloud Connect Help:
settings as well. since ES units run on port 2222, you'd have to configure port forwarding if yo
The reverse proxy will setup port forwarding for both web and ssh ports so that you will be able to access both from your CC server. You will not need to setup port forwarding on the mangoHTS side.
If you want to ssh into your mangoHTS you will ssh into the CC server and then run the following cmd:
ssh -p 37001 mango@localhostthe CC server will route that to the mangoHTS on the reverse proxy connection. -
Was what i was referring to -
The proxy basically routes guid.subdomain.domain -> localhost:"client web port" . I have never seen this before where you get a guid.mangoHTS### URL. Probably cause it's not common to set up an HTS as the CC server.
Please go to administration --> system settings -> ES configuration and change the hostname to your public hostname. I believe that will fix the URL issue.Yes this did fix the issue of the url that was given to the new window.
The new windows now opens up with 'GUID.subdomain.domain'
However I've got a new problem. The window just opens and directs straight into the servers UI from where I just came from. Basically just loops it around on itself.
Have you set up a wildcard DNS record for *.subdomain.hostname?
Not technically but the subdomain.domain is resolving to the domain. the subdomain part is really so the reverse proxy can identify it.
Is your Certificate a wildcard certificate?
Yes
-
I suggest trying to get it working without the complexity of your reverse proxy first.
You will need a wildcard DNS record that resolves to your MangoHTS server.
Basically, when you open the link the traffic will go as below
GUID.subdomain.domain --> "CC server"-->.localhost:37000-->MangoHTS:8080 -
@craigweb said in Cloud Connect Help:
I suggest trying to get it working without the complexity of your reverse proxy first.
Ok I'll try that out. What's the recommended way to secure the connections then between the mango and the internet? The main reason I was using the reverse proxy was for security.
@MattFox Are you using cloud connect with the reverse proxy? If so is that using apache on the same machine as your mango like I've seen you describe in some of the other threads?
-
Ive just dropped apache in favour of Nginx because it has better support for proxy headers.
Happy to help you with that.
In the meantime we can focus on plain http with the mango running on port 8080 then using the proxy engine to handle all requests and merely serve them to mango.
Im going to bed now so Ill assist with that tomorrow. In fact I think Ill write a tutorial...Fox
-
@cmason
Mount your certificate on the mango web server so all HTTP traffic is encrypted.
Mango webserver has a rate limiter on unauthorized API requests.
CC server uses ssh so those sockets are all encrypted.
The persistent data source/publisher uses encryption as well. you can choose the size of the shared key.
Use a firewall to block all unused ports.I may be wrong but how I don't see how the reverse proxy will make it more secure.
-
Thanks Guys. I followed what you guys said and stripped it all back to the basics and got it working without the proxy. Funnily enough though It worked with HTTPS 'ssl.on=true' (self signed on the mango) but HTTP was having issues.
Anyway I enabled set 'ssl.on=true' on the server and got it all working.Then I moved it all back behind the reverse proxy, and so far it all seems to be working fine.
The only difference this time is the ssl.on = true.I may be wrong but how I don't see how the reverse proxy will make it more secure
Yeah I mainly did this because I'm using a Synology NAS as the reverse proxy, it has nginx built in. Having this take care of the certificates and the auto renewals etc seemed a lot more straight forward then getting it to work on the mango with the java keystore etc. Perhaps a feature to add for Mango 4? haha.
I'll see how this goes and keep you posted.
Bearing in mind that the ports 9005 for cloud connect and the ports I've opened for the PTCP publishers get forwarded straight to the mango itself. I haven't got them going through the reverse proxy. Are the HTTP/S payloads?
-
Awesome!
They are not HTTP payloads.
I use let's encrypt and certbot to handle certificate renewals. There is a script in mango that can be run after the cert is renewed that will move the certificate into the keystore and replace the old cert. /mango/bin/certbot-deploy.sh
You may want to look at that.
