Open Media Vault 7 (mit 2 LAN-Kabel) nicht erreichbar, wenn eines fehlt

Mic2025 · 21. März 2026 um 10:24

Ich habe in der Diskussion Richtige IPv6 für IPV64 bei FritzBox + OpenWRT ein Problem angerissen, was nicht Teil dieser Diskussion ist und auch nicht wirklich im Scope vom IPV64-Forum steht. Da du mir aber vielleicht doch ein paar nützliche Tipps geben kannst und das Open Media Vault Forum irgendwie noch im Winterschlaf ist (da antwortet keiner mehr), starte ich einfach mal eine neue Diskussion.

Wie sieht mein Setup aus?

Ich habe meinen Mini-PC, der vier 2.5 GbE LAN-Schnittstellen hat mit zwei LAN-Kabeln mit der FritzBox verbunden und an den zwei restlichen LAN-Schnittstellen zwei nachgeschaltete PCs hängen. Das erspart mir einen zusätzlichen Switch und ich habe die schnelle 2.5 GbE Verbindung von meinem NAS (auf eben diesem Mini-PC) direkt zu meinem Arbeits-Laptop.

Als Betriebssystem verwende ich Open Media Vault 7, welches auf Debian basiert. In OMV7 habe ich das Docker-Plugin installiert und darin wiederum diverse Container laufen. Einige davon benötigen ein MacVLAN und da es in Docker leider nicht möglich ist ein MacVLAN mit einer LAN-Brücke „br0“ als Parent einzurichten, musste ich den Weg gehen, ein separates LAN-Port (Eth.3 im Bild) aus der Brücke zu entnehmen und separat mit der Fritz!Box zu verbinden. Lange Zeit hatte ich darauf auch DHCP aktiviert aber seit kurzem ist es inaktiv. D.h., dieses Eth.3 LAN-Port bekommt keine IP-Adresse mehr.

Was ist nun das Problem?

Da ich zwischen LAN Eth.3 und Fritz!Box gern (wie im oben verlinkten Thread beschrieben) einen NanoPi R5S mit OpenWRT als zusätzlichen Router (Firewall, Filter, …) hängen wollte, habe ich das Kabel zu Eth.3 gestern einfach mal abgezogen. Schlagartig war OMV nicht mehr erreichbar – weder seine WebGUI unter seiner IP-Adresse (IPv4), noch per SSH, noch per Ping. Das gleiche passiert, wenn ich das Kabel an Eth.3 anstecke aber das Kabel an Eth.0 abziehe. Nur wenn beide Kabel gesteckt sind, ist es erreichbar. Und genau das sollte so nicht sein.

Vielleicht hat hier im Forum jemand eine Idee, woran das liegen mag.

Vielen Dank schon einmal im Voraus!

Grüße
Mic.

m-electronics · 21. März 2026 um 10:48

Moin Moin
Ist auch besser das hierher auszulagern

So wie du das Problem beschreibst, scheint da ja doch noch irgendwie Host-Traffic über das eth3 zu laufen. Aber scheinbar auch über eth0…

Ich kenne die Netzwerkkonfigurationsmöglichkeiten von OMV nicht, deswegen bitte mal die Debian-Netzwerk-Konfiguration zeigen…

Mic2025 · 21. März 2026 um 11:38

Was genau möchtest du von der Debian-Konfiguration sehen?

## /etc/network/interfaces

# This file is auto-generated by openmediavault
source-directory /etc/network/interfaces.d


## ip addr

enp5s0: UP, in br0
enp6s0: DOWN, in br0
enp7s0: DOWN, in br0
enp8s0: UP (separat, NICHT in br0)

br0: UP
  IPv4: 192.168.178.xxx/24
  IPv6: 2001:xxxx:xxxx:xxxx::/64

macvlan0@enp8s0:
  IPv4: 192.168.178.xxx/24


## ip route

default via 192.168.178.1 dev br0
192.168.178.0/24 dev br0
192.168.178.0/24 dev macvlan0

m-electronics · 21. März 2026 um 14:42

