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


Recommended Posts

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
11 hours ago, JonathanM said:

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.

Perfect. The ISP modem is a Hitron CODA-4850 and seems like the custom firmware they have running on it is painfully restricted. I do have port passthrough but I've not seen anything that references NAT reflection OR bridge mode on a per-port (or any) basis. I've seen other people discover that setting port passthrough on port one of their modem automatically made it a bridge-mode port (albeit, not the same modem I have to deal with). Maybe I'll get lucky and enabling port passthrough on port one will automatically create a bridged port for me. (Yeah, I doubt that as well)...

Link to comment

Hi all,

I have unraid since two years now and I've always found solutions to my issues.

But today, I can't.

 

I got SWAG for reverse proxy with subdomain on many containers. All is fine except for plex which ran perfectly until three days ago without any sign. I can't figure out what's going wrong.

In SWAG log, I have lines like this :

*11 plex could not be resolved (3: Host not found), client: X.X.X.X, server: plex.*, request: "GET /favicon.ico HTTP/2.0", host: "plex.mydomain.com", referrer: "https://plex.mydomain.com/"

 

When I  open console on SWAG container to lookup for names, here is the result :

 nslookup radarr
Server:         127.0.0.11
Address:        127.0.0.11:53
Non-authoritative answer:
*** Can't find radarr: No answer
Non-authoritative answer:
Name:   radarr
Address: 172.18.0.10
root@XXX:/# nslookup plex
Server:         127.0.0.11
Address:        127.0.0.11:53

** server can't find plex: NXDOMAIN

** server can't find plex: NXDOMAIN

 

Container has the right name (plex). It is in network type host despite radarr is in same network as SWAG. 

 

And I did not change anything apart from updating container.

 

Any idea ?

Link to comment
On 11/9/2021 at 7:57 AM, jimdaway said:

Perfect. The ISP modem is a Hitron CODA-4850 and seems like the custom firmware they have running on it is painfully restricted. I do have port passthrough but I've not seen anything that references NAT reflection OR bridge mode on a per-port (or any) basis. I've seen other people discover that setting port passthrough on port one of their modem automatically made it a bridge-mode port (albeit, not the same modem I have to deal with). Maybe I'll get lucky and enabling port passthrough on port one will automatically create a bridged port for me. (Yeah, I doubt that as well)...

As a follow-up to this thread, I realized something very peculiar. When I am within my LAN and I drop-down the docker icon menu for the UI for Sonarr, it opens in my browser as normal. It is JUST Nextcloud that fails to open however when I do try to open the web UI for Nextcloud, it redirects to my subdomain URL yet Sonarr does not. It opens to 192.168.0.185:8989

 

Am I misunderstanding (yet again) the nuances of domain/WAN vs LAN access? Why does Sonarr connect properly yet Nextcloud does not? Is it because Nextcloud insists on an secure connection whereas Sonarr does not?

 

The more I learn, the less I realize that I know!

Link to comment

Hi,

 

I recently purchased my first iphone for 10 years and now I can't sync caldav/carddav from my own Nextcloud.
Im putting the issue here since it seems to be a certificate error.

 

I have no problem to browse to my nextcloud or to sync caldav/carddav on my old android.

But when I try setup a caldav account in my iphone i get certificate error and the certificate shown is the certificate for my Unifi router. Does anyone know why and how to fix it?

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.