Setup on Synology Docker

This is super helpful. I will redo and report. There has to be obvious mistake

Ok tried it again
Router gateway 10.0.0.1
Router dhcp range 10.0.0.2 to 10.0.0.150
Static Ip NAS on bonded network 10.0.0.155 (outside router dchp as recommended )
Pi hole 10.0.0.200 ( outside router dchp as recommended)
Pi hole bridge gateway 10.0.100.1

I still cannot reach 10.0.0.200/admin

When I look at assigned IPs on my router before macvlan there are 2 entries for my NAS 10.0.0.155 I am assuming because of link aggregation ( bond0). After macvlan and pihole I have one NAS at 10.0.0.155 and 2 entries for 10.0.0.200 ( one as NAS other as some unidentifiable Mac) I think I am getting some conflict because of using bond0
Or some port is not working as the IP is getting assigned to 10.0.0.200 but I cannot access the admin page
Also after putting 10.0.100.2 as DNS for NAS .. the NAS is unable to browse docker registries .. which means docker is not able to reach internet within NAS

ok. As suspected it is bond0 interface. When i dont use link aggregation and just use eth0 it works. So the person who got bond0 working could add value to this guide by providing more details.
Beefyfish thanks for all your help and the guide. Appreciate it a lot.

Did bond0 show when you did "ip addr" in ssh? Unless you go into the synology configuration with both Ethernet ports connected to the network and bond it through the synology UI it is not bonded. With it bonded you are unable to even create a macvlan on eth0 as it will come up with some error that the port is already claimed.

I did google the link aggregation in synology and see there is 4 different types. So it could be some trial and error to setup.

Being that you have got an understanding of setting up pihole you can test different ways. I personally dont use link aggregation because on my old nas had one of the NIC ports die and was a real hassle being that I could not connect to my NAS to disable it (luckily I ordered a usb network adapter and the synology installed it by default). If I could afford one with more the 2 ports then link aggregation on 2 and leaving one alone for a backup I would.

yeah the only difference between my tries were Bond0 vs eth0.
Yeah I took the default option to bond lan 1 and Lan2 using synology UI and yes selected that after checking ip addr.
I am curious how @coalfield got it working

bond should be 'IEEE 802.3ad Dynamic Link Aggregation', and I also manually config IPv4 in the same network settings (take a screenshot of that menu).

If you also take a screenshot of your docker Network menu (expanded), I can take a look.

Static Ip NAS on bonded network 10.0.0.155 (outside router dchp as recommended )

For this I have it on a different subnet. It may be worth a try, also use /32 on the bridge and pi-hole to restrict the IP so you know which one is being dished out

@Beefyfish

Thanks for your guide!

To get around the caveat where in pi-hole it sees only the IP address (instead of the FQDN) of Synology after implementing your brdige "trick", you can assign a static DNS A record entry in your upstream DNS for the gateway IP that you used when creating the bridge network. That is of course, if you manage the upstream DNS. In my case, my upstream DNS is pfsense so I can control it. Just my two cents.

