Swag is not working anymore

Looks like that is the case.

You need to see all of the ports being used by docker from compose / containers. You should see a list of all running containers with the ports in use. see if you can see any that are using 445

Quote from harold.mouras

Thank you for your mail. If I understand well, I changed my YML as follows:

Code

 ports:
      - 445:443
    restart: unless-stopped

When I try to redeploy the stack , I get :

failed to deploy a stack: Container swag Creating Container swag Created Container swag Starting Error response from daemon: driver failed programming external connectivity on endpoint swag (7427634feb47015984e16e0bbebf5ed9d3e5b508d23a1eb6292d4ccae0cf9080): failed to bind port 0.0.0.0:445/tcp: Error starting userland proxy: listen tcp4 0.0.0.0:445: bind: address already in use

Meaning that port 445 is also in use ?

Display More

That is what the error indicates. It has to be a port that is not in use by something else

You have been having a lot of fun getting this working.

I think this issue you have now is that when you are on your lan (e.g. at home with client connected to your wifi or wired) then https://mydomain.duckdns.org will not resolve. You need https://mydomain.duckdns.org:447

When not on your home network (e.g. on mobile network) then https://mydomain.duckdns.org will work but https://mydomain.duckdns.org:447 will not work.

Can you test this - then I know the issue and can help you fix it

FYI port forward rules on the router only apply to connections to your wan (not lan)

Out of interest, what service (omv, containers, other) is using the standard https port 443?

My first choice strategy to fix this issue would be to free up port 443 and then run swag 443:443 - but this is not always possible/easy.

The reason is that then you can use swag easily for everything - including whatever is currently using port 443.

Quote from harold.mouras

Hello,

I was able to deploy swag on port 447 with such a stack. :

Code

services:
  swag:
    image: lscr.io/linuxserver/swag
    container_name: swag
    hostname: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=100
      - TZ=Europe/Paris
      - EMAIL=mymail
      - URL=mydomain.duckdns.org
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
      - DUCKDNSTOKEN=mytoken
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /srv/dev-disk-by-uuid-a4573920-1223-409f-95b0-eb4903d28617/appdata/swag:/config
    ports:
      - 447:443
    restart: unless-stopped

Display More

I forwarded the port as follows on my router like shown on the attached pic. OMV is working on the port 88.

With such settings, going to https://mydomain.duckdns.org goes nowhere, http://... also....

What did I wrong....

Glad you got it working and got a partial answer to the question of why it wasn't resolving your domain locally.

When you type a domain into your browser, the browser looks to an internet DNS server to find the ip address of your configured domain. That ip address points right back at you but normally internet service providers hardware don't allow for this type of traffic reflection (also known as hairpinning).

You can continue to handle it like you are, or you can do what I, and many more, have done. I have an instance of pihole running on my system that acts as a local DNS server to handle any requests on your LAN, and if it doesn't have a lookup in it's table, it forwards the request on to the internet. You then configure your router to pass out the address of pihole as the primary dns server, or you manually configure your systems with the ip of pihole for dns.

There are guides in the guide section of the forum on how to set up pihole in docker and one I made on how to set it up in an lxc. You could also opt to set it up on another system or a raspberry pi (it's called pihole because it was originally designed for a raspberry pi) The configuration is all explained in the guides and the documentation on the pihole website.

There are other options as well. Some routers can handle local dns configurations with dnsmasq (dnsmasq is also what pihole uses), or and adguard docker container or you could also use a simple dnsmasq docker container if you don't want the ad blocking features of pihole or adguard.

Using local dns allows you to use the same address regardless of if you are at home or not.

Quote from harold.mouras

- URL=mydomain.duckdns.org - SUBDOMAINS=wildcard - VALIDATION=duckdns

When using wildcard on SWAG, the certificate is asign to the SUB.SUBDOMAIN

The access to the server will only shows some thing on

https://SUB.subdomain.duckdns.org

The domain won't have a certificate.

For eg

https://www.subdomain.duckdns.org will show the SWAG park page but without the www, nothing shows

You are correct. None of your containers are using port 443. It might not be a docker container using the port...

What port is omv gui using? http or https? what ports?

have you tried starting swag on 443?

I have swag running on two servers on my network. One using default port 443 and the other 444 so it does work fine.

You just do https://emby.mydomain.duckdns.org:447

And configure the reverse proxy in swag normally. Remember you have only changed to port you use on the host side. The container does not change and does not care. It just forwards the request internally and returns the results back.

If I were you I would get the reverse proxy working when on the network. Get one or two of the services you want to reverse proxy to working.

From outside you need to use https://emby.mydomain.duckdns.org (and this is an issue as you really want 1 url that works for both cases). Correct?

We can fix this issue. There are a few ways to do it. But my advice is get the basics working then we can help you with the next part...

hahaha. I am happy I said to check port 443! It simplifies everything a fair bit (as you have just found out).

One thing to think about but not for now!

While your setup is working, it is probably a bit inefficient. I'm guessing (as I don't know your network setup) but probably every time you connect to a reverse proxied service (while at home), your network has to do an external dns lookup to to find out the service is actually on your network and so this is a waste of time/resource. Others have pointed out you might want to investigate split or hairpin DNS.

Or use an intermediary system like pihole or adguard. I use adguard and it has a really clever and simple way to 'rewrite' (or redirect) to the correct internal address without needing to do an external dns lookup.

Right now, just enjoy your working setup!