Container shows only the Docker network's IP as the Client in logs

[YouveGotMeowxy]

Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• [X] I am running the latest version
• [X] I checked the documentation and found no answer
• [X] I checked to make sure that this issue has not already been filed

Issue Details

• Version of AdGuard Home server:
  • Version: v0.107.5
• How did you install AdGuard Home:
  • Docker container: adguard/adguardhome:latest

My Compose:

version: "3.8"

services:

    adguard:
        hostname: adguard
        image: adguard/adguardhome:latest
        environment:
          TZ: 'America/Chicago'
          PUID: 1000
          PGID: 1000
        volumes:
          - '/opt/docker/configs/adguard/config:/opt/adguardhome/conf:rw'
          - '/mnt/e/Docker/adguard/data:/opt/adguardhome/work:rw'
        ports:
          - '3000:3000/tcp'
          - '53:53/tcp'
          - '53:53/udp'
          - '853:853/tcp'
          - '853:853/udp'
          - '784:784/udp'
          - '8853:8853/udp'
          - '5443:5443/tcp'
          - '5443:5443/udp'
        networks:
          - ocdns
        deploy:
          mode: replicated
          replicas: 1
          placement:
            constraints:
              - node.labels.Main == true
          restart_policy:
            condition: any

networks:
  ocdns:
    external: true
    name: dns

• How did you setup DNS configuration:
  • Just setup through adg's settings, then put the host ip and port in the device I want to use adg. i.e. on another windows pc I set it's nic to use that dns.

• Operating system and version:
  • Win 10 x64 running WSL2 + Ubuntu

Expected Behavior

See real/actual IP of the client in the logs

Actual Behavior

It's only showing the IP of Docker's network (10.0.0.2) for every single item.

Screenshots

Screenshot:

