How to Configure NGINX Reverse Proxy Server for NextcloudPi?

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
1

How to Configure NGINX Reverse Proxy Server for NextcloudPi?

I have an existing Nextcloud installation (courtesy of NextcloudPi) that’s been up and running on my RasPi for well over a year now. It has the full LetsEncrypt/SSL setup installed and all works great. Now I want to add another pi-based website to the mix, using a 3rd Pi as an NGINX-based reverse proxy server. My question is how do I handle the HTTPS stuff for the NCP installation? Connecting it directly to the reverse proxy server using a simple proxy_pass didn’t work – do I need to set up a new LetEncrypt certificate for the RP server, and if so, will that be compatible with the existing NCP certificate? I’m a bit of a noob at proxying, and am not quite sure how to proceed. Any insight would be appreciated.

Many thanks in advance!

– DL

NextCloudPi version v1.17.0
NextCloudPi image NextCloudPi_10-10-17
distribution Raspbian GNU/Linux 9 \n \l
automount yes
USB devices sda sdb
datadir /media/NC-data/nc-data
data in SD no
data filesystem btrfs
data disk usage 23G/58G
rootfs usage 5.1G/30G
swapfile /var/swap
dbdir /var/lib/mysql
Nextcloud check ok
Nextcloud version 15.0.5.3
HTTPD service up
PHP service up
MariaDB service up
Redis service up
Postfix service up
internet check ok
port check 80 open
port check 443 open
IP 192.168.1.175
gateway 192.168.1.1
interface eth0
NAT loopback no
uptime 28days
2

You have to add your certificate / create a new certificate to your reverse proxy. With a reverse proxy, client connections allways end there and the proxy makes a new connection to your cloud server.

You should also point port 80 to your reverseproxy and let this proxy redirect to port 443.

3

Thank you so much for this info – your clear and concise answer is extremely helpful. Will I need to make any modifications to the NC installation, especially regarding the current HTTPS setup, or will it be sufficient to just install the certificate on the RP server? In other words, does the NC server need any modifications to accommodate the RP server?

4

No, your Nextcloud server does not need any modifications. You just need to install your RP and certbot for it.

1 Like
5

Many thanks for the reply – it’s really helpful. I’m still struggling to get the HTTPS stuff working on the proxy, and this helps eliminate a lot of possible causes.

6

I now this thread is very old but did you manage to get it running? I want do to the same now and there is still no manual for this…

7

well. the answer of @dst21 might be a bit misleading.

i don’t know nextcloudpi to well. but if it redirects http access automatically to https you have turn this of. or you have to provide a correct certificate for the internal nextcloudpi server name.

yes. your reverse proxy is now the ssl endpoint. and a valid certificate is needed for the url.

no. yes. what do you mean? simply speaking the certificate is the proof that your server is the correct server for the given url. so if your reverse proxys dns name is nextcloud.exampledomain.tld your certificate validates this string. if you move this fqdn to your reverse proxy you can move the certificate as well. if your reverse proxy is now proxy.exampledomain.tld you need new certificates.

said this it should be clear that if you rename your nextcloudpi server you need as well new certificates for the new name.

because normally your new name is an internal name e.g. nextcloud.home.routeryou won’t get signed certificates for this name. so you have to configure your reverse proxy to accept self signed certificates.

8

My apologies for neglecting this thread. I have not yet managed to get this all running to my satisfaction. My understanding from @dst21 was that once I got all the certificate stuff properly installed on my proxy server, I shouldn’t need to make any changes to the existing target (which will keep its current name). To install the Letsencrypt stuff on the proxy server, I just ran the certbot program according to the instructions on the Letsencrypt website. It sorta worked; queries to the proxy server seemed to properly redirect to the target website, but eventually I start getting odd errors and the links on the target website start breaking.

Unfortunately, due to some lingering family health crises, I simply haven’t had the time to pursue this in depth, or even to dedicate enough attention to documenting the problems fully and returning here for proper follow-up. I absolutely intend to crack this nut, but I don’t expect to have much time to devote to it until January. Many thanks to @Reiner_Nippes for his comments as well; I will address all the comments when I get the chance, but it will likely be weeks rather than days before I can get back to it in earnest.

9

I did something very similar (my reverse proxy is on a vps, not on a pi, though).

You essentially have two options:

  • You offload ALL tls work to the reverse proxy (I did this)
  • You don’t, and use a “dumb” reverse proxy.

