dfox1787 Posted October 7, 2021 Share Posted October 7, 2021 (edited) 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 October 7, 2021 by dfox1787 1 Quote Link to comment
galluno Posted October 8, 2021 Share Posted October 8, 2021 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 Quote Link to comment
bat2o Posted October 8, 2021 Share Posted October 8, 2021 (edited) 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 October 8, 2021 by bat2o Quote Link to comment
Abigel Posted October 11, 2021 Share Posted October 11, 2021 On 10/7/2021 at 10:24 AM, Konfitüre said: for me it is not solved I have still the problem with nextcloud and joplin. How can I remove the "DST Root CA X3" ? Same issue Somebody you can help? Quote Link to comment
rojarrolla Posted October 11, 2021 Share Posted October 11, 2021 I've Never used Letsencript. If I want to use SWAG is the same install and config? Thanks. Quote Link to comment
ErikRedbeard Posted October 12, 2021 Share Posted October 12, 2021 (edited) 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 October 15, 2021 by ErikRedbeard Solution Quote Link to comment
perfect Posted October 14, 2021 Share Posted October 14, 2021 (edited) 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 October 14, 2021 by perfect Quote Link to comment
perfect Posted October 14, 2021 Share Posted October 14, 2021 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!!! Quote Link to comment
007craft Posted October 17, 2021 Share Posted October 17, 2021 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. Quote Link to comment
anongum Posted October 18, 2021 Share Posted October 18, 2021 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? Quote Link to comment
hermy65 Posted October 20, 2021 Share Posted October 20, 2021 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? Quote Link to comment
jafi Posted October 22, 2021 Share Posted October 22, 2021 I tried to search, but no luck. Is it possible to use SWAG with custom ssl sertificate via cloudflare? Quote Link to comment
ksignorini Posted October 27, 2021 Share Posted October 27, 2021 (edited) 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 October 27, 2021 by ksignorini Quote Link to comment
JonathanM Posted October 27, 2021 Share Posted October 27, 2021 9 minutes ago, ksignorini said: nextcloud.mydomain.net which of course can't be accessed from inside. Why not? With the proper settings in your router it should work just fine. Quote Link to comment
ksignorini Posted October 27, 2021 Share Posted October 27, 2021 (edited) 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 October 27, 2021 by ksignorini more info Quote Link to comment
JonathanM Posted October 27, 2021 Share Posted October 27, 2021 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. Quote Link to comment
ksignorini Posted October 28, 2021 Share Posted October 28, 2021 (edited) 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 October 28, 2021 by ksignorini wording Quote Link to comment
ksignorini Posted October 28, 2021 Share Posted October 28, 2021 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. Quote Link to comment
Ockingshay Posted October 29, 2021 Share Posted October 29, 2021 (edited) 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 October 29, 2021 by Ockingshay Quote Link to comment
Congo Posted October 30, 2021 Share Posted October 30, 2021 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 Quote Link to comment
kazanjig Posted November 2, 2021 Share Posted November 2, 2021 (edited) 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 November 2, 2021 by kazanjig Quote Link to comment
Tosh6072 Posted November 3, 2021 Share Posted November 3, 2021 On 10/30/2021 at 6:37 PM, Congo said: I legit made an account to say thank you. I was struggling for 5 hours and now its fixed. THANK YOU. I LOVE YOU I appreciate that, really nice to know it helped someone else Quote Link to comment
jimdaway Posted November 9, 2021 Share Posted November 9, 2021 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. Quote Link to comment
jimdaway Posted November 9, 2021 Share Posted November 9, 2021 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? Quote Link to comment
JonathanM Posted November 9, 2021 Share Posted November 9, 2021 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. Quote Link to comment
Recommended Posts
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.