splerman Posted May 20, 2020 Share Posted May 20, 2020 I'm trying to configure my linuxserver/letsencrypt reverse proxy to do source-IP-based access control and authentication for various applications. I'm using sonarr as my test application (with its own authentication disabled). My intended restrictions are shown, below. It works for Private LAN, Guest Wi-Fi and Elsewhere. OpenVPN clients, however are being denied (403 Forbidden) even though they should be allowed. I'm using an iPad (Safari) as my test device since it is easy to disconnect from the LAN/Wi-Fi and reconnect via the VPN over LTE. I wonder/suspect that OpenVPN's use of NAT might be causing the problem. I also wonder if caching on the iPad/Safari is causing some unexpected results as certain inconsistencies seem to be happening over repeated test cycles. OpenVPN access is being provided by linuxserver/openvpn-as. Configs are all provided, below. Is it logical that NAT would cause problems? If so, is there a fix that can be done without changing the OpenVPN AS configuration? If the answer is to reconfigure the OpenVPN AS for routing instead of NAT, guidance on specifics are appreciated as I previously tried reconfiguring for Routing, but couldn't get it working (Changed OpenVPN's VPN config to use routing, added route in my internet access router such that Next Hop for 172.27.224.0/20 was the IP of the Unraid Server...Wasn't sure how to add a route in Unraid pointing 172.27.224.0/20 to the OpenVPN AS container, though....for now I've reverted back to NAT config). My goal is as follows: # Intended Access Restrictions and Authentication Requirements: # Private LAN (192.168.1.0/24): Access Allowed; No Authentication # OpenVPN Clients (172.27.224.0/20): Access Allowed; No Authentication # Guest Wi-Fi (192.168.2.0/24): Access Allowed; Authentication Required # Elsewhere (incl. Public Internet): Denied Here's my docker run command for letsencrypt: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='letsencrypt' --net='proxynet' --privileged=true -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'EMAIL'='[email protected]' -e 'URL'='xyz.com' -e 'SUBDOMAINS'='bazarr,calibre,ds-one,ds-two,jackett,jdownloader,mail,nzbget,ombi,qbittorrent,radarr,sonarr,speedtest,tautulli,unifi,unraid,webdav,www,nextcloud,onlyoffice,openvpn' -e 'ONLY_SUBDOMAINS'='true' -e 'DHLEVEL'='2048' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'PUID'='99' -e 'PGID'='100' -p '80:80/tcp' -p '443:443/tcp' -v '/mnt/user/appdata/letsencrypt':'/config':'rw' 'linuxserver/letsencrypt' c9d6dd6d8b23f11c7532f2a47582d1acaff3ee958a5aa1xxxxxde0c9e1d1f2e7 The command finished successfully! Here's my sonarr.subdomain.conf: # Sonarr reverse proxy config for NGINX # File location: \\unraid\appdata\letsencrypt\nginx\proxy-confs\sonarr.subdomain.com # Modified from sonarr.subdomain.conf.sample # Make sure that your dns has a cname set for sonarr and that your sonarr container is not using a base url # Intended Access Restrictions and Authentication Requirements: # Private LAN (192.168.1.0/24): Access Allowed; No Authentication # OpenVPN Clients (172.27.224.0/20): Access Allowed; No Authentication # Guest Wi-Fi (192.168.2.0/24): Access Allowed; Authentication Required # Elsewhere (incl. Public Internet): Denied # Set $allowed_ips to 1 if the client ip is in an allowed range else set to 0 to deny. geo $allowed_ips { default 0; 192.168.1.0/24 1; 192.168.2.0/24 1; 172.27.224.0/20 1; } # Set $authentication to "Authentication Required" if nginx authentication required of the client ip # else set to "off". geo $authentication { default "Authentication Required"; 192.168.1.0/24 "off"; 192.168.2.0/24 "Authentication Required"; 172.27.224.0/20 "off"; } server { listen 443 ssl; listen [::]:443 ssl; server_name sonarr.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # if allowed_ips is 0, then the login is from an IP address that is excluded, so return 403 Forbidden if ( $allowed_ips = 0 ) { return 403; } # if authentication is required, $authentication set to "Authentication Required" above, # otherwise, $authentication set to "off" above. auth_basic $authentication; auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app sonarr; set $upstream_port 8989; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location ~ (/sonarr)?/api { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app sonarr; set $upstream_port 8989; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } My openvpn-as docker run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='openvpn-as' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'PGID'='100' -e 'PUID'='99' -p '943:943/tcp' -p '9443:9443/tcp' -p '1194:1194/udp' -v '/mnt/user/appdata/openvpn-as':'/config':'rw' --cap-add=NET_ADMIN 'linuxserver/openvpn-as' f346af968420c62654e0ee992debd831a24b313eb0e71xxxxxfafd28641111 The command finished successfully! My OpenVPN AS VPN Config: Quote Link to comment
aptalca Posted May 20, 2020 Share Posted May 20, 2020 3 hours ago, splerman said: I'm trying to configure my linuxserver/letsencrypt reverse proxy to do source-IP-based access control and authentication for various applications. I'm using sonarr as my test application (with its own authentication disabled). My intended restrictions are shown, below. It works for Private LAN, Guest Wi-Fi and Elsewhere. OpenVPN clients, however are being denied (403 Forbidden) even though they should be allowed. I'm using an iPad (Safari) as my test device since it is easy to disconnect from the LAN/Wi-Fi and reconnect via the VPN over LTE. I wonder/suspect that OpenVPN's use of NAT might be causing the problem. I also wonder if caching on the iPad/Safari is causing some unexpected results as certain inconsistencies seem to be happening over repeated test cycles. OpenVPN access is being provided by linuxserver/openvpn-as. Configs are all provided, below. Is it logical that NAT would cause problems? If so, is there a fix that can be done without changing the OpenVPN AS configuration? If the answer is to reconfigure the OpenVPN AS for routing instead of NAT, guidance on specifics are appreciated as I previously tried reconfiguring for Routing, but couldn't get it working (Changed OpenVPN's VPN config to use routing, added route in my internet access router such that Next Hop for 172.27.224.0/20 was the IP of the Unraid Server...Wasn't sure how to add a route in Unraid pointing 172.27.224.0/20 to the OpenVPN AS container, though....for now I've reverted back to NAT config). My goal is as follows: # Intended Access Restrictions and Authentication Requirements: # Private LAN (192.168.1.0/24): Access Allowed; No Authentication # OpenVPN Clients (172.27.224.0/20): Access Allowed; No Authentication # Guest Wi-Fi (192.168.2.0/24): Access Allowed; Authentication Required # Elsewhere (incl. Public Internet): Denied Here's my docker run command for letsencrypt: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='letsencrypt' --net='proxynet' --privileged=true -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'EMAIL'='[email protected]' -e 'URL'='xyz.com' -e 'SUBDOMAINS'='bazarr,calibre,ds-one,ds-two,jackett,jdownloader,mail,nzbget,ombi,qbittorrent,radarr,sonarr,speedtest,tautulli,unifi,unraid,webdav,www,nextcloud,onlyoffice,openvpn' -e 'ONLY_SUBDOMAINS'='true' -e 'DHLEVEL'='2048' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'PUID'='99' -e 'PGID'='100' -p '80:80/tcp' -p '443:443/tcp' -v '/mnt/user/appdata/letsencrypt':'/config':'rw' 'linuxserver/letsencrypt' c9d6dd6d8b23f11c7532f2a47582d1acaff3ee958a5aa1xxxxxde0c9e1d1f2e7 The command finished successfully! Here's my sonarr.subdomain.conf: # Sonarr reverse proxy config for NGINX # File location: \\unraid\appdata\letsencrypt\nginx\proxy-confs\sonarr.subdomain.com # Modified from sonarr.subdomain.conf.sample # Make sure that your dns has a cname set for sonarr and that your sonarr container is not using a base url # Intended Access Restrictions and Authentication Requirements: # Private LAN (192.168.1.0/24): Access Allowed; No Authentication # OpenVPN Clients (172.27.224.0/20): Access Allowed; No Authentication # Guest Wi-Fi (192.168.2.0/24): Access Allowed; Authentication Required # Elsewhere (incl. Public Internet): Denied # Set $allowed_ips to 1 if the client ip is in an allowed range else set to 0 to deny. geo $allowed_ips { default 0; 192.168.1.0/24 1; 192.168.2.0/24 1; 172.27.224.0/20 1; } # Set $authentication to "Authentication Required" if nginx authentication required of the client ip # else set to "off". geo $authentication { default "Authentication Required"; 192.168.1.0/24 "off"; 192.168.2.0/24 "Authentication Required"; 172.27.224.0/20 "off"; } server { listen 443 ssl; listen [::]:443 ssl; server_name sonarr.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # if allowed_ips is 0, then the login is from an IP address that is excluded, so return 403 Forbidden if ( $allowed_ips = 0 ) { return 403; } # if authentication is required, $authentication set to "Authentication Required" above, # otherwise, $authentication set to "off" above. auth_basic $authentication; auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app sonarr; set $upstream_port 8989; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location ~ (/sonarr)?/api { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app sonarr; set $upstream_port 8989; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } My openvpn-as docker run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='openvpn-as' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'PGID'='100' -e 'PUID'='99' -p '943:943/tcp' -p '9443:9443/tcp' -p '1194:1194/udp' -v '/mnt/user/appdata/openvpn-as':'/config':'rw' --cap-add=NET_ADMIN 'linuxserver/openvpn-as' f346af968420c62654e0ee992debd831a24b313eb0e71xxxxxfafd28641111 The command finished successfully! My OpenVPN AS VPN Config: Check the nginx logs to see what ip is listed as the source when you connect over vpn. I suspect it will look like the openvpn container ip as everything is nat'ed through that Quote Link to comment
splerman Posted May 20, 2020 Share Posted May 20, 2020 (edited) Aptalca, thanks for your help! On the iPad test client, the IP address shown in the OpenVPN Connect app shows 172.27.224.16 (as expected). Unexpectedly, the nginx access log shows the request from 172.18.0.1 which is on my proxynet bridge. My OpenVPN container is on the default bridge (172.17.0.0). My LetsEncrypt container is on the proxynet bridge (172.18.0.0). Below are: access.log snippet, container info, docker network info. /mnt/user/appdata/letsencrypt/log/nginx/access.log entry: 172.18.0.1 - - [20/May/2020:11:12:56 -0700] "GET / HTTP/2.0" 403 114 "-" "Mozilla/5.0 (iPad; CPU OS 13_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Mobile/15E148 Safari/604.1" Container info (partial): Docker network info: root@Unraid:~# docker network ls NETWORK ID NAME DRIVER SCOPE 149dad2b001d br0 macvlan local 437fa80d49a7 bridge bridge local 313e86ebe6bd host host local affa87359514 none null local 5ae677f41049 proxynet bridge local root@Unraid:~# docker network inspect proxynet [ { "Name": "proxynet", "Id": "5ae677f41049b95bfa835bac27ed63d6d464c722ab4255eda0028f5e9c998e00", "Created": "2020-04-18T17:03:47.028748092-07: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": { "02050bac056c89c8b47cae9eda4efa6ffe3c69782b886bb00ae6006e20539a25": { "Name": "OnlyOfficeDocumentServer", "EndpointID": "679e1b80e980b59336fe67ba50d1f223a53d17ffe73ab442dd815a8a13a608d6", "MacAddress": "02:42:ac:12:00:02", "IPv4Address": "172.18.0.2/16", "IPv6Address": "" }, "1dbdd858a0d4dd5e3426e1c26d26ba9e32f8b086bd23e19a7efdca2e7dd936f6": { "Name": "ombi", "EndpointID": "4fd43f7fea67613418c38cf0bc72a1685d2c928635d45a991b60b9caaaf6f18a", "MacAddress": "02:42:ac:12:00:0a", "IPv4Address": "172.18.0.10/16", "IPv6Address": "" }, "2620cff940e83d7c276f9bde5f7d8fff46a813b1a8bdbd99b6f71c22901faf57": { "Name": "tautulli", "EndpointID": "90eea69636fc7846eb575eb2fbe585e4f39c5daeb86f8dfb901cbfc68dfae343", "MacAddress": "02:42:ac:12:00:0e", "IPv4Address": "172.18.0.14/16", "IPv6Address": "" }, "6eb5aea45d378db636b8b9c744f5f1634d6a5d3673ff86bd0233f2e9aafbe3ed": { "Name": "jdownloader2", "EndpointID": "cad9e26a7d197d99fba67523a182c80b5d4b482303437dc9cc61ce3785ae7b4c", "MacAddress": "02:42:ac:12:00:06", "IPv4Address": "172.18.0.6/16", "IPv6Address": "" }, "705a5e1ac3222aea179316986fe818977fcb23a346a0134c69f12d1b5e73fbc9": { "Name": "bazarr", "EndpointID": "1450dcd8f398b91639519ba2c751828dc6cf43e05a58a9abe378ab07c8e1da8d", "MacAddress": "02:42:ac:12:00:09", "IPv4Address": "172.18.0.9/16", "IPv6Address": "" }, "758dbc99154c4a025ae06659f1bd7bdac17a83444085d032d50ba0cdf30246d6": { "Name": "nzbget", "EndpointID": "3a340a9f4885df99031b9a5f2214a4c5817bcb42c5d370657a56ce2a904ab903", "MacAddress": "02:42:ac:12:00:07", "IPv4Address": "172.18.0.7/16", "IPv6Address": "" }, "90f2c7c3aa2e0ad89617ac94f691bd9ab175869d33e032d7f2c51ff60470dc27": { "Name": "jackett", "EndpointID": "60e2cbc4b13cca79749f460dd553bf85b8f69d5efb65c9fbe4c9c580230fe9e0", "MacAddress": "02:42:ac:12:00:08", "IPv4Address": "172.18.0.8/16", "IPv6Address": "" }, "bcbee02b8813c0bf5cc9b2bccfd0bc80ef29541e1eceecffb251b16baf143aaf": { "Name": "sonarr", "EndpointID": "2daa793d8b9614f2e5b56d107e59552ae8fd55bea774392972106a7c739bcb5c", "MacAddress": "02:42:ac:12:00:0c", "IPv4Address": "172.18.0.12/16", "IPv6Address": "" }, "bd382d8507a1c149c4a226adc357c53037a8842da7dfeedacd8e5dae880936d8": { "Name": "qbittorrentvpn", "EndpointID": "41c3c4f0e2e9aaa44df261ab81848f7faeee09fa1addd81adf9e742121997610", "MacAddress": "02:42:ac:12:00:04", "IPv4Address": "172.18.0.4/16", "IPv6Address": "" }, "c62348028dc05ee1e8566d24f5a8054cf76a66a4ff29407ef40cbfe09e2afc3f": { "Name": "nextcloud", "EndpointID": "c75c006b4da635a445cffcadac6c1e848728a6c9af4e7068acabdcb68db5bb0b", "MacAddress": "02:42:ac:12:00:05", "IPv4Address": "172.18.0.5/16", "IPv6Address": "" }, "c9d6dd6d8b23f11c7532f2a47582d1acaff3ee958a5aa125701de0c9e1d1f2e7": { "Name": "letsencrypt", "EndpointID": "862f45a2a60abaf62fee635c7007a87aa5933ee0981820198558bf9cedc2ab4a", "MacAddress": "02:42:ac:12:00:03", "IPv4Address": "172.18.0.3/16", "IPv6Address": "" }, "e8b128855c0a5348a0fe6ab166b0c455606807883d97242fe66f2edb311795be": { "Name": "speedtest", "EndpointID": "72383d32bd5850e3d37b2ffad45ff8692d1ba9780032ca16bdfac494f9034de1", "MacAddress": "02:42:ac:12:00:0d", "IPv4Address": "172.18.0.13/16", "IPv6Address": "" }, "e963268e039e7cd6d528aa421754eb13eee0fe9df4b918896b6ff1c152c0e135": { "Name": "radarr", "EndpointID": "23e892d51e30e0f78eeaf221c491941756980a61a9e17bcba3bb141c127bfee0", "MacAddress": "02:42:ac:12:00:0b", "IPv4Address": "172.18.0.11/16", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] root@Unraid:~# root@Unraid:~# docker network inspect bridge [ { "Name": "bridge", "Id": "437fa80d49a7831da11f2445567a2de643864b51a34af81c8b915a65481df4d5", "Created": "2020-05-17T10:06:03.195877445-07:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "3e08c9fff6fc580cd1835ec96c9b1c98ecdf1c4232e12ff288ece8d023d013e4": { "Name": "elasticsearch", "EndpointID": "b25e13dff119e76964caef6fe722fd813f88880583d0dd60fc752e7822b956eb", "MacAddress": "02:42:ac:11:00:02", "IPv4Address": "172.17.0.2/16", "IPv6Address": "" }, "439e932ed823ea325d099a5767fa8867cf486377f8f96685bea6a46a0490b0e7": { "Name": "lidarr", "EndpointID": "0da41c47467a9415acba4aa72c094f000b330a891bb3635108ffecc0daa5fb3a", "MacAddress": "02:42:ac:11:00:07", "IPv4Address": "172.17.0.7/16", "IPv6Address": "" }, "5237888648d1fcd0d9792193dd54e2432cde243d6ef20a77e377be43a3553cb1": { "Name": "openvpn-as", "EndpointID": "16431efb9ea54d2bda33c3713f98cd535d3d00c71f42811f63314d10c7489057", "MacAddress": "02:42:ac:11:00:04", "IPv4Address": "172.17.0.4/16", "IPv6Address": "" }, "65248dfc94c25a7485882a3dbd48c4da8ac58179fa4f4c4803114d44b3dac873": { "Name": "redis", "EndpointID": "dd9ec7030c30e47874c5679f06c36d3689045cc53816c448e452e83ede0e567f", "MacAddress": "02:42:ac:11:00:03", "IPv4Address": "172.17.0.3/16", "IPv6Address": "" }, "aa062c0fa4041c2a9676202c72da919df48592a309ff9c6a13ac1c640e1c1607": { "Name": "organizr", "EndpointID": "9126ef981eddc21b8ef8d43efa2c6d6cf31c992b61c660cc98a54ae8f5909c19", "MacAddress": "02:42:ac:11:00:08", "IPv4Address": "172.17.0.8/16", "IPv6Address": "" }, "c24e58e44b01beb2536dfe7c2ecb4f869d5d047f503012d2971012c663b2ebdc": { "Name": "mariadb", "EndpointID": "eff2c3185176af3031737da4d79aff7c71f79d0728dbb51956bd646be846f983", "MacAddress": "02:42:ac:11:00:05", "IPv4Address": "172.17.0.5/16", "IPv6Address": "" }, "d325c927cc9194be5312f9fa4881cc36c46a8a38003e44aa6fc2bf5ffdd6a6d0": { "Name": "krusader", "EndpointID": "0b616363699fb5763aed7e9e20f72623b2855b952b852197f9055316b5e9bbe9", "MacAddress": "02:42:ac:11:00:06", "IPv4Address": "172.17.0.6/16", "IPv6Address": "" }, "f6c06ab541d3c95ec5600a243bb02a6cf46449e576c6dd146afcb726e32ffa79": { "Name": "tdarr", "EndpointID": "d49379cd418dcd2b23a74d07e6a8ad41f827736f219942595d36b5a637054dcb", "MacAddress": "02:42:ac:11:00:09", "IPv4Address": "172.17.0.9/16", "IPv6Address": "" } }, "Options": { "com.docker.network.bridge.default_bridge": "true", "com.docker.network.bridge.enable_icc": "true", "com.docker.network.bridge.enable_ip_masquerade": "true", "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0", "com.docker.network.bridge.name": "docker0", "com.docker.network.driver.mtu": "9000" }, "Labels": {} } ] root@Unraid:~# Edited May 20, 2020 by splerman Quote Link to comment
Jaster Posted May 22, 2020 Share Posted May 22, 2020 On 5/19/2020 at 8:48 PM, saarg said: Is it on the same custom bridge as letsencrypt and the container name is all lowercase? yep Quote Link to comment
KoNeko Posted May 22, 2020 Share Posted May 22, 2020 got a few questions. i installed this and i get a certificate from letsencrypt via DNS transip. that seems to work Does this docker automatically renew the cert? i got the www. also working and i see the page Welcome to our server The website is currently being setup under this address. For help and support, please contact: [email protected] but when i put a image file in the same directory or in a directory i make in there it doesnt show it. Quote Link to comment
saarg Posted May 22, 2020 Share Posted May 22, 2020 2 hours ago, Jaster said: yep And if you exec into letsencrypt and try to ping nextcloud? Also post your run commands for both letsencrypt and nextcloud and the proxy conf for nextcloud. Quote Link to comment
saarg Posted May 22, 2020 Share Posted May 22, 2020 9 minutes ago, KoNeko said: got a few questions. i installed this and i get a certificate from letsencrypt via DNS transip. that seems to work Does this docker automatically renew the cert? i got the www. also working and i see the page Welcome to our server The website is currently being setup under this address. For help and support, please contact: [email protected] but when i put a image file in the same directory or in a directory i make in there it doesnt show it. It renews the cert automatically. You do have to learn html to add the image. It's not just to add it to a folder. Quote Link to comment
KoNeko Posted May 22, 2020 Share Posted May 22, 2020 (edited) 11 minutes ago, saarg said: It renews the cert automatically. You do have to learn html to add the image. It's not just to add it to a folder. i dont mean to the page it self. i know how to code html/php etc. i just added a file and want to direct access it. like https://mydomain.com/directory/file.png Edit: no idea what happend but after i restarted the docker its working Edited May 22, 2020 by KoNeko Quote Link to comment
Killabee44 Posted May 24, 2020 Share Posted May 24, 2020 Hello everyone, I am having an issue with a certificate that won't renew automatically like it should. I did get notifications but have been too busy to tackle this issue. My cert expired last night. Here is my letsencrypt log: 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/New_York URL=mydomain.com SUBDOMAINS=server,nextcloud,sonarr EXTRA_DOMAINS= ONLY_SUBDOMAINS=true DHLEVEL=2048 VALIDATION=http DNSPLUGIN= [email protected] STAGING= 2048 bit DH parameters present SUBDOMAINS entered, processing SUBDOMAINS entered, processing Only subdomains, no URL in cert Sub-domains processed are: -d server.mydomain.com -d nextcloud.mydomain.com -d sonarr.mydomain.com E-mail address entered: [email protected] http validation is selected Different validation parameters entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created Generating new certificate Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for nextcloud.mydomain.com http-01 challenge for server.mydomain.com http-01 challenge for sonarr.mydomain.com Waiting for verification... Challenge failed for domain sonarr.mydomain.com http-01 challenge for sonarr.mydomain.com Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server: Domain: sonarr.mydomain.com Type: dns Detail: DNS problem: NXDOMAIN looking up A for sonarr.mydomain.com - check that a DNS record exists for this - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. 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 And here is an error I am getting over and over again in my Unraid log : May 24 00:56:23 RSUNR nginx: 2020/05/24 00:56:23 [error] 7100#7100: *146195 connect() to unix:/var/tmp/letsencrypt.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.1.29, server: , request: "GET /dockerterminal/letsencrypt/ws HTTP/1.1", upstream: "http://unix:/var/tmp/letsencrypt.sock:/ws", host: "rsunr" 192.168.1.29 is the address of the desktop I use to access my Unraid server in my home network. Not sure about this error.. I did try to add and remove a subdomain in order to get it to renew the cert. Please let me know if I should upload any other logs that can help troubleshoot this issue. Thanks to anyone that can chime in and help. Quote Link to comment
aptalca Posted May 24, 2020 Share Posted May 24, 2020 37 minutes ago, Killabee44 said: Hello everyone, I am having an issue with a certificate that won't renew automatically like it should. I did get notifications but have been too busy to tackle this issue. My cert expired last night. Here is my letsencrypt log: 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/New_York URL=mydomain.com SUBDOMAINS=server,nextcloud,sonarr EXTRA_DOMAINS= ONLY_SUBDOMAINS=true DHLEVEL=2048 VALIDATION=http DNSPLUGIN= [email protected] STAGING= 2048 bit DH parameters present SUBDOMAINS entered, processing SUBDOMAINS entered, processing Only subdomains, no URL in cert Sub-domains processed are: -d server.mydomain.com -d nextcloud.mydomain.com -d sonarr.mydomain.com E-mail address entered: [email protected] http validation is selected Different validation parameters entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created Generating new certificate Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for nextcloud.mydomain.com http-01 challenge for server.mydomain.com http-01 challenge for sonarr.mydomain.com Waiting for verification... Challenge failed for domain sonarr.mydomain.com http-01 challenge for sonarr.mydomain.com Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server: Domain: sonarr.mydomain.com Type: dns Detail: DNS problem: NXDOMAIN looking up A for sonarr.mydomain.com - check that a DNS record exists for this - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. 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 And here is an error I am getting over and over again in my Unraid log : May 24 00:56:23 RSUNR nginx: 2020/05/24 00:56:23 [error] 7100#7100: *146195 connect() to unix:/var/tmp/letsencrypt.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.1.29, server: , request: "GET /dockerterminal/letsencrypt/ws HTTP/1.1", upstream: "http://unix:/var/tmp/letsencrypt.sock:/ws", host: "rsunr" 192.168.1.29 is the address of the desktop I use to access my Unraid server in my home network. Not sure about this error.. I did try to add and remove a subdomain in order to get it to renew the cert. Please let me know if I should upload any other logs that can help troubleshoot this issue. Thanks to anyone that can chime in and help. It tells you right there in the log. Fix your dns entry for the sonarr subdomain Quote Link to comment
uek2wooF Posted May 24, 2020 Share Posted May 24, 2020 After days or weeks of running fine my letsencrypt docker logs start filling up with this and all my nginx stuff goes down: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use) nginx: [emerg] bind() to [::]:80 failed (98: Address in use) nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address in use) nginx: [emerg] bind() to [::]:443 failed (98: Address in use I tried nginx -s reload and it says it can't find the pidfile. I tried running logrotate again (with the command from the crontabs) and that doesn't fix it. Any ideas what is causing this? Quote Link to comment
saarg Posted May 24, 2020 Share Posted May 24, 2020 (edited) 1 hour ago, uek2wooF said: After days or weeks of running fine my letsencrypt docker logs start filling up with this and all my nginx stuff goes down: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use) nginx: [emerg] bind() to [::]:80 failed (98: Address in use) nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address in use) nginx: [emerg] bind() to [::]:443 failed (98: Address in use I tried nginx -s reload and it says it can't find the pidfile. I tried running logrotate again (with the command from the crontabs) and that doesn't fix it. Any ideas what is causing this? Both 80 and 443 is already in use. If you are been running commands inside the container that might be the reason. Restart the container and see if the error is still there. Might be a good idea to post your docker run command and what you have changed lately. Edited May 24, 2020 by saarg Quote Link to comment
uek2wooF Posted May 25, 2020 Share Posted May 25, 2020 (edited) 20 hours ago, saarg said: Both 80 and 443 is already in use. If you are been running commands inside the container that might be the reason. Restart the container and see if the error is still there. Might be a good idea to post your docker run command and what you have changed lately. Restarting the container makes everything run fine again, for a week or so. The docker run command isn't really exposed for community apps in unraid that I can tell. I think it is somehow dynamically created. I don't really tinker with unraid much lately so I can't think of anything that has changed. I did add another nginx conf file for another host and this problem started a couple of weeks after that. But if there was a problem with the conf why would it work fine for a couple of weeks first? It looks like 3 things run out of cron, logrotate, libmaxmindb, and /app/le-renew.sh. That last one is for renewing certs and it restarts nginx. I bet that one is the problem. I guess I will disable it and just set a calendar reminder to manually renew the certs. Edited May 25, 2020 by uek2wooF Quote Link to comment
saarg Posted May 25, 2020 Share Posted May 25, 2020 1 hour ago, uek2wooF said: Restarting the container makes everything run fine again, for a week or so. The docker run command isn't really exposed for community apps in unraid that I can tell. I think it is somehow dynamically created. I don't really tinker with unraid much lately so I can't think of anything that has changed. I did add another nginx conf file for another host and this problem started a couple of weeks after that. But if there was a problem with the conf why would it work fine for a couple of weeks first? It looks like 3 things run out of cron, logrotate, libmaxmindb, and /app/le-renew.sh. That last one is for renewing certs and it restarts nginx. I bet that one is the problem. I guess I will disable it and just set a calendar reminder to manually renew the certs. The run command is easily found if you make a change in the container template and hit apply. Just remove a character and add it again and you can hit apply. You have to restart the container for changes to be applied after you copy in a new config. Might have been your cert was renewed and then it loaded the new config you added. You haven't supplied anything else than a small snippet of the log, so hard to say what the issue is. If it would have been an issue with the container, far more people would have reported the issue, so it's most likely a local issue. Do not run any NGINX reload commands inside the container as that will cause what you see. Quote Link to comment
aptalca Posted May 25, 2020 Share Posted May 25, 2020 1 hour ago, uek2wooF said: Restarting the container makes everything run fine again, for a week or so. The docker run command isn't really exposed for community apps in unraid that I can tell. I think it is somehow dynamically created. I don't really tinker with unraid much lately so I can't think of anything that has changed. I did add another nginx conf file for another host and this problem started a couple of weeks after that. But if there was a problem with the conf why would it work fine for a couple of weeks first? It looks like 3 things run out of cron, logrotate, libmaxmindb, and /app/le-renew.sh. That last one is for renewing certs and it restarts nginx. I bet that one is the problem. I guess I will disable it and just set a calendar reminder to manually renew the certs. You're manually running commands inside the container and heavily customizing it, therefore we can no longer provide support. Quote Link to comment
uek2wooF Posted May 25, 2020 Share Posted May 25, 2020 trying to debug your broken container isnt what broke it Quote Link to comment
uek2wooF Posted May 25, 2020 Share Posted May 25, 2020 Why are you using s6-svc to reload nginx after a cert renew instead of nginx -s reload anyway? If adding a conf file is heavy customization then how else do you suggest using it? Quote Link to comment
biggeek Posted May 25, 2020 Share Posted May 25, 2020 Saw this today and curious if I should be concerned. I did get a free license key, created a new variable as instructed and entered the key. Downloading GeoIP2 City database. tar: invalid tar magic Quote Link to comment
KoNeko Posted May 25, 2020 Share Posted May 25, 2020 i installed yesterday the container and it worked. i saw there was a update and it did the update when i was sleeping. In the morning i saw that the docker container was gone. The data directory is still there. When i load the docker again it isnt working. I didnt change anything on the settings since i got it running perfectly. Any idea? Quote Link to comment
saarg Posted May 25, 2020 Share Posted May 25, 2020 5 hours ago, uek2wooF said: trying to debug your broken container isnt what broke it Ke? Quote Link to comment
saarg Posted May 25, 2020 Share Posted May 25, 2020 4 hours ago, KoNeko said: i installed yesterday the container and it worked. i saw there was a update and it did the update when i was sleeping. In the morning i saw that the docker container was gone. The data directory is still there. When i load the docker again it isnt working. I didnt change anything on the settings since i got it running perfectly. Any idea? You have something invalid in your container template, so when the container is created it fails and therefor is removed from the list as there is no letsencrypt container anymore. Most likely port 80 or 443 is in use. Click add container, choose letsencrypt and hit apply and you will probably see the error. Quote Link to comment
aptalca Posted May 25, 2020 Share Posted May 25, 2020 7 hours ago, biggeek said: Saw this today and curious if I should be concerned. I did get a free license key, created a new variable as instructed and entered the key. Downloading GeoIP2 City database. tar: invalid tar magic Post your full log. It worked when I tested it Quote Link to comment
KoNeko Posted May 26, 2020 Share Posted May 26, 2020 (edited) 6 hours ago, saarg said: You have something invalid in your container template, so when the container is created it fails and therefor is removed from the list as there is no letsencrypt container anymore. Most likely port 80 or 443 is in use. Click add container, choose letsencrypt and hit apply and you will probably see the error. i didnt change anything in the template. every docker has its own IP. even if it was that it was a port problem which it didnt say it should not remove the docker at all it should just have stopped it. i had reinstalled it and i had it stopped. SO it isnt running. But when i just checked its removed again. Edited May 26, 2020 by KoNeko Quote Link to comment
Shamalamadindong Posted May 26, 2020 Share Posted May 26, 2020 Anyone happen to know if there's a writeup or container coming up for Authelia? I noticed some config files were added. 1 Quote Link to comment
saarg Posted May 26, 2020 Share Posted May 26, 2020 6 hours ago, KoNeko said: i didnt change anything in the template. every docker has its own IP. even if it was that it was a port problem which it didnt say it should not remove the docker at all it should just have stopped it. i had reinstalled it and i had it stopped. SO it isnt running. But when i just checked its removed again. When a container is updated, unraid first pull the new image, then stops the old container, deletes it and create a new container. If there is an error creating the container, the container is deleted from the list as it have not been created. This is how unraid works, so nothing we can do anything about. You have to find out why the container can't be created again. Force update it and you will se the error. We can't help when you don't post logs or error messages. 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.