Rocket.Chat's Community Open Call 🎤 Dec 15, 2021 Join us!

Help with setting up router port forwarding rules (if required) and reverse proxy for hosting rocketchat on raspberry pi on home network

I have installed rocketchat on a pi3 b via snaps.

Handed the pi back to the owner where the server will be homed on their home network, which we want to give internet access for others to join.

Now I am quite confused about what ports have to be opened if using reverse proxying. I am planning to go with nginx for the reverse proxy because when I tried with snap and caddy some errors came up which I looked on github seem to be a bug. Don’t have the errors as it was days ago but besides I have more familiarity with nginx since I used it successfully about a year ago for another rocketchat server.

I have received very conflicting replies so for when asking on general networking/self hosting based forums about what ports have to be forwarded to the pi for this to work correctly.

Some say you should forward only port 3000 from public-ip of the network to the pi’s ip. Others say you should never expose any port as it is a security hole. Others still say you should port forward 3000 as well as 443 for ssl and 80 for the redirect to ssl. Others again say you should not port forward anything at all as the reverse proxy will handle it all without exposing any ports.

So yea I really don’t know what is correct right now. Can anyone please clear this up for me?

What makes it more cumbersome is that I am doing this remotely for a network that isn’t mine and the owner only has small windows of about an hour at a time a couple of times a week to make changes to the router settings. So I have to ask questions and then gather info beforehand to relay to him to make the changes.

Where we are up to so far is that yesterday I told him to forward port 3000 of public-ip to internal port 3000 of the pi. While I was unable to access the chat server remotely before, I was, after this change, then able to access the pi on their public-ip:3000 in browser. Now, given the above conflicting advice, I am unsure whether this should be closed to ensure security or left open now that we want to setup the reverse proxy.

I am still not clear if this is a no-no or not in terms of security? Since I was not sure I told him to switch off the pi soon after until I got more information on the matter. Also to note, we were not able to forward either 443 or 80 to the pi’s IP as the router would say these ports are in use. He has confirmed to me he hasn’t set anything up on the router himself but I have since read this could be an issue with the ISP/router itself, given a forum thread I found for the ISP on the error message, which prevents forwarding of those specific ports. As mentioned above, I have no idea if these ports have to be forwarded to the pi or not for reverse proxying to work? I would really hope not since the router is not allowing us to forward them!

I have already set an A name for the tld pointing to the public-ip of their network but no further reverse proxying setup as yet. That is correct right? It should be just the IP with no port in the A name?

So I am just wanting to know what are the final steps we have to take now to setup ssl with reverse proxying so it can be accessed via the tld and what ports if any have to be forwarded to achieve this.

Thanks.

Hi! Welcome to our forums!

I often see this doubts about reverse proxy. Usually, the reverse proxy will handle domain registration and “port forwarding”.

So if you have a PUBLIC IP, let’s say, 1.2.3.4, you can point your domain (chat.company.com) at it.

Whenever someone access chat.company.com, it will be resolved to 1.2.3.4 (this is your router)

At this IP, there can be a reverse proxy mechanism (apache, nginx, traefik, caddy and what not), that will know where to proxy the request to. Let’s first see the port forward option.

Now, let’s say, that at this network you have your raspberry pi, 192.168.1.10, and a rocketchat instance at port 3000.

If you don’t want SSL (meaning https), you can directly forward the port 3000 to rocketchat. You will end up being able to access your rocketchat, externally, using:
http://1.2.3.4:3000

So it is like this:
http://1.2.3.4:3000 → ROUTER (PORT FORWARD 3000) —> 192.168.1.10:3000

This will work, however, you will not be able to use our mobile apps, as they required https/SSL in order to securely connect to the server.

If you want this, then, you will need to use the reverse proxy. For that, it will be good to forward ports 80 and 433 to your reverse proxy. At the configuration of your reverse proxy (https://docs.rocket.chat/quick-start/installing-and-updating/manual-installation/configuring-ssl-reverse-proxy) you will then point the ip and port of your rocketchat instance.

https://chat.company.com → ROUTER (PORT FORWARD 80 and 443) —> reverse proxy → 192.168.1.10:3000

Sometimes, you will need to change the router admin web interface ports in order to have 80 and 443 available, otherwise they can conflict (usually, router will use the port 80 for their own admin)

Hope I have clarified it for you. Feel free to ping me at our open ir you help:

1 Like

Thanks for your detailed response. Unfortunately, after doing more research on the issue with the specific router, it appears that it is a known issue with that router that it doesn’t allow you to tamper at all with 443 and 80 and a replacement is necessary to be able to forward them.

As this seems a rather heavy handed solution I was looking for alternative workarounds.

I was doing more reading up on nginx reverse proxying and read that it is their LetsEncrypt ssl certificate validation which is what is requiring these ports and DNS-01 is an alternative that avoids the requirement to open ports.

So could I do that and not have to forward any ports, or does rocketchat also require the forwarding of these ports? As I understand it the nginx server would handle the traffic via the tld which would then push it to the internal pi’s ip address. Is that right or does rocketchat itself still require those ports somehow?

If this is still no good would you be able to offer any solution which could avoid the router’s ‘baked in’ port forward issue with these specific ports.

Btw, yes we want to secure it with ssl, and also have it available for the mobile app.

What make and model is your router?

If it doesn’t allow forwarding - then it must be using those ports itself somehow. It is sounding very strange and atypical.

I didn’t say it doesn’t allow forwarding, just not forwarding 443 and 80.

I do not own the router so don’t know the specifics as the person I am trying to set it up for has very little time for us to work on this in the small windows they are free. They thought they sent me the model last time but the data appears to be wrong and haven’t been in contact since.

You can read this thread if you want to know where I got that info.

Seems like a messy provider config (talktalk).

Yes, if you want mobile support with LetEncrypt SSL, you’ll need to get this atypical router problem fixed. fwiw