In order to show real IP, add `trustedproxy` to `config.json`

[JJPro]

Thanks for the image.

I was struggling to display real client IPs, and figured that you need to add the reverse proxy server (I'm using nginx proxy manager) as trustedproxy in config.json file. Otherwise, all clients will appear as IP of the proxy server instead of their own.

...
"settings": {
    ...
    "TLSOffload": false,
    "trustedproxy": "10.10.0.3",
  },
  "domains": {
    "": {
      ...
      "certUrl": "https://10.10.0.3:443"
      }
  },
...

Since you already have the proxy IP from REVERSE_PROXY env var from docker-compose file, this should be convenient to implement.

[Typhonragewind]

Oh, this is a nice one, I never check the clients IP so I never noticed. I'll change it when I have the time, thanks for the tip!

[GitTworn]

I'm also using Nginx Proxy Manager but I have it setup with 2 networks within docker. One connects it to the internet, the other network connects the reverse proxy to all the internal containers so that they cam be resolved using the host names.

Which internal IP do I use? The docker network that connects the rev. proxy to the internet, the docker network connecting the rev. proxy to the meshcentral container, the local network ip on the server machine?

The certUrl points to the domain name of my meshcentral instance.

[Typhonragewind]

@GitTworn Your network topology is a bit more different than what I'm used to, but my best guess is the internal IP you need is the IP of the reverse proxy as the internal Meshcentral container would see it

[JJPro]

It's IP of your NPM docker. usually starting with 172. I had '10.10.0.3' in my snippet above because mine was using docker macvlan network.

[JJPro]

BTW, why do you connect two networks to it? can you not access internet via NPM network only?

[GitTworn]

As per the Nginx Proxy Manager docs (https://nginxproxymanager.com/advanced-config/)

For those who have a few of their upstream services running in Docker on the same Docker host as NPM, here's a trick to secure things a bit better. By creating a custom Docker network, you don't need to publish ports for your upstream services to all of the Docker host's interfaces.

[JJPro]

I see. For sure you do not need two networks.

Docker network docs:

Differences between user-defined bridges and the default bridge: User-defined bridges provide automatic DNS resolution between containers.

The NPM docs you posted recommends to use a user-defined bridge, rather than the default bridge, then you get the benefits of automatic name resolution between containers on the bridge.

If NPM is created via docker-compose, the custom network is created for you. It's $NPM_default unless you don't name it otherwise. ($NPM refers to the folder name of your docker-compose.yml file).

Connect all other containers to $NPM_default. that's it. You don't need a second network.