No external access with duckdns and Nginx Proxy manager

    • Offizieller Beitrag
    Zitat von Soma

    This is strange and the only thing that comes to mind is that you are behind a CGNAT and you can't reach you server, even if the cert is being emitted (don't know but maybe chente can give some input )

    The OP is from Spain and his ISP is Movistar. As far as I know, Movistar in Spain does not use CGNAT.

    I am not on a CG-NAT because I called my carrier to see if I was and was told that they do not activate CG-NAT and that I did not have it activated.


    curl ifconfig.me

    81.38.27.96


    ip a

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether e8:39:35:ec:f2:18 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.250/24 brd 192.168.1.255 scope global enp2s0

    valid_lft forever preferred_lft forever

    3: br-34bfa25ab7a4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:d2:d2:e6:0e brd ff:ff:ff:ff:ff:ff

    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-34bfa25ab7a4

    valid_lft forever preferred_lft forever

    inet6 fe80::42:d2ff:fed2:e60e/64 scope link

    valid_lft forever preferred_lft forever

    4: br-5ba693ce1d44: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:30:89:2b:be brd ff:ff:ff:ff:ff:ff

    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-5ba693ce1d44

    valid_lft forever preferred_lft forever

    inet6 fe80::42:30ff:fe89:2bbe/64 scope link

    valid_lft forever preferred_lft forever

    5: br-5e71c5dce428: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

    link/ether 02:42:d4:42:58:65 brd ff:ff:ff:ff:ff:ff

    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-5e71c5dce428

    valid_lft forever preferred_lft forever

    6: br-65bb23622f5b: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:6c:06:8e:22 brd ff:ff:ff:ff:ff:ff

    inet 172.25.0.1/16 brd 172.25.255.255 scope global br-65bb23622f5b

    valid_lft forever preferred_lft forever

    inet6 fe80::42:6cff:fe06:8e22/64 scope link

    valid_lft forever preferred_lft forever

    7: br-72a37d882ea5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:8e:a2:6d:68 brd ff:ff:ff:ff:ff:ff

    inet 172.24.0.1/16 brd 172.24.255.255 scope global br-72a37d882ea5

    valid_lft forever preferred_lft forever

    inet6 fe80::42:8eff:fea2:6d68/64 scope link

    valid_lft forever preferred_lft forever

    8: br-19a361055bec: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:d5:ac:4a:c3 brd ff:ff:ff:ff:ff:ff

    inet 172.23.0.1/16 brd 172.23.255.255 scope global br-19a361055bec

    valid_lft forever preferred_lft forever

    inet6 fe80::42:d5ff:feac:4ac3/64 scope link

    valid_lft forever preferred_lft forever

    9: br-7cc835f1789d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:bf:3c:e6:27 brd ff:ff:ff:ff:ff:ff

    inet 172.27.0.1/16 brd 172.27.255.255 scope global br-7cc835f1789d

    valid_lft forever preferred_lft forever

    inet6 fe80::42:bfff:fe3c:e627/64 scope link

    valid_lft forever preferred_lft forever

    10: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:5c:f6:73:2f brd ff:ff:ff:ff:ff:ff

    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

    valid_lft forever preferred_lft forever

    inet6 fe80::42:5cff:fef6:732f/64 scope link

    valid_lft forever preferred_lft forever

    11: br-a21cb77ada16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:d5:5c:81:a5 brd ff:ff:ff:ff:ff:ff

    inet 172.28.0.1/16 brd 172.28.255.255 scope global br-a21cb77ada16

    valid_lft forever preferred_lft forever

    inet6 fe80::42:d5ff:fe5c:81a5/64 scope link

    valid_lft forever preferred_lft forever

    13: vetha2ac542@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether b6:e0:a9:13:2c:cb brd ff:ff:ff:ff:ff:ff link-netnsid 3

    inet6 fe80::b4e0:a9ff:fe13:2ccb/64 scope link

    valid_lft forever preferred_lft forever

    17: veth8f952ca@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default

    link/ether 0a:60:1f:25:16:56 brd ff:ff:ff:ff:ff:ff link-netnsid 7

    inet6 fe80::860:1fff:fe25:1656/64 scope link

    valid_lft forever preferred_lft forever

    19: veth4c5f9f0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-5ba693ce1d44 state UP group default

    link/ether 72:8d:50:45:8c:42 brd ff:ff:ff:ff:ff:ff link-netnsid 0

    inet6 fe80::708d:50ff:fe45:8c42/64 scope link

    valid_lft forever preferred_lft forever

    21: vetha191904@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-a21cb77ada16 state UP group default

    link/ether 52:38:89:98:5c:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 1

    inet6 fe80::5038:89ff:fe98:5cf5/64 scope link

    valid_lft forever preferred_lft forever

    23: veth21e7c12@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether 2e:21:1b:a1:98:b1 brd ff:ff:ff:ff:ff:ff link-netnsid 2

    inet6 fe80::2c21:1bff:fea1:98b1/64 scope link

    valid_lft forever preferred_lft forever

    25: veth15718dd@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether 22:cb:2e:97:c8:e3 brd ff:ff:ff:ff:ff:ff link-netnsid 5

    inet6 fe80::20cb:2eff:fe97:c8e3/64 scope link

    valid_lft forever preferred_lft forever

    27: veth1c35661@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether ba:49:3f:71:d7:df brd ff:ff:ff:ff:ff:ff link-netnsid 8

    inet6 fe80::b849:3fff:fe71:d7df/64 scope link

    valid_lft forever preferred_lft forever

    29: vethb5fc9ad@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-19a361055bec state UP group default

    link/ether de:fc:6f:2e:88:65 brd ff:ff:ff:ff:ff:ff link-netnsid 3

    inet6 fe80::dcfc:6fff:fe2e:8865/64 scope link

    valid_lft forever preferred_lft forever

    31: vethde30d2f@if30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether d6:0f:d8:84:93:fc brd ff:ff:ff:ff:ff:ff link-netnsid 6

    inet6 fe80::d40f:d8ff:fe84:93fc/64 scope link

    valid_lft forever preferred_lft forever

    33: veth931772e@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-65bb23622f5b state UP group default

    link/ether 62:5c:62:46:66:bf brd ff:ff:ff:ff:ff:ff link-netnsid 7

    inet6 fe80::605c:62ff:fe46:66bf/64 scope link

    valid_lft forever preferred_lft forever

    35: veth7688a4e@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-72a37d882ea5 state UP group default

    link/ether 9a:62:9f:df:49:2c brd ff:ff:ff:ff:ff:ff link-netnsid 5

    inet6 fe80::9862:9fff:fedf:492c/64 scope link

    valid_lft forever preferred_lft forever

    37: vethf6535a9@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-34bfa25ab7a4 state UP group default

    link/ether 6e:06:1a:99:a5:c6 brd ff:ff:ff:ff:ff:ff link-netnsid 8

    inet6 fe80::6c06:1aff:fe99:a5c6/64 scope link

    valid_lft forever preferred_lft forever

    39: veth007a9a0@if38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-5ba693ce1d44 state UP group default

    link/ether 5a:91:8e:b4:23:ef brd ff:ff:ff:ff:ff:ff link-netnsid 6

    inet6 fe80::5891:8eff:feb4:23ef/64 scope link

    valid_lft forever preferred_lft forever

    41: vethd103c0c@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7cc835f1789d state UP group default

    link/ether a6:dd:76:24:c3:0e brd ff:ff:ff:ff:ff:ff link-netnsid 4

    inet6 fe80::a4dd:76ff:fe24:c30e/64 scope link

    valid_lft forever preferred_lft forever


    ls -al /var/docker/swag/

    total 48

    drwxr-sr-x 10 root root 4096 feb 27 19:35 .

    drwxr-sr-x 6 root users 4096 feb 27 19:35 ..

    drwxr-sr-x 2 root root 4096 feb 28 14:03 dns-conf

    -rw-r--r-- 1 root root 241 feb 28 14:03 .donoteditthisfile.conf

    drwxr-sr-x 3 root root 4096 feb 27 19:35 etc

    drwxr-sr-x 4 root root 4096 feb 27 19:36 fail2ban

    drwxr-sr-x 2 root root 4096 feb 28 14:03 keys

    drwxr-sr-x 6 root root 4096 feb 27 19:35 log

    -rw-r--r-- 1 root root 28 feb 27 19:35 .migrations

    drwxrwsr-x 4 root root 4096 feb 28 14:03 nginx

    drwxr-sr-x 2 root root 4096 feb 27 19:35 php

    drwxr-sr-x 2 root root 4096 feb 27 19:35 www

    Zitat von cl0v3r_404

    ls -al /var/docker/swag/

    This is not what I asked.


    I told you to use the YML on post #35 as I wrote it and the volume is: /appdata/swag/config:/config

    So I need to see the permissions on:

    ls -al /appdata/swag/config


    cl0v3r_404


    This is how the duckdns should be (just to rule out any issue)



    email must be a valid one (otherwise no access to the duckdns page) and token need to be generated


    -------


    Put the subdomain (for eg mysubdomain) that was used on the YML URL field



    Click add domain


    Domain (example was mysubdomain) will be seen here and the WAN IP



    If the IP doesn't match, copy paste the output of the curl ifconfig.me command and click "update ip"


    With this and the SWAG running with a proper port forward on the router, you should (have to) be able to see the SWAG park page secured by opening a browser with https://www.mysubdomain.duckdns.org


    If it does not, then something is wrong with your setup/router/IPs

    The container log with the new path


    The container code



    The ip of duckdns and the result of the command you mention are identical, if I "update" it in duckdns the message I get is that the ip has not been updated.


    I want to add one thing that I have been testing now, I have changed the container port to 443 and I have enabled port 80, both I have opened in the router, besides adding the service containers to the same swag network. Locally I can access the services I set up (nothing new so far). What is new is that I decided to connect with my laptop and connected to the mobile data network and execute several commands. The first one was to ping one of my services (jellyfin.mysubdomain.duckdns.org) and I got a response. The second command was to do a tracert to the same url and I also get a response. Right now at this point is where I am stuck as I don't have CG-NAT.

    Just in case!

    I am using duckdns and SWAG wildcard got no issue I can access any service by putting name of service in front ex

    https://service-ex.emby.myurl.duckdns.org

    (I am aware need to update to the latest swag proxy-confs Lol)

    in Attachment are my opnsense port forwarding

    Zitat von Nefertiti

    Just in case!

    I am using duckdns and SWAG wildcard got no issue I can access any service by putting name of service in front ex

    https://service-ex.emby.myurl.duckdns.org

    (I am aware need to update to the latest swag proxy-confs Lol)

    in Attachment are my opnsense port forwarding

    I have compared your codes and the ones I currently have, I have changed the ports as you have them and the result is the same.

    cl0v3r_404

    Your folders aren't being made with the proper permissions.

    If this is what was created with the new PATH and is the output of /appdata/swag/config (When posting outputs, always post the prompt also, please)

    They all belong to root when they should be owned by the PUID 1000 && PGID 1000 (the same that you used on the YML)


    In my case, my PUID 1000 is USER pi and PGID 100 is GROUP users

    On my YML is:

    Code
        environment:
      - PUID=1000
      - PGID=100

    And the folders reflect that:


    To fix this, bring down SWAG.

    ONLY DO THIS ON THE NEW FOLDER /appdata/swag/config

    DO NOT DO THIS on the old /var/docker/swag


    Run on CLI

    id 1000 This will show the name for the USER and the GROUPs that it belongs to.


    (change UID:GID with the proper name of the USER and the GROUP that has that number 1000)

    sudo chown -R UID:GID /appdata/swag/config


    Check again the permissions with (and make sure they are correct)

    ls -al /appdata/swag/config


    Bring SWAG up.

    Well, I have completely removed all swag, including the container and directory to start from 0 as if I had done nothing. This is the result of the command ls -al /appdata/swag/config


    Zitat von cl0v3r_404

    This is the result of the command

    And Usuario is your USER with id 1000?

    Zitat von cl0v3r_404

    Right

    And?

    Some info would be nice.

    One word replies don't help nothing.


    Do you see the SWAG park page now?
    Are the SWAG logs looking OK?


    If NOT, then take a step back and explain exactly:

    How are you launching the services? Compose plugin? CLI and docker-compose? Portainer?


    How are you running OMV? On the host or via a VM, etc?


    What other services are you running also on the SERVER?

    Anything that might interfere with SWAG?


    Do you have a Firewall running that might be blocking anything?


    What hardware are you using for network other than the ROUTER, if any?


    What does this show:

    sudo lsof -i -P -n | grep docker


    Remember that other people are not in front of your system.

    Working with assumptions is tiredsome.

    Replies are always dependent of the info given.

    The swag page locally appears as shown in the picture


    (I show that I am connected to my Wi-Fi network to show that it is local.)

    But if I leave my local network it does not appear. I am launching the container with portainer, the OMV system is physically installed on the server.

    Other services I am running are:
    - nextcloud
    - jellyfin
    -wgeasy
    - dashy
    - the duckdns container so that it updates the ip
    - swag - Mealie (digital recipe book)


    Elements that may have apart from the router none, no firewall or anything like that, the most so let's say different a TP Link Wi-Fi repeater and an unmanageable switch also of the same brand. This is what it shows me if I execute the command

    Zitat von cl0v3r_404

    (I show that I am connected to my Wi-Fi network to show that it is local.)

    You need to be out of your network, be it Wi-Fi or wired.
    Try on your phone with mobile DATA. Not on the home network.


    Zitat von cl0v3r_404

    Other services I am running are:

    Stop all of them except SWAG

    Zitat von Soma

    You need to be out of your network, be it Wi-Fi or wired.
    Try on your phone with mobile DATA. Not on the home network.


    Stop all of them except SWAG

    I have closed all containers except duckdns, portainer and swag (obviously), from the mobile with the data I tried to enter the URL and it does absolutely nothing, giving time out, likewise with my laptop connected to the phone with an access point.

    Zitat von cl0v3r_404

    I have closed all containers

    Then, I'm out of ideas.

    Was hoping that maybe nextcloud was blocking the port 443.


    Someone will have to pitch in because I can't think of anything else.


    Sorry and good luck.

    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).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden