Using "useBindPortIP" + "swarmMode", what am I doing wrong?

Could someone please explain how on earth do I get useBindPortIP = true working with swarmMode = true & swam modes required traefik.http.services.selfservice.loadbalancer.server.port?

Preferably with an actual working docker compose example so that I can compare what I've tried vs how it's actually supposed to look cause I genuinely cannot figure it out

A number of my backend services use a custom signed certificate which works fine, I can easily get it working using the file config along the lines of:

http:
  routers:
    selfservice:
      entryPoints:
      - https
      service: selfservice
      rule: "Host(`myaccount.publicnet`)"
      tls:
        certResolver: cloudflare

  services:
    selfservice:
      loadBalancer:
        servers:
        - url: https://192.168.0.10:6089
        - url: https://192.168.0.15:6089

When deploying it this way everything works as expected, traefik has the CA configured so internal certificates are all trusted, public facing myaccount.publicnet just works taking advantage of the letsencrypt certificates, absolutely no hassle setting it up this way

But trying to get it working within a swarm compose stack has been exceedingly infuriating

It breaks because the custom certificate the service uses expects either 192.168.0.10/15/20/25/30 (accounting for all the swarm nodes this service can run on) or myaccount.localnet (which resolves to the same IP's) for the backend https connection, instead it is seeing the internal container ip (172.128.38.47) which means the cert isn't trusted resulting in myaccount.publicnet giving me a big fat middle finger in the form of an internal server error page

No matter what I try, the backend service connection ALWAYS sets itself to the internal container IP and I always get:

msg="Unable to find a binding for container \"auth_selfservice.1\", falling back on its internal IP/Port." providerName=docker container=auth-selfservice-h61jknxn07501ynqa1kpklzhj serviceName=selfservice

I've tried using multiple variations of examples shown in the documentation (which could really use some extra clarification. Maybe a real world example as I don't think I understand how it's supposed to be used?) in various places of the compose and I've spent the last few hours trying to search various sources how the hell to get it working without much luck pinpointing what I'm missing

I suppose I could opt for using insecureskipverify=true but I shouldn't have to fall back on using that, I'd rather get it working correctly

I've attempted too many variations to include all of them but I'll list some of the more obvious ones I've tried:

---
version: "3.7"
x-logging: 
      &default-logging
      driver: "gelf"
      options:
        gelf-address: "tcp://192.168.0.99:12201"
        tag: "Auth"

networks:
  traefik_proxy:
    external: true
services:
  selfservice:
    container_name: selfservice
    hostname: selfservice
    image: selfservice-webapp:local
    networks:
        - traefik_proxy
    ports:
      - 6089:8443 # Tried multiple variations of this such as long syntax and x.x.x.x:6089:8443 methods
    volumes:
      - /mnt/GFSVol01/AppData/selfservice:/config
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints:
         - node.platform.arch == x86_64
      labels:
        - traefik.enable=true
        - traefik.docker.network=traefik_proxy
	#- traefik.port=6089 # Tried multiple variations of this, didn't take note of the source but some site said to try using it, maybe I misinterpreted the use case
        - traefik.http.routers.selfservice.rule=Host(`myaccount.publicnet`)
        - traefik.http.routers.selfservice.tls=true
        - traefik.http.routers.selfservice.tls.certresolver=cloudflare
        - traefik.http.routers.selfservice.entrypoints=https
        - traefik.http.routers.selfservice.service=selfservice
        - traefik.http.services.selfservice.loadbalancer.passhostheader=true
        - traefik.http.services.selfservice.loadbalancer.server.scheme=https
        - traefik.http.services.selfservice.loadbalancer.server.port=8443 # Tried with and without this, tried using 6089 instead
    logging: *default-logging

The assignment of an IP range for a docker network is usually automatic.

I'd suggest that if you need to use tls between docker and the service then set the ip range of the network [using ipam in the compose])Compose file version 3 reference | Docker Documentation).

If your concern is securing the network you can encrypt the overlay network and then allow traefik to connect without tls over this encrypted network.

I appreciate your response but it unfortunately doesn't really help me understand why it isn't working/not recognizing my container bindings
Isn't useBindPortIP supposed to allow me to tell traefik to use my configured binds rather than the internal docker network?
The internal IP of the container itself shouldn't matter with what I'm trying to accomplish, I can talk to the service via the exposed ports anyswarmhostip:exposedport (which i used a couple as examples in the dynamic config)

Everything is already dockerized, nginx proxy manager can do this perfectly for me already, I just imported my CA into NPM's trust and created a proxy pointing at https://myaccount.localnet and it worked
Just as easily as using the traefik dynamic config file method so I'm not really sure I understand why we are talking about the ip range of the docker network itself?
From my reading it comes across as possible with the use of useBindPortIP, but my mind doesn't seem to want to make sense of the current documentation around it


Your suggestion of encrypting the overlay network isn't a bad one, I'll definitely take it into consideration but it does involve reconfiguring quite a number services to allow unencrypted connections to begin with

I could use the dynamic config file as I know that already works due to being able to just use urls in the load balancer but I'd like to minimise the need to file based configs as much as possible

And there is the option of using insecureskipverify but again, I shouldn't HAVE to use it

At the end of the day, being able to just set the loadbalancer urls via docker labels would have made this much simpler...

But none of these help me actually understand why the configuration I'm trying to use doesn't work. If my understanding of it is wrong then I'd like to learn why it's wrong and what it's actually for / the correct syntax of it