Remote Access for my dashboard

@TotallyInformation it can be if you don't already have a web server set-up to expose the ACME challenges.

Nope, not any more. As long as you have a domain and can control the DNS to some degree it is easy and you no longer have to expose anything. Please read the post.

@TotallyInformation Touche, but I would say that having to use a DNS provider that supports DNS01 isn't a cakewalk either, especially if you already have many DNS entries.

Not trying to take away from your post, I just think it's more trouble than it's worth if the only thing you're going to expose is Node-RED. Just do a self-signed cert and ignore the security warnings or make the exception rules so you don't see the warning. The warnings are meaningless when it's hardware you control and you're the only one using it. Otherwise if it were a public server not in your possession and other people are using it, by all means, Let's Encrypt.

Thank you all , I'm planning to move like Paul suggest me 'cos for me it's much easy,using one raspberry like proxy reversed with nginx , and another raspberry with node-red running .
For me , it's the very first time that i run into security access problem ...

Thank you
S.

Well, it was actually very easy. I put all my DNS entries through the free tier of CloudFlare which supports Lets Encrypt. You don't have to mess with any of the DNS entries at all. In addition, Let's Encrypt now support wildcard and multi-domain certs so I bundled a big set into a single cert giving me lots of flexibility - the auto-renew runs quite happily on one of the Pi's so it all just works.

Anyway, each to their own but I wanted to make clear to others just how easy it is now to use Let's Encrypt.

Iā€™ve been wondering about the same issue. I had port forwarding on for a year (donā€™t do that). I was going to check into a remote MQTT server with a dashboard. We hen send just the updates as needed. Mqtt would open the port and then close it. Correct? Wouldnā€™t that be the way to go on this?

Not sure that is correct, I suspect that the port would remain open. However that shouldn't be much of an issue as you are opening the port outwards, not inbound.

However, this approach really needs an authenticated connection and that requires an encrypted connection. While you can do it without encryption, it would mean sending your login details in free-text over the Internet, not ideal.

This is why I need to encrypt my traffic to and from Rasp.

1 Like

Before publishing your ip port of Node red, make sure you set password for node red and node red user interface. Then from manage pallets, instal ngrok. The go to ngrok.com, create an account. After creating the account, there will be a tab left side. In that authuntication will be there. Click on that. There will be a key. Copy that. Now come back to the ngrok node in node red. Edit the authtoken and paste the key you copied from the website. Then give the port number in which your node red is running, usually 1880. Then select a region. Give HTTP protocol. Then in input type give input port . Leave the other options blank. Now create two input nodes. In one node give string "on" and on the other input node give string "off". Connect both to the ngrok node. Now create a debug node and connect to the other end of ngrok node. Deploy. Now inject on node. You will get the url on the debug node. Using that url you can access node red from any where. Note: for free users ngrok gives random url and the url will be available only for 8 hours. After that you have to generate a new authentication key. For paid version you can use constant domain for unlimited time.

hi, link is not working... :slightly_frowning_face:

It did in 2019 :slight_smile:
Here it is, I will correct the original post too.

1 Like

thank you bro.. :heart_eyes: :heart_eyes:

Please don't use the default settings for NGROK though, they are not secure. There is a thread on the forum where I gave details but there is also this flow: Access Node-RED from the Internet securely using NGROK (flow) - Node-RED.

You can also use localtunnel

The advantage over mgrok is that you can define an url (using somthing as lt -p 1880 -s subdomain) and you'll (nearly) always get that, as long as it isnt already used.The urls have the following format:
https://subdomain.loca.lt
It is also free and open source, also unlimited connection time (until Raspberry reboots or connection crashes)
Downside is that you have to configure it over commandline, but once you have it, that can be automated (e.g via cron)

This option is not bad:

It's free, includes WAF, stats, ssl certificate rotation, OAuth integration, connection doesn't crash (multiplexing 3 redundant tunnels)...

Yes, the CloudFlare Zero Trust features are great with 50 accounts built into the free tier. Excellent for creating a secure front-end for your Node-RED dashboards/UI's as well as for access to the editor or the whole server.

The only disadvantage is that it is a fair bit more complex to set up.

I found microgro.co the easiest method for remote access.
They supply a RPi image file with nr already installed with flows etc. plus tech manual to setup your password etc. Their focus is on microgreens but can obviously be used for any iot application .. smart home etc.

Are you using microgro then? The Ā£6 or Ā£10 a month option?

What sort of secure remote access are they offering - a VPN?

A snippet of their website:
image

Yet https://find-and-update.company-information.service.gov.uk/ has no record of Microgro PLC.

There is a Microgro LTD, incorporated September 2022 and which has not yet filed any accounts.

2 Likes