No external access with duckdns and Nginx Proxy manager

Zitat von BernH

I am going to throw out one question that I don't think was asked.

Do you have any firewall rules engaged on OMV?

If you do, they may be blocking traffic that is not originating from your LAN, so if so, disable the firewall as a test.

If you don't, my only though is that there is something strange with your router. I am not familiar with the brand, but perhaps have a closer look at it to make shure there are no other traffic filters engaged. Perhaps a cold restart of it may help too, just in case it's stored routing tables need to be refreshed (I have seen this on occasion).

Alles anzeigen

No, I don't have any kind of firewall active, in fact I tried to activate it with all the rules and I didn't have any result either.

As for the router, when I opened the ports I restarted it and the result is the same. I also restarted it after a week as usual and it didn't work either. I also left the router off all night to try it and it didn't work either.

Zitat von chente

I would set up a Wireguard connection just to rule out problems with the router. If it works, it means that the domain is correctly configured and the router allows the connection. https://wiki.omv-extras.org/do…v7:omv7_plugins:wireguard

Once this was verified, I would start from scratch to configure the NPM or Swag container following the recommendations in this document. https://wiki.omv-extras.org/doku.php?id=omv7:docker_in_omv

I have followed both guides that you have published, with the wireguard service I have not had any problem, I have connected with the mobile and I have been a while browsing different sites and it works without problems with my domain. I have configured docker also with the guide, I have installed NPM and swag and the result is the same, locally if I have access, but externally without result.

Zitat von Soma

The only other thing I thought of is to put that LAN device on DMZ.

This is a last resource that will put the device wide open to the WAN.

Can be just to test but this will require a proper setup with firewall rules on the device.

If it works then the router is doing something that blocks the portfward to the LAN device.

If it doesn't work, well...

Back to square 1.

Alles anzeigen

I have also tried in DMZ, restarting the router and nothing, the result is the same. Locally it works, but outside the local network it does not.

Zitat von chente

At least that guarantees that your domain is working fine and that the router is not the problem either. So all that's left is your container configuration.

This is my docker compose of swag

version: "2.1"
services:
  swag:
    image: lscr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1003 (user appuser)
      - PGID=100  (group users)
      - TZ=Europe/Madrid
      - URL=mysubdomain.duckdns.org
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
      - DUCKDNSTOKEN=mytockensuperlarge
    volumes:
      - ./swag:/config (/appdata path)
    ports:
      - 443:443
      - 80:80
    restart: unless-stopped

Zitat von BernH

I the ISP. I had an ISP about 25 years ago that blocked inbound traffic on standard HTTP/HTTPS and FTP ports to try to force opeople that wanted to run some kind of server to pay them extra for a "hosting" or "business" plan.

I do not think it is the case of Movistar/O2, because I have clients that have Movistar/O2 and I have configured other NAS (mostly synology and xpenology) with the domain of those clients and I have not had any problem, I only had to open the necessary ports and that was it. Most customers had a "domestic" connection in their business.

Zitat von BernH

- ./swag:/config (/appdata path)

Is that really your volume mapping or is this a copy/paste error. It has no persistent data mapped and the (/appdata path) will cause errors as it is not a valid path

actually all the stuff in brackets will cause errors. comments should be preceded by a #

Alles anzeigen

Yes, that is the route I have mapped, I added the brackets when I made the publication, my fault for not commenting them.

Zitat von Soma

Why are you using that volume?

You are creating SWAG folder inside the docker root which has very specific permissions that UID 1003 won't see.

The volume must be accessible by the UID and that is why ALL guides on the forum say to use a full path (to a different disk even better) on the volumes so they persist across reboots/rebuilts.

If you just created UID 1003 appuser to run containers, then make the configs for the YMLs unique.

For eg, like I told you way back (delete that folder if it exists because, at the time, you were using UID 1000)

Code

    volumes:
      - /appdata/swag/config:/config

This will launch the container with proper permissions(UID:GID 1003:100) and create a:

appdata folder inside /

a swag folder inside /appdata/

a config folder inside /appdata/swag/

If you don't want them to be inside / just change /appdata with /srv-dev-disk-by-uuid-xxxxyyyyy (where this is a seperate drive on the system with ext4 FS)

Or just make a SYMLINK to point /srv-dev-disk-by-uuid-xxxxyyyyy to /appdata

When launching other containers, all you need for the config folder is:

Code

/appdata/<CONTAINER-NAME>/config:/config

That way, you always know where to get/edit files of the container from the host CLI.

The way you have up there ( ./swag) can you even figure out where the config folder is to change the proxy samples?

Alles anzeigen

That user I have created with all permissions so that it can use docker, including to that path I have created. I do not have any problem in that the folders are created in the root.

Zitat von Nefertiti

Maybe the OP should use the ports in swag like mine, open those TCP port in his router and see if he got a certificate from swag

Also the OP did not mention if he was using 2 routers in cascade in that case it could be double NAT

Spoiler anzeigen

Code

  ports:
     - 450:443  
     -  90:80 

No, I only have the router from the operator. I tried before to change other ports in the compose and open those ports in the router and the result is the same, without success.

Zitat von chente

cl0v3r_404

Since this thread is getting very long and there seems to be no solution for Swag, here is a guide that may help you if you want to try NPM again. If you follow it from the beginning there is no possible error.

Thema

OMV Quick Configuration Guide

OMV QUICK CONFIGURATION GUIDE


This is a quick guide to make a standard OMV setup with samba and several docker containers running.
Just follow the steps. This is for those users who want to get their server up and running quickly. There are no explanations, if you need to understand something about what you are doing consult the openmediavault documentation and omv-extras to find the information, everything is explained there.


ISSUES TO CONSIDER

• This procedure is designed for a system with a single

…

chente

27. August 2023

I will try to follow the guide on another piece of equipment I have for testing.

I finally managed to get swag working from outside, it turns out that the Movistar router I have, has mapped port 443 for remote administration, and after reading the Movistar forums and doing a nmap -F my.public.ip I only got port 80 open. In the Movistar forums they said that in the advanced interface in the section Manteinance > Remote MGMT > WWW is port 80 and 443, port 80 is set to LAN while port 443 is set to WAN & LAN, they said that port 443 should be changed to LAN to free the port or directly change that port to another one. I have changed it to "LAN" without changing the port and so far it has started working.

I have not tried with NPM, because as they say, if it works don't touch it .