EDIT: Also, I just found out a bug in your guide. When one follows your guide, the default route in the pihole container will default to the gateway IP you specify in the "bridge" network instead of the one in the "macvlan" network. This is fine if you have one subnet in your physical network because there will be a route in the container for the macvlan subnet. But in my case, I have mulitple subnets (VLAN's) in my physical network. Any traffic originating from those "other" subnets will not be replied to properly by pihole because it doesn't have routea to them. The default route should always be the gateway of the macvlan network where the container is connected to, not the bridge network gateway IP. I'm not sure how to solve this as I cannot find a way to set the default gateway of a container when it uses two or more networks.

@kevindd992002

Hi,

I have the same problem, have multiple VLANS in the physical network, I thought allowing DNS traffic from the VLANS to the macvlan ip would be enough...

Did do you find any solution to set the default gateway of the container?

I didn't manage to find out how to set the default gateway of a container but I resorted to creating a script to have the same effect in my NAS. My script's content is:

#!/bin/bash

The macvlan network subinterface

/usr/sbin/ip link add mac0 link bond0 type macvlan mode bridge
/usr/sbin/ip addr add <arbitrary IP in my primary subnet/vlan>/24 dev mac0
/usr/sbin/ip link set mac0 up
/usr/sbin/ip route add /32 dev mac0

And then create a boot-triggered scheduled task that runs this:

sleep 60 &&

The sleep is important because it won't work without it. Make sure to chmod the script also to make it executable.

Can you explain what this script does?

The arbitrary ip should this be an adress in the subnet of the macvlan or bridge?

@kevindd992002
@all

I found another solution who is very easy.
Just set Pi-hole to Listen on all interfaces, permit all origins this way Pi-hole answers to the DNS request even if it is not originating from the default gateway. I don't forward port 53 to WAN so I don't think there's any problem in using this option, or am I wrong?

@Kopernikus

Sorry for the late reply. What the script does is basically to create a macvlan interface in the physical host machine with the arbitrary IP being in the subnet of the macvlan network you created for the container. And then creates a route for the host (and for the other containers as well) to use that interface when sending packets to the IP of the pihole docker container.

I'm surprised that the "listen on all interfaces..." option worked for you because that only checks source IP's. Our problem with the default gateway is not related to this because what the container doesn't do (when following the guide) is pass the "reply" packets to the correct default gateway.

@kevindd992002
@Beefyfish

For me it's working if I set Pi-hole to listen on all interfaces, so I wonder if there's a way manually define the subnets Pi-hole listens to (for security reasons). The only thing I can't get to work is to display the block page from Pi-hole although blocking itself is working fine. My Synology where the Pi-hole is installed is on my untaged (management) LAN, the devices who access the PĆÆ-hole are on VLAN10 / VLAN20.

A very good technical explanation of docker macvlans and how to enable the docker host to access containers using the macvlan is at:

https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/

Brad

Thank you very much for this tutorial, it is very detailed and just following your steps everything ends up working great.

However, I got a problem I would like to ask you about.
If I connect to a VPN (PPTP in this case) to redirect all my traffic over there and then start the Pi-hole container, the pi-hole finds problems, even the DNS replies and seems to be working ok, but the web interface is not reachable (error 443) and the log says:

::: Docker start setup complete
[i] Pi-hole blocking is enabled
[āœ—] DNS resolution is currently unavailable
Then it shutdowns after a minute or two.

My 1st thought points to the macvlan gateway setup, as the VPN is on all the traffic is fw over there and not directly to my ISP modem (192.168.0.1). Unfortunately, I don't know apriori the gateway the VPN will set when it connects, as I can connect to many different servers it is quite likely that default route changes every time I connect.

On the other hand, if I start first the pihole container and then establish the VPN connection, everything works flawlessly.

Do you have any suggestions about how can I fix this problem?

Thank You
Jorge

hello,
i installed pihole into mynas and i got something strange
my pihole docker have different time with my nas. how to make it sync?
i cannot add volume the nas system to the docker. so i might cannot make it have a correct time. the pihole is working but with status "BOGUS"

I followed this guide and for some reason my container just continuously reboots. Has any run into that issue? I followed the below guide previously and didn't have any issues with the container but for some reason it wouldn't actually take traffic.

I have written a modified version of Beefyfish's wonderful guide that accounts for running a DNS server, Domain services and a bonded network setup on the synology if any one would find that useful? There are a few differences and I found a reliable way to maintain domain services and get all traffic through the pihole with the original client addresses.

https://drive.google.com/file/d/1DjCna_5CB4XzSOjU86ESLHa9Uv8dBEn-/view?usp=sharing

1 Like

Just ran in to the exact same issue. Here's the fix.
You will need to create a resolv.conf file and put it in the pihole folder created earlier. The contents should be:

nameserver 127.0.0.1

Edited to remove bad advice about additional incorrect entries

You then need to mount the file to the mount path /etc/resolv.conf .
edited to remove bad advice about making the file read only

This fixes a DNS error with the pihole docker image that stops it starting up and causes it to reboot once every 2 minutes.

Unless there is a good reason to interfere and making it immutable for your network, I would leave resolv.conf under system control.

resolv.conf is a fundamental file for quite a few network services (resolvconf, dhclient, dhcpcd5, to name a few), and as as such is managed and written to by their daemons regularly. While it is commonly located at /etc/resolv.conf, quite often that is just a symlink to another location like /run/systemd/resolve/stub-resolv.conf or /etc/resolvconf/run/resolv.conf.

I would advise against providing that file directly at /etc/resolv.conf and making this file read-only, as a daemon ostracised from writing to that file might fail and choose to create bunches of temp files instead or even use its original location (as symlinked before).
This may result in unexpected network behaviour that will give you a hard time analyzing why your system does not honor the config you supplied or is not able to properly integrate with your network.

One such example would be that Pi-hole could be unaware of your local search domain (supplied via a search option in resolv.conf) and thus not be able to resolve local FQDNs correctly.

There are circumstances where a temporary provision of a public nameserver via resolv.conf is advised, e.g.when retrying to continue an installation/update of Pi-hole that failed previously (so Pi-hole would not be able to provide DNS resolution yet).

But permanently providing two additional nameservers via resolv.conf may result in clients bypassing Pi-hole (127.0.0.1), using Google's public servers (8.8.8.8 and 8.8.4.4) instead.

Pi-hole relies on configuration as the only DNS resolver to provide its services correctly.