Hello everyone,
Sorry for my late reply. Too much work, too less time. Thanks again for your advice. It looks like mapping the MacVLAN to the LAN bridge br0 wasn't the right solution after all. However, the problem originated from a different source. The host PC can't establish a direct connection to the MacVLAN, which means it can't access DNS (which runs in the MacVLAN). My idea was to assign the host PC an IP address in the MacVLAN. This gives it direct access to the DNS, which worked well. Unfortunately, it seems as if OMV7 repeatedly pushed itself to the forefront via this IP address and blocked the necessary ports of AdGuard (or Pi-hole). I always assumed it was an instability in the Docker container, because it worked again after a restart.
My old configuration of /etc/network/interfaces.d/macvlan_host:
auto macvlan_host
iface macvlan_host inet static
address 192.168.178.223 # Host IPv4 in MacVLAN
netmask 255.255.255.0
#gateway 192.168.178.1 # IPv4 of router (not used)
pre-up ip link add macvlan_host link br0 type macvlan mode bridge
up ip addr add 192.168.178.222/24 dev macvlan_host # Target IPv4 of DNS
post-down ip link del macvlan_host
iface macvlan_host inet6 static
address fd00::4a5d:35ff:fe1e:223/64 # Host IPv6 in MacVLAN
gateway fe80::4a5d:35ff:fe1e:17de # IPv6 of router (not used)
pre-up sysctl -w net.ipv6.conf.all.forwarding=1
up ip -6 addr add fd00::4a5d:35ff:fe1e:222/64 dev macvlan_host # Target IPv6 of DNS
Display More
(Please don't use this idea.)
My new idea was to remove this host IP address from the MacVLAN and grant the host PC access to the DNS via my router. Unfortunately, it's not possible to establish such an IP route via the same LAN port that the host PC is connected to the router via. Therefore, I removed one of my four LAN ports from the LAN bridge br0 and assigned it exclusively to the MacVLAN for AdGuard. This allows me to establish an IP route from the host PC via the router to the DNS. The ping is slightly slower this way, but that's not a problem.
Since this change, AdGuard's DNS and WebGUI have been permanently and reliably accessible. This makes it the best solution for me. (Note: If you don't have a free LAN port, you can also use a USB-to-LAN adapter. I tested this as a first attempt (because it was the easiest).)
In OMV7, you also have to set up the additional LAN port as DHCP. All other options didn't work for me. It's important that the LAN port doesn't have the same IP address nor MAC address as the MacVLAN. (This would cause a complete network crash.) In the Docker Compose I entered the name of the LAN adapter directly (not just eth3) as parent. You can check your LAN configuration by ip a in the command line to find the adapter names.
MacVLAN part of the Docker Compose:
[...]
networks:
macvlan_adguard:
driver: macvlan
enable_ipv6: true
driver_opts:
parent: enp8s0 # LAN port 4 (eth3) as parent
[...]
There used to be a menu in the OMV web GUI that allowed you to create a static IP route. This apparently no longer exists. Therefore, I created a systemd service that establishes the static route from the host PC via the router to the MacVLAN (with DNS) every time the PC is rebooted. This has worked flawlessly so far.
My system Service /etc/systemd/system/static-routes.service to enable the IP routing:
[Unit]
Description=Add static IP routes to MacVLAN IP for DNS (AdGuard, Pi-hole)
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/sbin/ip route replace 192.168.178.222 via 192.168.178.1 dev br0
ExecStart=/sbin/ip -6 route replace fd00::4a5d:35ff:fe1e:222 via fe80::4a5d:35ff:fe1e:17de dev br0
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Display More
The disadvantages of this solution are that you have to sacrifice one LAN port each on the PC and one on the router, and that Linux now establishes two parallel routes for IP traffic via the router. In my case, however, this doesn't cause any conflicts, as both LAN cables run directly from the router to the PC, so there's no difference in the path data packets take.
The following image illustrates the situation once again:
Perhaps this will help other users who encounter similar problems with a complex network configuration.
Best regards,
Mic.