If you go for the first one, you should remove tls from the pi where your nextcloud installation is, and be absolutely sure that it has a safe channel to reach the reverse proxy (I use wireguard and tinc as a backup, but being both on the same local area network sounds fine). you might even keep tls on there, letsencrypt http-01 verification should go across the proxy just fine, but it is kinda pointless.

A big advantage of this solution is that it works with the nginx proxy_pass syntax you posted.

If, instead, you want to keep the TLS load on the current pi, you have two options, use nginx as a stream proxy, or use haproxy.

My nginx conf for the reverse proxy is as follows:


upstream mypi {
	server 10.9.1.5:3000; # wireguard
	server 10.9.0.5:3000 backup; # tinc
}

server {
	server_name __hostname__;
	include snippets/listen;
	include snippets/ssl_conf;

	location / {
		proxy_pass http://mypi;
		include snippets/proxy_conf;
	}
    ssl_certificate /etc/letsencrypt/live/__hostname__/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/__hostname__/privkey.pem; # managed by Certbot
}

Where snippets/proxy_conf is

proxy_redirect http:// $scheme://;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Proto $scheme;

Something you want to keep in mind is to remove $port from the 301 redirects for .well-known/carddav and caldav in the nextcloud nginx conf, otherwise it wont work, app will issue a redirect to https://yoursite:80/ with a protocol and port mismatch (default https is 443, 80 is unencrypted – and if your reverse proxy rejects connections on port 80 (mine does) nextcloud will complain misconfiguration.)

3 Likes
10

I was able to implement a reverse-proxy as well. Somebody wrote a nice manual for that purpose: https://phip1611.de/2019/12/programmierung-und-skripte/running-nextcloudpi-with-docker-compose-behind-nginx-reverse-proxy-with-tls/

I had to get a bit into it but even I have managed it without any experience. So give it a try anybody who reads this.

2 Likes
11

What I am trying now it to safely enable caching in the reverse proxy nginx. Any pointers?

It’s not like it will serve private files to the public, right?

12

This one works on every level, it’s the first setup I met in about 4 days trial and error, reading, searching and more. So great share. There is al lot of security issues to consider and I am not 100% sure they have all been met in this setup. So step 2, finding out and checking once again many pages, sites and advise. Tnxs Giuseppe!

1 Like
13

can someone post the config.php?

Thread is quite old, but I face the same issue. I am getting a “too many redirects” error.

14 
<?php
$CONFIG = array (
  'passwordsalt' => 'someHashValue',
  'secret' => 'longSecret',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    5 => 'nextcloudpi.local',
    7 => 'nextcloudpi',
    8 => 'nextcloudpi.lan',
    1 => '172.18.0.2',
    20 => 'cloud.domain.de',
    21 => 'domain.de_',
    22 => '_',
    3 => '16982383f018',
    11 => '88.152.59.117',
    14 => '16982383f018',
    '' => 'cloud.domain.de',
  ),
  'default_language' => 'de',
  'default_phone_region' => 'DE',
  'default_locale' => 'de_DE',
  'datadirectory' => '/data/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '23.0.2.1',
  'overwritehost' => 'cloud.domain.de',
  'overwrite.cli.url' => 'https://16982383f018/',
  'overwriteprotocol' => 'https',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'ncadmin',
  'dbpassword' => 'somePassword',
  'installed' => true,
  'instanceid' => 'ocpki9ramxdk',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
    'password' => 'someHashValue',
  ),
  'tempdirectory' => '/var/www/nextcloud/data/tmp',
  'mail_smtpmode' => 'smtp',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_from_address' => 'info',
  'mail_domain' => 'gmail.com',
  'jpeg_quality' => '60',
  'preview_max_x' => '2048',
  'preview_max_y' => '2048',
  'maintenance' => false,
  'loglevel' => 1,
  'htaccess.RewriteBase' => '/',
  'mail_sendmailmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'ssl.host.net',
  'mail_smtpport' => '465',
  'mail_smtpname' => 'xyz@gmail.com',
  'mail_smtppassword' => 'password',
  'theme' => '',
  'app_install_overwrite' => 
  array (
    0 => 'keeweb',
    1 => 'drop_account',
    2 => 'ldap_write_support',
  ),
  'trusted_proxies' => 
  array (
    11 => '127.0.0.1',
    12 => '::1',
    13 => '16982383f018',
    14 => '172.18.0.2',
  ),
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
);

Not all of these entries are useful for you. Some are because of LDAP as you can see.

1 Like