Pihole query log geeft op synology bridge ip

[Dr.Roelski]

Weet niet of fit het juiste topic is. Correct me if I'm wrong.

Ik heb pi-hole in docker draaien op 2 devices met nebula-sync gesynchroniseerd:
Orange pi 5 en op synology.
Beide via portainer als stack deployed, met bridge network.
Beide configuraties nagenoeg gelijk.
Op de opi5 krijg ik netjes de client ip adressen te zien in client log.
Op de synology krijg ik altijd het bridge network IPAM gateway adres te zien die de pihole toegewezen heeft als bridge network.
Omdat beide bridge network gebruiken en beide in docker draaien snap ik niet waarom hier verschil in zit. Waarom is er verschil, en hoe kan ik in synology ook de client ip adressen zien (zonder host network of macvlan te gebruiken)?

Kom probleem tegen in google,, maar nergens een antwoord en ook niet dat het op ene device wel werkt en op andere niet.
Best passende link is https://discourse.pi-hole...-from-other-subnets/36680

Mijn yaml's:
Opi5:

code:

services:
  pihole-unbound:
    container_name: pihole-unbound
    image: mpgirro/pihole-unbound:latest
    hostname: pihole24
    domainname: home.local
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 8002:8002/tcp
    environment:
      - PUID=1001
      - PGID=988
      - FTLCONF_LOCAL_IPV4=192.168.2.24
      - TZ=Europe/Amsterdam
      - FTLCONF_webserver_api_password=mypassword
      - FTLCONF_webserver_interface_theme=default-light
      - REV_SERVER=true
      - REV_SERVER_DOMAIN=home.local
      - REV_SERVER_TARGET=192.168.2.1
      - REV_SERVER_CIDR=192.168.2.0/24
      - FTLCONF_dns_revServers=true,192.168.2.0/24,192.168.2.1,home.local
      - FTLCONF_dns_upstreams=127.0.0.1#5335
      - FTLCONF_dns_dnssec="true"
      - FTLCONF_dns_listeningMode=single
      - FTLCONF_webserver_port=8002s
      - WEBTHEME=default-light
    volumes:
      - /nvme/pihole/unbound:/etc/pihole:rw
      - /nvme/pihole/dnsmasq:/etc/dnsmasq.d:rw
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    mem_limit: 1g

Synology:

code:

services:
  pihole-unbound:
    container_name: pihole-unbound
    image: mpgirro/pihole-unbound:2025.04.0
    hostname: pihole4
    domainname: home.local
    ports:
#      - 8006:443/tcp
      - 53:53/tcp
      - 53:53/udp
      - 8002:8002/tcp #Allows use of different port to access pihole web interface when other docker containers use port 80
      # - 5335:5335/tcp # Uncomment to enable unbound access on local server
      # - 22/tcp # Uncomment to enable SSH
    environment:
      - PUID=1028 # Dockerlimited
      - PGID=100
      - PIHOLE_UID=1028
      - PIHOLE_GID=100
      - FTLCONF_LOCAL_IPV4=192.168.2.4
      - TZ=Europe/Amsterdam
      - FTLCONF_webserver_api_password=mypassword
      - FTLCONF_webserver_interface_theme=default-light
      - REV_SERVER=true
      - REV_SERVER_DOMAIN=home.local
      - REV_SERVER_TARGET=192.168.2.1
      - REV_SERVER_CIDR=192.168.2.0/24
      - FTLCONF_dns_revServers=true,192.168.2.0/24,192.168.2.1,home.local
      - FTLCONF_dns_upstreams=127.0.0.1#5335
      - FTLCONF_dns_dnssec="true"
      - FTLCONF_dns_listeningMode=single
      - FTLCONF_webserver_port=8002s
      - WEBTHEME=default-light
    volumes:
      - /volume2/docker/pihole/unbound:/etc/pihole:rw
      - /volume2/docker/pihole/dnsmasq:/etc/dnsmasq.d:rw
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    mem_limit: 1g

Wie o wie snapt het verschil en kan eventueel mijn synology net als de orange pi 5 de juiste client ip adressen laten zien met bridge netwerk?

[Hero of Time]

Ga eens kijken naar de regels die Portainer maakt in iptables. Lijkt er namelijk eerder op dat er op je Syno 'masquerade' wordt toegepast. Als je werkelijk bridge network gebruikt, heb je ook helemaal geen port forwards nodig.