Sample of client queries from Adguard (ALL client IP's are always the same):

Additional Information

I'm also using Linuxserver.io's SWAG Nginx container, and serving the web ui up via a reverse proxy (https://adguard.mydomain.com), but that's only for the web ui; the regular adguard ports are still open to the host and all devices connect to the host's ip + port 53.

[nikkadim]

Can confirm same issue.

[agneevX]

If you're using Docker Networking, this is expected behavior.

You should use host networking if you want to see requests by client. This should be documented in the wiki.

[YouveGotMeowxy]

So don't use a container if we want to see actual IP's?

[decisoft]

Same here, same config. But as far as I remember, this doesn't happen before. Even with rDNS and upstreams servers with my router address, only appears as a client de gateway of the docker network. Any solution on this?

[agneevX]

So don't use a container if we want to see actual IP's?

You can containerize, but you need to use host networking as I said.

[YouveGotMeowxy]

So don't use a container if we want to see actual IP's?

You can containerize, but you need to use host networking as I said.

How do you do that when using docker swarm?

[agneevX]

https://forums.docker.com/t/use-host-network-for-swarm-container/74878/4

[EugeneOne1]

@YouveGotMeowxy, if the @agneevX's suggestion worked?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[a1ex4]

@EugeneOne1 I can confirm that running AdGuard Home docker container with network_mode host fixes this issue.

I myself was seeing only one client (the gateway of the docker network all my other containers are connected to), and now all containers show up.

I am running a reverse proxy (nginx-proxy/nginx-proxy) that uses ports 80 and 443, so to enable AGH encryption I configured the AGH HTTPS port to be 444 and ran a socat container so that the Web UI / HTTPS traffic can be exposed in the vlan where the reverse proxy can see it. Putting my working compose here for others having similar issues:

---
version: "3.2"

services: 
  adguard:
    container_name: adguard
    image: adguard/adguardhome
    user: "1000:1000"
    network_mode: host
    volumes: 
      - ./data:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf
      - ../nginx-proxy/certs/dns.domain.tld:/certs:ro
    restart: unless-stopped

  adguard-socat:
    image: alpine/socat:latest
    container_name: adguard-socat
    cap_add: [ 'NET_ADMIN', 'NET_RAW' ]
    entrypoint: "socat tcp-listen:445,fork,reuseaddr tcp-connect:<HOST_IP>:444"
    environment:
      - LETSENCRYPT_HOST=dns.domain.tld
      - VIRTUAL_PORT=445
      - VIRTUAL_HOST=dns.domain.tld
      - VIRTUAL_PROTO=https
    ports:
      - 445:445
    restart: always

networks:
  default:
    external:
      name: webproxy

[nextlogic-ono]

How do I fix this if I don't want to use the host mode in docker?

Can AdGuard Home not take IP from HTTP header from trusted reverse proxy by specifying trusted reverse proxy IP? That's how it's usually handled.

[STaRDoGG]

Can AdGuard Home not take IP from HTTP header from trusted reverse proxy by specifying trusted reverse proxy IP? That's how it's usually handled.

Are you referring to this header?: proxy_set_header X-VerifiedViaNginx yes;

I recently came across this header for the first time and am not fully sure what it does/how it works, and can't really find any info on it?

[nextlogic-ono]

No, I meant the generally used X-Forwarded-For header.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

I have a reverse proxy in front of AdGuard Home, which can send the client's real IP through that header and if I specify the reverse proxy's IP (such as 172.17.0.1 using docker) as a trusted source IP in AdGuard Home, then AdGuard Home may use that header's value as the client's IP instead of listing every access is from 172.17.0.1.

[STaRDoGG]

No, I meant the generally used X-Forwarded-For header.

I'm not an expert in this area, but if I had to guess I'd say those are only for http headers, and when doing a DNS lookup http headers aren't sent to AGH (or any DNS resolver), so the forwarded for header wouldn't matter. It only matters to the AGH Web UI. (again, just guessing).

[nextlogic-ono]

Yes, this is only for DoH.

Regarding plain DNS on port 53 and DoT, you cannot reverse proxy those like web servers do, so it's ok to take the client's IP as is, as client's IP is exposed to AdGuard Home even through NAT, but for DoH through a reverse proxy, the client that's directly accessing AdGuard Home would be the reverse proxy web server making it looking like all requests are coming from the reverse proxy but by utilizing that header, AdGuard Home can obtain the actual client's IP.

Client (1.2.3.4) -> Reverse proxy (172.17.0.1) -> AdGuard Home

• Currently AdGuard Home logs 172.17.0.1 as client IP no matter what the actual client IP is.
• Reverse proxy can send X-Forwarded-For: 1.2.3.4header to AdGuard Home.
• AdGuard Home should have a setting for what IP to trust (as anyone else can also set that header to pretend to be another IP) that can send X-Forwarded-For (in this case, set the trusted source as 172.17.0.1) and use the header value as client's IP instead.

Without this, you cannot also restrict access by IP as AdGuard Home thinks it's only interacting with 172.17.0.1.

[EugeneOne1]

@windware-ono, hello. AdGuard Home actually has this setting in the configuration file, it's called trusted_proxies. AGH treats those subnets as trusted and check the HTTP headers for real client's IP. The wiki has a description of those headers. As @STaRDoGG correctly noted, this is the DNS-over-HTTP only solution.

By the way, we've got a feature request for extracting the real client's IP from the DNS message itself (#1727).

[nextlogic-ono]

@EugeneOne1 Sorry for the mess. I'll make sure to read the doc first.

[EugeneOne1]

@windware-ono, we'd appreciate your feedback on using trusted_proxies. If that works as expected?

[nextlogic-ono]

@windware-ono, we'd appreciate your feedback on using trusted_proxies. If that works as expected?

Yes it did! Thanks.

[FlyingPersian]

I haven't really figured this out! I'm seeing three solutions, none of which aren't working on my docker swarm setup:

version: "3"
services:
  adguardhome:
    image: adguard/adguardhome
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 67:67/udp
      - 68:68/tcp
      - 68:68/udp
      - 853:853/tcp
      - 82:80/tcp #change this to something like 81:80 if port 80 is already in use
      - 3000:3000/tcp
    volumes:
      - adguard-data:/opt/adguardhome/work
      - adguard-config:/opt/adguardhome/conf
    restart: unless-stopped
    network_mode: host

volumes:
  adguard-data:
    external: true
  adguard-config:
    external: true

version: "3"
services:
  adguardhome:
    image: adguard/adguardhome
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 67:67/udp
      - 68:68/tcp
      - 68:68/udp
      - 853:853/tcp
      - 82:80/tcp #change this to something like 81:80 if port 80 is already in use
      - 3000:3000/tcp
    volumes:
      - adguard-data:/opt/adguardhome/work
      - adguard-config:/opt/adguardhome/conf
    restart: unless-stopped
    networks:
      - outside

volumes:
  adguard-data:
    external: true
  adguard-config:
    external: true

networks:
  outside:
    external:
      name: "host"

version: "3"
services:
  adguardhome:
    image: adguard/adguardhome
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 67:67/udp
      - 68:68/tcp
      - 68:68/udp
      - 853:853/tcp
      - 82:80/tcp #change this to something like 81:80 if port 80 is already in use
      - 3000:3000/tcp
    volumes:
      - adguard-data:/opt/adguardhome/work
      - adguard-config:/opt/adguardhome/conf
    restart: unless-stopped

volumes:
  adguard-data:
    external: true
  adguard-config:
    external: true

networks:
  outside:
    external:
      name: "host"

Plus the socat stuff, which I don't even know what it is.

1. Starts up fine. I can set it up, but it only shows 10.0.0.2 as a client.
2. The docker container fails to start without any error and I don't even know what exactly to change in Portainer or such, like whether I should actually add the network "outside" and if yes how to configure it.
3. Same as 2.

Can anybody give an idiot-proof step-by-step on what to do here, please?

[ainar-g]

@FlyingPersian, it's better to start new Discussions as opposed to writing to closed issues. Also, not a lot of people have enough experience with Portainer/Docker Swarm, so it's generally better to check if AdGuard Home works outside of a container before filing an issue. Because if it does, the problem is most probably with the system configuration, and is thus better discussed on the Discussions page.

[YouveGotMeowxy]

Can anybody give an idiot-proof step-by-step on what to do here, please?

I suspect you won't really get any "good" answer to that exact request. I've tried several times in the past and still have never gotten one that works.

[YouveGotMeowxy]

@FlyingPersian, it's better to start new Discussions as opposed to writing to closed issues. Also, not a lot of people have enough experience with Portainer/Docker Swarm, so it's generally better to check if AdGuard Home works outside of a container before filing an issue. Because if it does, the problem is most probably with the system configuration, and is thus better discussed on the Discussions page.

It'd probably be great if the owner of this repo converted this thread into a discussion rather than create another, brand new one revolving around the same exact question.

[flavorgold1]

Can't you just run in network_mode: host and eliminate all those ports?

That's the simplest solution if you're fine with no network isolation for your AdGuardHome instance.

[FlyingPersian]

Can't you just run in network_mode: host and eliminate all those ports?

That's the simplest solution if you're fine with no network isolation for your AdGuardHome instance.

I have that already, doesn't solve the problem

[outofsight]

I have many AdGuardHome installations, all with non-default bridge networking. One of these correctly log the real IP address of my host in my lan (10.20....) . The other instead log the docker gateway ip address (172.20...) for any client. Why?

[Blue765]

For me, the correct IP is displayed first and the URL e.g. blocked and then the docker IP afterwards without the URL being blocked It would be nice if you could get rid of the docker IP.

[wangerzi]

Maybe we can use macvlan in docker, it will create a virtual network device for docker, also we will get a new IP by this virtual network interface.

Reference(missing test, enp2s0 is my network interface id):

version: "2.1"
services:
  adguardhome:
    container_name: adguardhome
    restart: unless-stopped
    volumes:
      - ./adguardhome/workdir:/opt/adguardhome/work
      - ./adguardhome/confdir:/opt/adguardhome/conf
    ports:
      - 53:53/tcp
      - 53:53/udp
        #- 67:67/udp
        #- 68:68/udp
      - 18099:80/tcp
        #- 443:443/tcp
        #- 443:443/udp
      - 18090:3000/tcp
        #- 853:853/tcp
        #- 784:784/udp
        #- 853:853/udp
        #- 8853:8853/udp
        #- 5443:5443/tcp
        #- 5443:5443/udp
    networks:
      openwrt_lan:
    image: adguard/adguardhome:v0.107.36
    
networks:
  openwrt_lan:
    driver: macvlan
    driver_opts:
      parent: enp2s0
    ipam:
      config: default

[mTrax-]

I have a similar issue with a rootless podman installation. I have another installation with Docker Swarm and overlay network, it works without any problem. From what I understand, my problem is the bridge driver with splirp4netns. It doesn't support original IP address.

Using network_mode=host will be insecure, I believe that switching to pasta (passt) will fix the problem. I've not tested yet because my host is a LTS 22.04 ubuntu and passt is only available (from package) with 23.04/23.10