My NAS project: Swag on a non standard public port

LSIO Discussion Container Support
, ,
1

Hello,

I created my account and came visit here and the first topic I read was about a very similar issue I am facing: https://discourse.linuxserver.io/t/nextcloud-and-swag-on-non-standard-port/3613

But as my project is a bit different and I do not want to pollute this other thread with my specific question, I hope there will be no problem creating my own here.

My project: I bought a domain name and I want to have my NAS to be internet facing. My NAS is an openmediavault computer, with additional services provided as docker containers.

Let say my domain is mydomain.com for the rest of this thread.

I managed to configure it so that it works flawlessly (or almost) on my internal network.
I have a local dns entry to have *.mydomain.com resolved as my local IP address (192.168.1.40) where openmediavault and docker/portainer are running.

My swag setup is done.

Everything is almost working as expected locally, with the local domain name resolution (except an issue with duplicati that I will try to solve on my own for the time being).
openmediavault is a redirection to the server itself, portainer, nextcloud, duplicati and filebrowser are docker containers, so I use docker networking for that between swag and containers. Everything under a certificate generated by swag.

This is what I wanted … but externally.

I now want to have that single port (192.168.1.40:443), routing all HTTPS traffic to swag, internet facing. Easy peasy … on port 443 ^^
I made some tests and everything works fine :grinning:
The problem is that port 80 and 443 are already used by other servers. I need another port, let say 444.
Of course I changed my NAT to route public IP 444 to internal IP 443 and it is for sure working.

Heimdall redirects to 443 and barely not loads on https://mydomain.com:444/
image
It has the correct configuration, with subfolder settings (not subdomain) and / removed from standard site-confs configuration.

nextcloud is configured like other containers as subdomain for swag: https://nextcloud.mydomain.com:444/
It displays a login page but blocks the following requests

FileBrowser as well as Portainer are working very well on this other port, no issue at all!

So to sumarize:
Everything work on my internal network
Everything work on my domain name, standard 443 port.
As soon as I use a non standard port for HTTPS traffic, many services stop working

Is there anything I can do to debug this issue and identify if anything can be done to make the reverse proxy work as it should do ?
I think that having it working internally and on port 443 is a proof that my configuration are correct, so I guess there must be additional settings to add when you are not running on a standard port so that servers inside containers redirect properly.
I thought it was completely transparent, maybe it is not after all !

Thank you.

2

As I am new here, this is very complex to add media to help understanding my issue and debugging.
Here is the one for nextcloud :

image
image1906×1459 179 KB

3

Hello and welcome to our forums. We are much more active on our discord server and since you’re queries above are multi-part it may be best to have a live conversation.

that said, a few things to note. If you already use 443 internally and/or externally, why not just reverse proxy whatever THAT is through swag. This way 80/443 are owned by swag and tls will always work properly. Since your other apps would all be proxied (swag can proxy ANYTHING, doesnt even have to be owned by you, i reverse proxy google.com as a proof of concept) everything will have a valid cert.

for nextcloud, 1) are you using our nextcloud container? 2) did you follow the instructions at the top of the nextcloud.subdomain.conf file in swag? it has some items you need to edit in your nextcloud’s config.php.

discord: LinuxServer.io

4

Hello driz!

The first thing I tried was the discord channel, but my question there was not answered and replaced by others soon after.
I think nobody really replied to my message, except something like “do you really need it?”.

Regarding nextcloud (and other containers):
They are fully working on standard 443 port. I am looking for hints on how to make them also working on another port. Maybe the issue is not linked to swag itself, this is only my main concern: I do not know where to have a look and understand what is going wrong.

I cannot and will not put swag as a front reverse proxy on the 443 port, I cannot provide HA on the server running it and take any risk to cut my service already available there.
This is the reason why I am trying to have it working on another port for the time being. What should not be an issue at all. At least it works for some services. I am not saying here that it does not work, I am saying that it does not work for my nextcloud container and my heimdall container. Others are okay.

Yes, I am running it as a container. This one: Package nextcloud · GitHub

Yes, I followed the instructions:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'ocxefzoouy4e',
  'passwordsalt' => 'XXX',
  'secret' => 'XXX',
  'trusted_domains' =>
  array (
    0 => '192.168.1.40:8400',
    1 => 'nextcloud.mydomain.com',
),
  'dbtype' => 'mysql',
  'version' => '22.2.3.0',
  'dbname' => 'nextcloud',
  'dbhost' => 'nextclouddb',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'oc_admin',
  'dbpassword' => 'XXX',
  'installed' => true,
  'trusted_proxies' => ['swag'],
  'overwrite.cli.url' => 'https://nextcloud.mydomain.com/',
  'overwritehost' => 'nextcloud.mydomain.com',
  'overwriteprotocol' => 'https',
);

(I tried adding some port information on rewrite settings but not sure they are used to compute back the url …)

I just discovered something but looking in details into the https request.

https://nextcloud.mydomain.com:444/ does not work (redirect to 443 for login)
but 'https://nextcloud.mydomain.com:444/login and https://nextcloud.mydomain.com:444/dashboard are working. So I guess there is an improper handling of redirect placed somewhere … but I have no idea where !

image
image1288×649 51.1 KB

5

For heimdall it does not look the same. The content of the returned html page contains invalid address, they are not asking with the same port than the request.
I followed the guides listed on the swag documentation to setup everything.

image
image2743×928 355 KB

As both servers are running okay on 443 and when I access them directly on the host via their dedicated port, I guess they are also working and that something is not working when swag handles a redirect back from the container.

header location in response is the main cause of all my issues. It does not contain the correct port information. How could I fix it ?