[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

On 10/5/2021 at 8:51 AM, dfox1787 said:

Hi, Has something changed on swag recently? its been working fine and nothing has changed on my FW or network now i am getting this error:

 

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

 

restored a backup all working now. thanks for the help.....

Edited by dfox1787
  • Like 1
Link to comment

Hi! I'm trying to host my own git server, using Gitea combined with SWAG, I followed @SpaceInvaderOne's guide on how to add reverse proxies for select applications, I think I did it right, as I get to an error page, saying Error 403 Permission Denied; SWAG redirects the traffic "correctly", but I can't figure out what I configured wrongly. Could someone help me? app.iniis Gitea's own config.

gitea.subdomain.conf

Link to comment
On 9/25/2021 at 2:23 PM, sloob said:

EXCEPT that I can no longer access my nextcloud GUI AT ALL on my home network, when I try to access it via localhost:444 it gets redirected to my domain name (nextcloud.mydomain.com). is there a way I can retain the ability to connect to owncloud on my home network?

 

I have the same issue, where my router doesn't allow NAT loopback or hairpinning. To access nextcloud on my home network, type the localhost:444, which then redirects it to the nextcloud.mydomain.com (like you indicated). After that first redirect I change the "nextcloud.mydomain.com" with "localhost:444" in the url and it works.

Edited by bat2o
Link to comment

Solved
My issue turned out to be this and removing the resolver.conf and having it regenerate fixed my issue.

Quote

 

  • The container originally ran with host networking, or the default bridge.
    • In most cases the contents of /config/nginx/resolver.conf; should be ...resolver 127.0.0.11 valid=30s;, if this is not the case, you can:
    • Delete it, and restart the container to have it regenerate
    • Manually set the content(we wont override it)

 


Old message
I'm having an issue I can't find much about.
My custom docker network isn't properly doing auto dns.

So far I've followed and adjusted some things based on How to Setup and Configure a Reverse Proxy on unRAID with LetsEncrypt & NGINX since it's mostly the same.

NGINX is working from what I can tell. I can access www.subdomain.duckdns.org without any issues.
I'm trying to get Emby configured. So I've made an emby.subdomain.conf in the proxy folder based on the sample.

Spoiler

server {

    listen 443 ssl;

    listen [::]:443 ssl;

 

    server_name emby.*;

 

    include /config/nginx/ssl.conf;

 

    client_max_body_size 0;

 

    location / {

        include /config/nginx/proxy.conf;

        include /config/nginx/resolver.conf;

        set $upstream_app LinuxServer-Emby;

        set $upstream_port 8096;

        set $upstream_proto http;

        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

 

        proxy_set_header Range $http_range;

        proxy_set_header If-Range $http_if_range;

    }

}

However the above does not work.

[error] 495#495: *1 linuxserver-emby could not be resolved (110: Operation timed out), client: 192.168.1.1, server: emby.*, request: "GET / HTTP/2.0", host: "emby.subdomain.duckdns.org"

If I however use the unraid or the container specific IP instead of my container name it works without issues.


If I open the console for the swag container and do a "ping linuxserver-emby" it returns properly
An "nslookup linuxserver-emby" comes back with

Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:
*** Can't find linuxserver-emby: No answer

Non-authoritative answer:
Name:   linuxserver-emby
Address: 172.18.0.2

 

I'll also include my "docker network inspect bridge-dnsres" output. As that is the custom network I made with "docker network create"
 

Spoiler

[
    {
        "Name": "bridge-dnsres",
        "Id": "da0c7b689a7e0db97a1d768673709630dfb84c08514253f84d89d5d8b6885ab3",
        "Created": "2021-10-12T19:34:00.972223414+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "a98c8b65116c3a4a14dfe974f0ca7d09d7633f167fffef1652e25af5fad79447": {
                "Name": "LinuxServer-Emby",
                "EndpointID": "7f7343d63d26b399073229cb9a5a01cda9ba7ec11d9d64c6d537e5b1604876d6",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            },
            "f4e5a8ba0be35e8de976f796272dd212675316ed8b0fa75e858e01f2f67a5d76": {
                "Name": "LinuxServer-Swag",
                "EndpointID": "fa158bec314864f546c3cd799f85586563388a3f41068842fa49fa2aa8d06f6a",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]


I'm completely stumped at this point as to why NGINX refuses to see the emby container by name.

Edited by ErikRedbeard
Solution
Link to comment

I'm having a recent issue with SWAG that I need help to solve.

 

Specs:

  • Unraid version 6.9.2 (rebooted earlier today)
  • SWAG (linuxserver) - up-to-date

 

Problem:  My duckdns subdomains will no longer work and I can't access any of my reverse proxies (on or off network).  This all worked fine a few months ago.  My ports are forwarded for 80 and 443 (I can see both ports as open using https://canyouseeme.org/)

 

SWAG LOG: (redacted some private info)

ErrorWarningSystemArrayLogin


[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing...
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=America/Chicago
URL=duckdns.org
SUBDOMAINS=cdrA,cdrB,cdrC
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
VALIDATION=http
CERTPROVIDER=
DNSPLUGIN=
EMAIL=REMOVED
STAGING=false

grep: /config/nginx/resolver.conf: No such file or directory
Setting resolver to 127.0.0.11
grep: /config/nginx/worker_processes.conf: No such file or directory
Setting worker_processes to 4
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d cdrA.duckdns.org -d cdrB.duckdns.org -d cdrC.duckdns.org
E-mail address entered: REMOVED
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for cdrnasrp.duckdns.org and 2 more domains

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:

Domain: cdrA.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrA.duckdns.org/.well-known/acme-challenge/nJv_R9lJk8sxZtsoGX1gkZySREMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Domain: cdrB.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrB.duckdns.org/.well-known/acme-challenge/VMwvJ3ck1dFUxwL12FG1CzRtmrs8REMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Domain: cdrC.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrC.duckdns.org/.well-known/acme-challenge/7jQsQISoHcKOZpF_ajOE-AcDxz_REMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.


Some challenges have failed.

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

 

Edited by perfect
Link to comment
19 hours ago, perfect said:

I'm having a recent issue with SWAG that I need help to solve.

 

Specs:

  • Unraid version 6.9.2 (rebooted earlier today)
  • SWAG (linuxserver) - up-to-date

 

Problem:  My duckdns subdomains will no longer work and I can't access any of my reverse proxies (on or off network).  This all worked fine a few months ago.  My ports are forwarded for 80 and 443 (I can see both ports as open using https://canyouseeme.org/)

 

SWAG LOG: (redacted some private info)

ErrorWarningSystemArrayLogin


[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing...
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=America/Chicago
URL=duckdns.org
SUBDOMAINS=cdrA,cdrB,cdrC
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
VALIDATION=http
CERTPROVIDER=
DNSPLUGIN=
EMAIL=REMOVED
STAGING=false

grep: /config/nginx/resolver.conf: No such file or directory
Setting resolver to 127.0.0.11
grep: /config/nginx/worker_processes.conf: No such file or directory
Setting worker_processes to 4
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d cdrA.duckdns.org -d cdrB.duckdns.org -d cdrC.duckdns.org
E-mail address entered: REMOVED
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for cdrnasrp.duckdns.org and 2 more domains

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:

Domain: cdrA.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrA.duckdns.org/.well-known/acme-challenge/nJv_R9lJk8sxZtsoGX1gkZySREMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Domain: cdrB.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrB.duckdns.org/.well-known/acme-challenge/VMwvJ3ck1dFUxwL12FG1CzRtmrs8REMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Domain: cdrC.duckdns.org
Type: unauthorized
Detail: Invalid response from http://cdrC.duckdns.org/.well-known/acme-challenge/7jQsQISoHcKOZpF_ajOE-AcDxz_REMOVED [98.156.3.999]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.


Some challenges have failed.

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

 

I might have actually solved my problem...

 

My home router is a Unifi USG PRO-4.  I did some reading and discovered that SWAG (Let's Encrypt) has been experiencing a certificate expiration issue since 9/30/2021 (right around the time that this started). 

 

This page really helped me better understand the issue.

 

I did a firmware update to my USG PRO-4 and restarted my SWAG docker... and everything works now!!!

Link to comment

How do I forward a subdomain to an EXTERNAL site?  For example I have games.mydomain.com and when a user goes there I want to redirect them to https://dosgames.com

 

I set up a games.subdomain.conf file which contains:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name games.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        proxy_pass https://www.dosgames.com/;

        proxy_max_temp_file_size 2048m;
    }
}

 

But when I goto the site it looks wrong and says connection not secure.  Like it wont switch over to https for some reason.  How do I fix this?  Im running other subdomains going to various dockers like jellyfin, radar, ect and those all work, but this is the first time Ive tried to direct a subdomain to an EXTERNAL site, and not some app on my server.

Link to comment

As many other, the expiration of the root certificate made my TVs swag reverse proxy of plex stop working.

Is there something I can do to fix this without resorting to removing the reverseproxy altogether? On some emby threads https://emby.media/community/index.php?/topic/102144-several-lg-tvs-cannot-connect-to-server/page/2/ they suggested to switch to zerossl: I recreated my certs last week, but still no luck, and I don't know honestly if zerossl is built into letsencrypt or not, this is way beyond my tech competence.
Can someone help me?

 

Link to comment

Any chance anyone can help me with some samesite/sameorigin issues im having with swag+organizr?

 

I was able to use the chrome flags when they were available to get things working, then they removed the flags so i resorted to a registry tweak but that no longer works for me either. I would like to get this fixed once and for all so i can continue to use things.

 

Right now i have everything going through swag using a name.domain.com format. If i use local ips for organizr + the organizr tabs use local ips i get the attached image when i inspect the tab. If i go through my reverse proxy with organizr.domain.com and all the tabs using service.domain.com i get the same thing. How do i resolve this once and for all?

1.png

Link to comment

I've installed Nextcloud and have SWAG correctly redirecting my external nextcloud.mydomain.net to Nextcloud when accessed from outside my network. When accessing from inside my network using 10.0.0.10:4434 (the port I chose for Nextcloud in the config) I can't access the webui.

 

I think it's trying to convert it to nextcloud.mydomain.net which of course can't be accessed from inside.

 

Ideas?

Edited by ksignorini
Link to comment
24 minutes ago, JonathanM said:

Why not? With the proper settings in your router it should work just fine.

Hm. What settings can cause this to not work? I'm forwarding all 80 and 443 to my unRAID box.

 

nextcloud.mydomain.net works great if I'm on a VPN from outside my local network or physically outside my local network, as do 4 other subdomains being used to access containers via SWAG. All of them hang when trying to access the outside subdomain from inside the network.

As well, why would 10.0.0.10:4434 be resolving to the outside subdomain?

 

Also of note: 10.0.0.10 webDAV access works great using a webDAV client while inside the network.

Edited by ksignorini
more info
Link to comment
46 minutes ago, ksignorini said:

nextcloud.mydomain.net works great if I'm on a VPN from outside my local network or physically outside my local network, as do 4 other subdomains being used to access containers via SWAG. All of them hang when trying to access the outside subdomain from inside the network.

The terms to google are

nat reflection

hairpinning

nat loopback

along with your specific router.

Link to comment
9 hours ago, JonathanM said:

The terms to google are

nat reflection

hairpinning

nat loopback

along with your specific router.

 

Couldn't find much. I actually have 2 routers (one is an ISP modem/router that I use for nothing but the modem; the other is my main router that sits in the ISP router's DMZ). 

 

However, when configuring Nextcloud, if I change these lines:


 

'overwrite.cli.url' => 'https://10.0.0.10:444',      <----- the way it was originally
'overwritehost' => 'nextcloud.mydomain.net',      <----- remove this line entirely

 

and add to the trusted_domains array:

 

1 => 'nextloud.mydomain.net',


Then it works from both inside (using 10.0.0.10:444) and outside the network (using subdomain.domain.net -- as far as I can tell by VPNing outside anyway).

 

What am I breaking by not having the url and host overwritten with the external subdomain.domain name?

 

Edited by ksignorini
wording
Link to comment
20 hours ago, JonathanM said:

The terms to google are

nat reflection

hairpinning

nat loopback

along with your specific router.

 

Turns out my ISP has a built-in bridged port on their modem/router (T3200M) that you don't even need to configure as bridged (port 1) and by throwing my inside router on port 1, NAT reflection started working. As a result, I've gone back to setting up Nextcloud and SWAG as intended and all is well.

Link to comment

can anyone please share their ombi default config: i've been using it for years as

 

	location /ombi {		
    		return 301 $scheme://$host/ombi/;		
	}
	
	location /ombi/ {
  		proxy_pass http://192.168.0.3:3579;
  		proxy_set_header Host $host;
 		proxy_set_header X-Forwarded-Host $server_name;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    		proxy_set_header X-Forwarded-Ssl on;
    		proxy_set_header X-Forwarded-Proto $scheme;
   		proxy_read_timeout  90;
    		proxy_redirect http://192.168.0.3:3579 https://$host;
	}

	if ($http_referer ~* /ombi/) {
	        rewrite ^/dist/(.*) $scheme://$host/ombi/dist/$1 permanent;
	}

 

but it has stopped working all of a sudden. When i look at ombi help docs it gives a very different config and the sample swag config is different again.

 

this is using base url/ombi

Edited by Ockingshay
Link to comment
On 10/7/2021 at 5:48 AM, Tosh6072 said:

I had my Swag docker still failing with the Letsencrypt cert renewal.  My issue renewing was caused with Cloudflare proxing the traffic.   I turned off Proxying for my A and CNAME records (under the DNS tab in Cloudflare).  I then restarted docker and it came right.  I could then go back to Cloudflare and turned the Proxying back on.  Hope this may help someone else

I legit made an account to say thank you. I was struggling for 5 hours and now its fixed. THANK YOU. I LOVE YOU

Link to comment

EDIT: Ugh, pulled a stoopid. I was putting Shinobi on 'proxynet' instead of br1.

 

---------------------------

 

Hi all. I'm having a problem with SWAG/Shinobi using an IP address in a second subnet. It _was_ working a couple days ago but then a few things blew up with UnRAID/my network and now I cannot get Shinobi to start on the correct subnet. I've deleted and reinstalled SWAG and Shinobi, no luck. I've blown up my Docker file and rebuilt, no luck.

 

Desired: Shinobi on 'proxynet' at 192.168.2.100:8080 (I have it set correctly in the manually created shinobi.subdomain.conf)

Result: Shinobi starts on 'proxynet' at 192.168.1.100:8080 (which is a problem because I also run Ubiquiti equipment)

 

No matter what I put in the conf file for an IP address, it is ignored. Even if I put an IP address in the *.*.1.* subnet it's still ignored and Shinobi fires up using my UnRAID server's IP address. As a point of reference,I can start Shinobi on br0 and br1 using IP addresses in their respective subnets and its works just fine bypassing 'proxynet'. So, good that it appears to not be a routing issue (outside of Docker's own routing).

 

 

It's as if SWAG isn't seeing the shinobi.subdomain.conf file at all. Any thoughts on what could be causing SWAG to ignore the conf file?

Edited by kazanjig
Link to comment

SWAG Configuration (probably silly) Question

 

Hi. I have set up SWAG using my domain name and DuckDNS. I have subdomains pointing to a couple of docker containers (Nextcloud and Sonarr at present) and would like to set up a couple of more. This is working absolutely perfect from outside of my LAN.

 

I used the SpaceInvaderOne TY guides (albeit for LetsEncrypt) and things seem to work very, very well if I am outside of my LAN. The issue I am having is that I can not access either Nextcloud or Sonarr from my LAN.

 

When I installed Nextcloud, I specified port 444.

 

I have taken the following steps (and I'm hoping I don't miss anything as I recap):

- I edited the CNAME entries at my domain registrar to point to my DuckDNS entry.

- I have my DuckDNS account (and the associated docker container) setup and working

- I have SWAG installed and have:

  - Edited the conf files for both Nextcloud and Sonarr (per SpaceInvaderOne's tutorial)

  - Created a specific network (proxynet per SpaceInvaderOne's tutorial)

- I have edited the Nextcloud config.php so the array section has:

  0 => '192.168.0.185:444',

  1 => 'nextcloud.domainname.com',

- Below the array section, I added:

  'trusted_proxies' => ['swag']

  'overwrite.cli.url' => 'https://nextcloud.mydomainname.com',

  'overwritehost' => 'nextcloud.mydomainname.com',

  'overwriteprotocol' => 'https',

  'dbname' => 'nextcloud',

 

I'm sure there is a step or config element that I've missed somewhere. When I am in my LAN, navigating to 192.168.0.185:444 redirects me to nextcloud.mydomain.com and throws a "took too long to respond" error.

 

If I ping nextcloud.mydomain.com from within my LAN, it resolves to my DuckDNS account AND to my current IP but the packets timeout.

 

 

Link to comment
20 minutes ago, jimdaway said:

SWAG Configuration (probably silly) Question

 

Hi. I have set up SWAG using my domain name and DuckDNS. I have subdomains pointing to a couple of docker containers (Nextcloud and Sonarr at present) and would like to set up a couple of more. This is working absolutely perfect from outside of my LAN.

 

I used the SpaceInvaderOne TY guides (albeit for LetsEncrypt) and things seem to work very, very well if I am outside of my LAN. The issue I am having is that I can not access either Nextcloud or Sonarr from my LAN.

 

When I installed Nextcloud, I specified port 444.

 

I have taken the following steps (and I'm hoping I don't miss anything as I recap):

- I edited the CNAME entries at my domain registrar to point to my DuckDNS entry.

- I have my DuckDNS account (and the associated docker container) setup and working

- I have SWAG installed and have:

  - Edited the conf files for both Nextcloud and Sonarr (per SpaceInvaderOne's tutorial)

  - Created a specific network (proxynet per SpaceInvaderOne's tutorial)

- I have edited the Nextcloud config.php so the array section has:

  0 => '192.168.0.185:444',

  1 => 'nextcloud.domainname.com',

- Below the array section, I added:

  'trusted_proxies' => ['swag']

  'overwrite.cli.url' => 'https://nextcloud.mydomainname.com',

  'overwritehost' => 'nextcloud.mydomainname.com',

  'overwriteprotocol' => 'https',

  'dbname' => 'nextcloud',

 

I'm sure there is a step or config element that I've missed somewhere. When I am in my LAN, navigating to 192.168.0.185:444 redirects me to nextcloud.mydomain.com and throws a "took too long to respond" error.

 

If I ping nextcloud.mydomain.com from within my LAN, it resolves to my DuckDNS account AND to my current IP but the packets timeout.

 

 

And, now reading about:

nat reflection

hairpinning

nat loopback

 

I suspect that my IPS modem/router does NOT have this functionality and my only solution will be use a more advanced router and do a port passthough to it.

 

Does that make any sense?

Link to comment
23 minutes ago, jimdaway said:

And, now reading about:

nat reflection

hairpinning

nat loopback

 

I suspect that my IPS modem/router does NOT have this functionality and my only solution will be use a more advanced router and do a port passthough to it.

 

Does that make any sense?

You got it, only snag is that you need not just a port passthrough to the more capable router, you need the external IP to be assigned to the WAN port of the router. Typically that's referred to as bridge mode, so see if you can configure that, some ISP's require that sort of thing to be configured by them, not something you can do yourself.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.