Node red SSL/TLS dashboard behind 4g

[Trevor Morris]

What is the best way to attack this?  I have ngrok working.  I have the ui and dashboard passlocked via the node-red tutorial.  I would like to add TLS to the dashboard and be able to access it via the web ui without using ngrok but using apache or nginx or something else.  I'am not a networking guy but I have gone through a couple of the digital ocean tutorials for VPS's and have somewhat of an idea of how to do this.  Have any of you pulled this off?  Thanks

[Julian Knight]

This should help: https://github.com/node-red/cookbook.nodered.org/wiki/How-to-safely-expose-Node-RED-to-the-Internet

I think it has a link to at least one article. NGINX works well but you have to remember to secure websockets as well as http.

[Trevor Morris]

Julian, thank you for the response.  I actually have looked at this, it is where I found out about ngrok. Since I'am on the 4gLTE network I'am NAT'ed and cannot point a domain to my IP nor access it directly.  I put my device on a dmz.  I have a linux VPS.  I have a fqdn.  Should I be trying a reverse proxy?  This makes no sense to me because I cannot connect to the public ip (becuase its a bullshit ip).  I also read people have used a VPS to VPN between the device and the server and then forward all web traffic to the server.  ngrok works, however I figured there must be a way to do this on my own w/o paying for a service if I work at it harder.  Thoughts?  The vpn over the vps sounds clunky...

[Julian Knight]

OK, lets take a step back. First we need to understand the architecture you are actually wanting.

If I understand it correctly. You have NR running on a device that is connected to the internet via 4g? And you want to allow inbound access to that?

So far, you've used ngrok. So what that is doing is creating an SSL (I think, maybe an SSH?) VPN via their own servers. Your device reaches out to their servers and tells gives them a channel to your device, you or someone else can connect to their servers and receive a route through to your device.

It's too late in the day for me to go through your options - so perhaps you would confirm (or otherwise) my assumptions and I'll try and pick this up again tomorrow. There are definitely ways to sort this, we just need to home in on the best option.

[Trevor Morris]

Yes, that is correct.  I have NR working on both a pi3 and windows IOT.  I would like inbound access to the dashboard allowing me to include authentication and forcing https.  Since I last checked this post, I have gotten openvpn working on my droplet and I'am trying to forward http traffic over the vpn from my NR device trying to mimic the behavior of ngrok as others have mentioned is possible.  Is it as easy as forwarding http over ssh now?  This isn't working yet but I maybe am doing something dumb.  My nginx on the server side is forcing https, and I have gotten it to load an index page.  The open vpn server/client structure is working however I'am currently using the default udp protocol...might need to switch to tcp?  I do think this is sortable just lots of minutia! :)  I *think I need to forward traffic over the tunnel but not sure the method?  Ideally since I have a fqdm on my droplet server I'd like to access the n/r dashboard via that name and have it forcing me into https and logging in.  I already created a CA and generated all the certs etc.  Thank you for your input.

[Julian Knight]

To use a VPN, you have to route the traffic you want over it. This is a networking issue. The remote end of your VPN is effectively on the same network as the root. So once you create a VPN link from the network your Pi is on to your server, there should be nothing more to do. Well, other than making sure you have the right firewall settings that allow the outbound VPN connection from your Pi network and inbound on the server's network.

How you test that depends on what is providing the VPN endpoint locally. If, for example you are running the VPN endpoint on the Pi and NR on the Windows IoT device, you would likely need to make sure that the default gateway for the IoT device was the Pi. Normally it would be your 4g router.

[Trevor Morris]

Ok, I think I'am getting close but this is still confusing.  I will be as clear as possible with my current setup this time.  I have a cloud ubuntu server and my NR is running as the client on a pi3 (Ignore the win IOT machine that is another dev machine).  I have been successful in getting openvpn to connect from the pi3 to the ubuntu server with tcp (not udp) over the default port 1194.  NR is also running on the default of 1880.  I have an nginx web server block running on my ubuntu server that is serving a default index page just as a test.  The server has tcp 1194 open.  This is where I start to become confused because of my lack of network knowledge.  Do I need to additionally allow 1880 through the vpn as well, and do I need to create a server block that points back to the clients host/domain/ip?  I have no idea how to do this.  Would I reference the clients vpn IP in the nginx conf in order to get it to see that?  Also how would I get the NR port 1880 stuff to show up as the default splash page when I go to the ubuntu servers domain...ie without typing www.ubuntudomain.com:1880.  I'am not asking for a total hand hold here more which rabbit hole to jump down or tutorials to read through next.  I'am slightly suprised this has not been covered more since a huge application of NR is field applications where your only connection option may be 4g (which is my case).  Maybe something like this http://nginx.org/en/docs/stream/ngx_stream_core_module.html ?

[Julian Knight]

Ah! OK. Yes, well you've chosen a pretty complex example to start your learning journey with TCP networking :-)

So you've got some traffic going from the Pi through OpenVPN to the server - but what traffic, how have you configured OpenVPN? If all of your traffic is going through the VPN, you should no longer be able to access the Pi from your home network. If you can , then only some traffic is being routed and we need to understand what. You can selectively route using a routing policy. This allows you to select specific routes and ports, even specific applications.

On the server, traffic from the Pi (over OpenVPN) should appear to be on the same local network. I suspect the problem you have is that NGINX is acting as a proxy not a web server. You will need to configure NGINX to proxy traffic coming from the VPN virtual network. That should let it be seen from the outside world.

You also need to make sure that the IPTABLEs firewall on the server isn't blocking any traffic from the VPN network. That might be why you can't see UDP traffic.

To get the NR pages to appear as the default, you need to configure NGINX to convert NR's port 1880 to port 80, that is also part of the proxy configuration. Note, though that this is generally a bad thing. You really need to set up NGINX to be a TLS endpoint so that it is proxying https connections - you can do this in Node-RED as well but doing it in NGINX is much better. More secure and more efficient. So then you would be translating from the Pi's VPN IP address with port 1880 to your servers external IP address on port 443.

Yes, it is complex. No, it isn't easy! Sorry.

[Trevor Morris]

Yea, I've set up soho type stuff but not web servers that needed these sorts of features :! Sooo I got it working except on nginx side I can still get to the dashboard through http://domain:1880, however http://domain redirects to ssl and works now! (not sure why 1880 not redirecting since its also http) Something in my nginx config.  Here is what I did these IPTable rules.

tun0 is my vpn interface, eth0 is my lan.

10.8.0.1 is my server 10.8.0.6 is the client

sudo iptables -A FORWARD -i eth0 -o tun0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1880 -j DNAT --to-destination 10.8.0.6
sudo iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 1880 -d 10.8.0.6 -j SNAT --to-source 10.8.0.1


Here is my nginx config.
server {

        listen 443 ssl;
        server_name domain www.domain;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host   $http_host;
                proxy_pass http://10.8.0.6:1880;
        #       try_files $uri $uri/ =404;  (should I leave this on? dunno)
        }

    ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem; # m$
    ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem; #$
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot



    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot


#     Redirect non-https traffic to https  (this not working at least on port 1880)
     if ($scheme != "https") {
         return 301 https://$host$request_uri;
     } # managed by Certbot

}

I think I have the right idea, I will look up nginx TLS endpoint stuff and continue the climb.

[Julian Knight]

Looks OK off the top of my head except that I think you are missing some entries for websockets. 

The entry for 404 processing doesn't hurt, it just returns an NGINX 404 response for URI's that can't be found.