Kijkende naar de documentatie van Portainer (https://docs.portainer.io/user/docker/networks), hebben ze een ongelukkige naam gekozen ervoor. Het is niet 'bridge' hoe het zou moeten heten, maar 'NAT'. Met 'bridge' verwachten velen hetzelfde gedrag als bij een VM in bridge mode, wat bij macvlan staat omschreven.

Bij je clients moet je zeker ook het IP adres van je Pi of Syno opgeven als DNS server?

[Dr.Roelski]

Hero of Time schreef op maandag 21 april 2025 @ 15:00:
Ga eens kijken naar de regels die Portainer maakt in iptables. Lijkt er namelijk eerder op dat er op je Syno 'masquerade' wordt toegepast. Als je werkelijk bridge network gebruikt, heb je ook helemaal geen port forwards nodig.

Kijkende naar de documentatie van Portainer (https://docs.portainer.io/user/docker/networks), hebben ze een ongelukkige naam gekozen ervoor. Het is niet 'bridge' hoe het zou moeten heten, maar 'NAT'. Met 'bridge' verwachten velen hetzelfde gedrag als bij een VM in bridge mode, wat bij macvlan staat omschreven.

Bij je clients moet je zeker ook het IP adres van je Pi of Syno opgeven als DNS server?

Klopt, ik snap het verschil. Bridge in vmware is host bij docker.
Het NAT netwerk is ook wat ik liefste heb, Dan kun je exact opgeven welke poorten doorgegeven worden aan de containers en heb je grip op poort conflicten.
Macvlan heb ik ook werkend op synology, maar dat geeft het ongewenste gedrag (waar wel weer omheen te werken is) dat synology zelf (of de overige containers) dat ip adres niet kan gebruiken. Teveel gedoe om dat te omzeilen.
Als ik beide netwerken bekijk vanuit portainer zie ik geen verschil. Enige verschil is het uiteindelijke subnet (172.22.0.0/16 vs 172.31.0.0/16).

// edit: docker network inspect en version
docker network inspect geeft geen verschil. Op opi5 staat wel EnableIPv4=true gespecificeerd en op syno niet, maar er wordt ipv4 gebruikt.
Grootste verschil is de docker versie.
Opi5: Docker version 28.1.1, build 4eba377
Syno: Docker version 24.0.2, build 610b8d0
Kan me niet voorstellen dat dit verschil in gedrag iets is wat in een nieuwere docker versie gewijzigd is.

[ Voor 13% gewijzigd door Dr.Roelski op 21-04-2025 15:29 ]

[Hero of Time]

Zoals ik al direct zei, check de iptables config. En dat verschil in versie van Docker is nou net hetgeen wat heel ander gedrag met iptables kan geven. Ga de changelogs lezen hierover, kijk of en wat er genoemd wordt over netwerken. Gegarandeerd dat er wel iets in staat.

[Dr.Roelski]

Hero of Time schreef op maandag 21 april 2025 @ 17:01:
Zoals ik al direct zei, check de iptables config. En dat verschil in versie van Docker is nou net hetgeen wat heel ander gedrag met iptables kan geven. Ga de changelogs lezen hierover, kijk of en wat er genoemd wordt over netwerken. Gegarandeerd dat er wel iets in staat.

Thanx, ga ik me in verdiepen!

Heb de tables opgevraagd en hier de relevante regels:

code:

# Syno
-A DEFAULT_POSTROUTING -s 192.168.96.0/20 ! -o docker-d894295a -j MASQUERADE
-A DEFAULT_POSTROUTING -s 192.168.96.2/32 -d 192.168.96.2/32 -p tcp -m tcp --dport 8002 -j MASQUERADE
-A DEFAULT_POSTROUTING -s 192.168.96.2/32 -d 192.168.96.2/32 -p tcp -m tcp --dport 53 -j MASQUERADE
-A DEFAULT_POSTROUTING -s 192.168.96.2/32 -d 192.168.96.2/32 -p udp -m udp --dport 53 -j MASQUERADE
-A DOCKER -i docker-d894295a -j RETURN
-A DOCKER ! -i docker-d894295a -p tcp -m tcp --dport 8002 -j DNAT --to-destination 192.168.96.2:8002
-A DOCKER ! -i docker-d894295a -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.96.2:53
-A DOCKER ! -i docker-d894295a -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.96.2:53

code:

# Opi5
-A POSTROUTING -s 172.22.0.0/16 ! -o br-c5b9d883b7d9 -j MASQUERADE
-A DOCKER -i br-c5b9d883b7d9 -j RETURN
-A DOCKER ! -i br-c5b9d883b7d9 -p tcp -m tcp --dport 53 -j DNAT --to-destination 172.22.0.3:53
-A DOCKER ! -i br-c5b9d883b7d9 -p udp -m udp --dport 53 -j DNAT --to-destination 172.22.0.3:53
-A DOCKER ! -i br-c5b9d883b7d9 -p tcp -m tcp --dport 8002 -j DNAT --to-destination 172.22.0.3:8002

Synology heeft 3 extra regels. Nu verder inlezen wat het betekend....