Ne, die /etc/network/interfaces oder mittlerweile vielleicht auch irgendwas unter /etc/systemd/network/*

Mic2025 · 21. März 2026 um 17:20

Das Blöde ist, dass da bei Open Media Vault 7 nichts mehr drin steht.

root@pc:/etc/systemd/network# ls -lah
insgesamt 8,0K
drwxr-xr-x 2 root root 4,0K 10. Okt 2024  .
drwxr-xr-x 7 root root 4,0K 20. Mär 22:55 ..

root@pc:/etc/systemd/network# cat /etc/network/interfaces
# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

# interfaces(5) file used by ifup(8) and ifdown(8)
# Better use netplan.io or systemd-networkd to configure additional interface stanzas.

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

root@pc:/etc/systemd/network# cd /etc/network/interfaces.d

root@pc:/etc/network/interfaces.d# ls -lah
insgesamt 8,0K
drwxr-xr-x 2 root root 4,0K 25. Jul 2025  .
drwxr-xr-x 7 root root 4,0K  8. Mär 2025  ..

Open Media Vault 7 nutzt nicht netplan. Es gibt aber ein globales /etc/openmediavault/config.xml (bei mir 2895 Zeilen), wo praktisch alles drin konfiguriert ist. Darin finde ich diese winzigen Abschnitt zur Netzwerkkonfiguration:

<interface>
  <uuid>********-****-****-****-************</uuid>
  <type>bridge</type>
  <devicename>br0</devicename>
  <method>dhcp</method>
  …
  <method6>dhcp</method6>
  <netmask6>64</netmask6>
  <routemetric6>1</routemetric6>
  <slaves>enp5s0, enp6s0, enp7s0</slaves>
  <comment>Eth. 0, Eth. 1, Eth. 2, LAN bridge</comment>
</interface>

Open Media Vault mag es auch gar nicht, wenn man von Hand in den Dateien rumfummelt. Da habe ich schon so meine Erfahrungen gesammelt.

m-electronics · 21. März 2026 um 17:36

Genau wegen sowas bastel ich nicht mehrere Geräte in eins…
Also wenn da Proxmox drauf wäre auf dem Mini-PC und OMV als VM hättest du weniger Stress

Mic2025 · 21. März 2026 um 17:42

Möglicherweise hast du Recht… ich habe halt genau anders herum begonnen. Open Media Vault 7 war meine Basis, weil ich ein einfaches NAS haben wollte. Darauf habe ich dann das Docker Plugin installiert und darin dann sukzessive mehr Dienste in Docker installiert. Dann habe ich irgendwann IPV64 entdeckt und die wahnsinnige Idee gehabt, dass ich damit eigene Web-Dienste hosten kann. Und jetzt möchte ich sie eben noch mit einem Gürtel (OpenWRT) zum Hosenträger (CrowdSec) schützen.

Wobei ich die Idee und Möglichkeiten von Docker nach wie vor echt gut finde.

Nur habe ich mir jetzt eben mit zunehmender Komplexität irgendwo ein Ei ins Nest gelegt, was mir Bauchschmerzen macht… und was ich nicht wieder finde.

m-electronics · 21. März 2026 um 17:58

Docker ist ja auch nicht schlecht. Aber das kannst du besser alles getrennt auf Proxmox installieren

Mic2025 · 21. März 2026 um 18:13

Ich sehe eben, dass wir im falschen Thread weiter diskutiert hatten.

[m-electronics] Das müsste man mal tracen im Netz, aber das ist nicht so einfach, weil das ja nicht als Broadcast an alle geht, zumindest nicht alles…

[Mic2025] Das komische ist übrigens: Wenn ich das Kabel an Eth.3 abziehe und den PC reboote, dann ist OMV in den ersten Sekunden nach Neustart für eine (sehr) kurze Zeit erreichbar. Dann scheint irgendein Dienst zu starten, der es „zumacht“.

[m-electronics] Firewall könnte natürlich auch noch sein…
Durch dieses ganze Hin- und her hier hab ich meinen strengen Fehlersuchpfad verlassen

[Mic2025] Hilft das hier weiter?

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:85 brd ff:ff:ff:ff:ff:ff

3: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br0 state DOWN mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:86 brd ff:ff:ff:ff:ff:ff

4: enp7s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br0 state DOWN mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:87 brd ff:ff:ff:ff:ff:ff

5: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:88 brd ff:ff:ff:ff:ff:ff

6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:A9 brd ff:ff:ff:ff:ff:ff

7: macvlan0@enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:D8 brd ff:ff:ff:ff:ff:ff

9: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:59 brd ff:ff:ff:ff:ff:ff

10: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:82 brd ff:ff:ff:ff:ff:ff

11: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:76 brd ff:ff:ff:ff:ff:ff

13: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:0F brd ff:ff:ff:ff:ff:ff

17: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:A4 brd ff:ff:ff:ff:ff:ff link-netnsid 3

19: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:36 brd ff:ff:ff:ff:ff:ff link-netnsid 5

24: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:2F brd ff:ff:ff:ff:ff:ff link-netnsid 9

25: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:A9 brd ff:ff:ff:ff:ff:ff link-netnsid 10

26: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:EF brd ff:ff:ff:ff:ff:ff link-netnsid 11

28: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:C1 brd ff:ff:ff:ff:ff:ff link-netnsid 14

29: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:6B brd ff:ff:ff:ff:ff:ff link-netnsid 15

38: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:0B brd ff:ff:ff:ff:ff:ff

39: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:CA brd ff:ff:ff:ff:ff:ff link-netnsid 6

40: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:7A brd ff:ff:ff:ff:ff:ff link-netnsid 16

41: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:79 brd ff:ff:ff:ff:ff:ff link-netnsid 18

52: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:0A brd ff:ff:ff:ff:ff:ff

53: vethXXXXXXXX@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:1E brd ff:ff:ff:ff:ff:ff link-netnsid 0

Mic2025 · 21. März 2026 um 18:18

Firewall könnte natürlich auch noch sein…

Die Feuerwand hatte ich auch im Verdacht. Ich hatte testweise mal mein Script, was bei jedem Reboot die Firewall-Rules setzt, deaktiviert. Das half schon mal nicht. Dennoch kann da auch was im Argen sein… nur wo…?

m-electronics · 21. März 2026 um 18:33

iptables -nvL
nftables list ruleset

Mic2025 · 21. März 2026 um 20:10

root@pc:~# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       0    --  macvlan0 *       192.168.178.48/29    0.0.0.0/0
    0     0 DROP       0    --  enp8s0 *       192.168.178.32/28    0.0.0.0/0
1418K   15G LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "IPTables-Input: "
    0     0 LOG        0    --  macvlan_host *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "MACVLAN-Input: "

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 104K   43M DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 104K   43M DOCKER-FORWARD  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     0    --  enp5s0 br0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    enp5s0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  enp6s0 br0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    enp6s0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  enp7s0 br0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    enp7s0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  macvlan_host br0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    macvlan_host  0.0.0.0/0            0.0.0.0/0
91712   36M LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "IPTables-Forward: "
    0     0 LOG        0    --  macvlan_host *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "MACVLAN-Forward: "

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
1156K  888M LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "IPTables-Output: "

Chain DOCKER (6 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     6    --  !br-078075b72338 br-078075b72338  0.0.0.0/0            172.21.0.4           tcp dpt:11434
    0     0 ACCEPT     6    --  !br-078075b72338 br-078075b72338  0.0.0.0/0            172.21.0.3           tcp dpt:80
    1    52 ACCEPT     6    --  !br-f70a98d21268 br-f70a98d21268  0.0.0.0/0            172.19.0.4           tcp dpt:8080    0     0 ACCEPT     6    --  !br-078075b72338 br-078075b72338  0.0.0.0/0            172.21.0.2           tcp dpt:80
    8   416 ACCEPT     6    --  !br-f70a98d21268 br-f70a98d21268  0.0.0.0/0            172.19.0.3           tcp dpt:3000    0     0 DROP       0    --  !br-f70a98d21268 br-f70a98d21268  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       0    --  !br-078075b72338 br-078075b72338  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       0    --  !br-093deb96b4f9 br-093deb96b4f9  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       0    --  !docker0 docker0  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       0    --  !br-7818c0bb0af2 br-7818c0bb0af2  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       0    --  !br-8272bbbe89eb br-8272bbbe89eb  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
 pkts bytes target     prot opt in     out     source               destination
   16   888 DOCKER     0    --  *      br-f70a98d21268  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     0    --  *      br-078075b72338  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     0    --  *      br-093deb96b4f9  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     0    --  *      br-7818c0bb0af2  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     0    --  *      br-8272bbbe89eb  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-CT (1 references)
 pkts bytes target     prot opt in     out     source               destination
 5588 2029K ACCEPT     0    --  *      br-f70a98d21268  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  *      br-078075b72338  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  *      br-093deb96b4f9  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 2830 1165K ACCEPT     0    --  *      br-7818c0bb0af2  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  *      br-8272bbbe89eb  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination
 104K   43M DOCKER-CT  0    --  *      *       0.0.0.0/0            0.0.0.0/0
95124   39M DOCKER-INTERNAL  0    --  *      *       0.0.0.0/0            0.0.0.0/0
95124   39M DOCKER-BRIDGE  0    --  *      *       0.0.0.0/0            0.0.0.0/0
  402 2874K ACCEPT     0    --  br-f70a98d21268 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br-078075b72338 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br-093deb96b4f9 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  docker0 *       0.0.0.0/0            0.0.0.0/0
 2971  568K ACCEPT     0    --  br-7818c0bb0af2 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br-8272bbbe89eb *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-INTERNAL (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
root@pc:~#

nftables gibt es bei OMV7 nicht.

m-electronics · 22. März 2026 um 08:32

Was ist das mit diesen /29 und /28 Subnetzen die im Fritzbox-Subnetz liegen? Das klingt nicht gut…

Mic2025 · 22. März 2026 um 09:56

Ich schätze, du spielst auf diese beiden Zeile an:

 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       0    --  macvlan0 *       192.168.178.48/29    0.0.0.0/0
    0     0 DROP       0    --  enp8s0 *       192.168.178.32/28    0.0.0.0/0

Ich schätze, dass das erste „Subnetz“ (/29) ein MacVLAN ist, was Docker sich aufsetzt. Und das zweite Sub-Netz (/28) ist die Range, die ich Docker gegeben habe, um einen Adressbereich für dieses MacVLAN aufzuspannen: ip_range: 192.168.178.32/28. Die IP-Adresse 192.168.178.48 findet sich nicht in meinem Docker Compose File. Die muss sich das Docker MacVLAN selbst zugeteilt haben.

m-electronics · 22. März 2026 um 10:01

Ein Macvlan hat keine IP-Addressen auf dem Host.
Das kriegt nur das Netz konfiguriert, was auf dem Interface, wo das Macvlan hin geht, anliegt.
Das funktioniert so nicht meines Wissens nach, warum es trotzdem funktioniert, weiß ich nicht…

Aber man müsste mal tcpdump laufen lassen auf beiden Interfaces und dann mal eins abziehen und schauen, wo überhaupt der Traffic läuft.

Und das Interface macvlan_host taucht auch nirgends anders auf

Mic2025 · 22. März 2026 um 12:46

Hallo!

Ich denke, ich habe den Fehler gefunden und du hast den Finger drauf. Es war/ist „selbstverschuldetes Leid“. Ich habe auf meinem Host-PC ein Skript laufen, was ein „künstliches“ Gateway erstellt, damit ein Docker Container mit MacVLAN ins Internet kann. Docker hat bei IPv4 leider die blöde Einschränkung, dass man ein Gateway nur für ein MacVLAN verwenden darf. Bei IPv6 gibt es diese Einschränkung nicht. Und da ich zwei MacVLAN bei mir laufen habe, konnte ich nur einem die IP der Fritz!Box als Gateway geben. Für das andere MacVLAN habe ich ein weiteres Gateway auf dem Host-PC erstellt und es starte sich bei jedem Reboot als SystemCtl Dienst.

Das Skript sieht so aus:

#!/bin/bash

# Bridge-Interface erstellen
ip link add macvlan0 link enp8s0 type macvlan mode bridge
ip addr add 192.168.178.20/24 dev macvlan0
ip link set macvlan0 up

# IP Forwarding aktivieren
sysctl -w net.ipv4.ip_forward=1

# NAT aktivieren (MASQUERADE, falls noch nicht vorhanden)
iptables -t nat -C POSTROUTING -s 192.168.178.0/24 -o enp8s0 -j MASQUERADE 2>/dev/null || \
iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o enp8s0 -j MASQUERADE

# 🔐 Host-Isolation gegen MACVLAN-Container
# Regel nur hinzufügen, wenn sie nicht existiert
iptables -C INPUT -s 192.168.178.48/29 -i macvlan0 -j DROP 2>/dev/null || \
iptables -I INPUT -s 192.168.178.48/29 -i macvlan0 -j DROP

echo "Macvlan-Gateway & Sicherheitsregel gesetzt ✅"

Deaktiviere ich den entsprechenden SystemCtlDienst und reboote, ist der Host-PC auch erreichbar, wenn man das Kabel Eth.3 abzieht.

Also alternative Lösung habe ich nun dieses Skript gebastelt. Damit scheint der Fehler bei Abziehen des Kabels nicht aufzutreten. Es verursacht aber ein neues Problem. Die FritzBox weigert sich nun meinem Reverse Proxy Caddy (der eine ganz andere IPv4-Adresse hat) eine Portfreigabe zu erteilen. Sie tut es einfach nicht.

#!/bin/bash
set -e

# Namespace existiert bereits? Dann löschen wir ihn sauber.
ip netns delete gwB 2>/dev/null || true

# Namespace neu anlegen
ip netns add gwB

# MacVLAN für FritzBox-Netz erzeugen
ip link add macvlanB link enp8s0 type macvlan mode bridge
ip link set macvlanB netns gwB

# IP im FritzBox-Netz setzen
ip netns exec gwB ip addr add 192.168.178.20/24 dev macvlanB
ip netns exec gwB ip link set macvlanB up

# veth-Paar erzeugen
ip link add veth-hostB type veth peer name veth-gwB
ip link set veth-gwB netns gwB

# Host-Seite aktivieren
ip addr add 10.10.20.1/24 dev veth-hostB
ip link set veth-hostB up

# Namespace-Seite aktivieren
ip netns exec gwB ip addr add 10.10.20.2/24 dev veth-gwB
ip netns exec gwB ip link set veth-gwB up

# Default-Route im Namespace
ip netns exec gwB ip route add default via 192.168.178.1

# NAT im Namespace
ip netns exec gwB iptables -t nat -A POSTROUTING -o macvlanB -j MASQUERADE

Jetzt bin ich am überlegen: In Zukunft sollen ja alle MacVLAN’s in das Sub-Netz von OpenWRT verschoben werden. Gäbe es direkt in OpenWRT vielleicht eine elegantere Lösung ein zweites „künstliches“ Gateway zu erzeugen, was einen Zugriff der Container ins Internet ermöglicht? AdGuard Home braucht das z.B., um seine Blocklisten zu aktualisieren. Oder NextCloud braucht es, um Wetterdaten und Apps upzudaten.

Wenn das ginge, bräuchte ich auf dem Mini-PC keine Kopfstände mehr machen. Wenn nicht, bräuchte ich ein neues SystemCtlSkript, was mir ein Gateway erzeugt ohne all die o.g. Probleme zu haben.

Gestern standen wir am Abgrund. Heute sind wir einen Schritt weiter.

Vielen Dank schon mal für gute Tipps, wie ich hier am sinnvollsten weiter gehe…

Grüße
Mic.

m-electronics · 22. März 2026 um 13:17

Ich schaue nachher mal genauer in das Script rein, irgendwie ist das alles sehr unterschiedlich zu dem, wie man MACVLANs eigentlich erstellt und benutzt…
Und das Script klingt sehr nach ChatGPT oder einer anderen KI… Die spucken bei sowas auch immer noch gerne Blödsinn aus…

m-electronics · 22. März 2026 um 16:10

Warum genau hast du überhaupt zwei Macvlans für ein Subnetz (dass der Fritzbox, später das des OpenWRT)? Das macht irgendwie wenig Sinn, ein Macvlan ist ja extra dafür da, dass die Container direkt im Netzwerk sind, was an dem Port ankommt…

Und dieses ganze Masquerading-NAT ist auch unlogisch, weil man genau das ja nicht will beim Macvlan. Da sollen die Container ja eine IP aus dem Netz haben, was an dem Port ankommt und eben nicht in einem internen Docker-Netzwerk…

Mic2025 · 22. März 2026 um 18:13

Ertappt… bei den Skripten habe ich mit von Copilot helfen lassen und was wir da gebaut haben, hat ja auch gut funktioniert.

Ich habe zwei Docker Compose Files mit zwei unterschiedlichen MacVLAN. Ein MacVLAN brauche ich für AdGuard Home, weil es sonst Port-Konflikte zu OMV7 gibt. Das zweite MacVLAN habe ich, weil ich darin all meine Web-Dienste gepackt habe, um sie vom Host isolieren zu können. Genau dieses MacVLAN möchte ich ja durch OpenWRT besser schützen. Alle MacVLAN werden im jeweiligen Docker Compose File definiert und erstellt und haben einen eigenen Bereich an IP-Adressen im Netz der FritzBox, den sie nutzen können.

Und ja, die Container in den Dockern haben dann ihre eigenen IP-Adressen - aktuell im Netz der Fritz!Box.

m-electronics · 22. März 2026 um 18:19

So funktioniert das nicht!
Ein Macvlan ist dafür da, damit ein Container eine eigene IP im Fritzbox-Netz kriegt. Da kann es keine Portkonflikte geben. Aber ich hab auch gerade nicht die Kapazitäten mich da tiefer in deine Struktur einzuarbeiten.