16
Wireguard - vLAN-Routing, EdgeOS
Ne Frage, mal wieder. Was sonst 
Meine VPN-Odyssee nimmt irgendwie kein Ende.
Bin nach dem kurzen Ausflug in die IPSec-Welt wieder zurück zu WG – da weiß ich (eigentlich), was ich habe. Am EdgeRouter will er mir das WG-Paket nicht (mehr) installieren. Die .deb-Datei ist angeblich nicht Debian-kompatibel aber ich habe ja noch ein Unraid/NAS, welches Wireguard von sich aus anbietet. Ziel ist, dass ein Büro-Client Backups auf dem Netzwerkspeicher zu Hause(!) anlegen kann (grüne Linie):
Aktueller Stand:
Problem:
Ich kann zwar problemlos von "zu Hause" auf die Geräte im Büro zugreifen – aber umgekehrt klappt es nicht! Wenn ich von einem Büro-Client (10.98.33.15) versuche die 10.98.200.2 ODER 192.168.66.0/24 "traceroute", endet der Spaß bei 10.98.33.1, dem vLAN-DHCP/Router.
A: VPN ist bei Unraid integriert,
eigene Adresse: 10.98.200.2/29
NAT: aktiviert
Peer-Type: LAN to LAN access
Peer-Tunnel-Adresse: 10.98.200.1
Peer allowed IPs = 10.98.200.0/29,192.168.66.0/24
RoutingTable: 10.98.200.0/29 > Gateway/wg0; 192.168.66.0/24 > wg0
B: Static Route: gateway, dest: 192.168.66.0/24, next hop 10.98.33.6
Static Route: gateway, dest: 10.98.200.0/29, next hop 10.98.33.6
Port forwarding: 51888/UDP > forward 10.98.33.6/51888, WAN-interf: eth0, LAN-interf: switch0.33
FW-Ruleset vlan33: accept all protocolls, source: 10.98.200.0/29
C: Portfreigabe 192.168.66.7/UDP51888
Routing-Table 10.98.0.0/255.255.0.0 > Gateway 192.168.66.7
D: AllowedIPs = 10.98.200.0/29,10.98.33.0/26,10.98.0.0/26
Nachdem ich ja ein ziemlicher Newbee bei vLANs bin (und ebenso dem EdgeRouter) wird wohl da der Wurm zu suchen sein. Hat irgend jemand einen Tipp, woran das liegen könnte?! Ich probiere da jetzt ja schon einige Tage rum und langsam geht mir das an die Nieren. 😩
Viele Grüße
PS: ... vielleicht ist es doch eher ein Stoßgebet an die kundigen Geister
#EDIT#
zu B:
PortForwarding: "Hairpin" aktiviert.
Kein Wireguard-"Interface"
Kein NAT konfiguriert – man könnte in EdgeOS "Source" und "Destination"-NAT konfigurieren
Meine VPN-Odyssee nimmt irgendwie kein Ende.
Bin nach dem kurzen Ausflug in die IPSec-Welt wieder zurück zu WG – da weiß ich (eigentlich), was ich habe. Am EdgeRouter will er mir das WG-Paket nicht (mehr) installieren. Die .deb-Datei ist angeblich nicht Debian-kompatibel aber ich habe ja noch ein Unraid/NAS, welches Wireguard von sich aus anbietet. Ziel ist, dass ein Büro-Client Backups auf dem Netzwerkspeicher zu Hause(!) anlegen kann (grüne Linie):
Aktueller Stand:
Problem:
Ich kann zwar problemlos von "zu Hause" auf die Geräte im Büro zugreifen – aber umgekehrt klappt es nicht! Wenn ich von einem Büro-Client (10.98.33.15) versuche die 10.98.200.2 ODER 192.168.66.0/24 "traceroute", endet der Spaß bei 10.98.33.1, dem vLAN-DHCP/Router.
A: VPN ist bei Unraid integriert,
eigene Adresse: 10.98.200.2/29
NAT: aktiviert
Peer-Type: LAN to LAN access
Peer-Tunnel-Adresse: 10.98.200.1
Peer allowed IPs = 10.98.200.0/29,192.168.66.0/24
RoutingTable: 10.98.200.0/29 > Gateway/wg0; 192.168.66.0/24 > wg0
B: Static Route: gateway, dest: 192.168.66.0/24, next hop 10.98.33.6
Static Route: gateway, dest: 10.98.200.0/29, next hop 10.98.33.6
Port forwarding: 51888/UDP > forward 10.98.33.6/51888, WAN-interf: eth0, LAN-interf: switch0.33
FW-Ruleset vlan33: accept all protocolls, source: 10.98.200.0/29
C: Portfreigabe 192.168.66.7/UDP51888
Routing-Table 10.98.0.0/255.255.0.0 > Gateway 192.168.66.7
D: AllowedIPs = 10.98.200.0/29,10.98.33.0/26,10.98.0.0/26
Nachdem ich ja ein ziemlicher Newbee bei vLANs bin (und ebenso dem EdgeRouter) wird wohl da der Wurm zu suchen sein. Hat irgend jemand einen Tipp, woran das liegen könnte?! Ich probiere da jetzt ja schon einige Tage rum und langsam geht mir das an die Nieren. 😩
Viele Grüße
PS: ... vielleicht ist es doch eher ein Stoßgebet an die kundigen Geister
#EDIT#
zu B:
PortForwarding: "Hairpin" aktiviert.
Kein Wireguard-"Interface"
Kein NAT konfiguriert – man könnte in EdgeOS "Source" und "Destination"-NAT konfigurieren
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1291422783
Url: https://administrator.de/contentid/1291422783
Printed on: April 23, 2024 at 15:04 o'clock
16 Comments
Latest comment
10.98.33.1 wird der Standard Gatway sein im VLAN33.
Denn musst du die Route zu 10.98.200.2 ODER 192.168.66.0 über 10.98.33.6 bekannt machen
Denn musst du die Route zu 10.98.200.2 ODER 192.168.66.0 über 10.98.33.6 bekannt machen
eigene Adresse: 10.98.200.2/29
Stimmt nicht mit der o.a. Zeichnung übereinNAT: aktiviert
Fehler !In internen Site-to-Site VPN Netzwerken macht man niemals NAT im Tunnel ! Damit erzeugst du dir eine NAT Firewall die das Routing zu einer Einbahnstrasse macht da in die andere Richtung Sessions niemals die NAT Firewall überwinden können. Das ist zu 98% auch dein Problem oben.
wird wohl da der Wurm zu suchen sein.
Nein !Deine Router bzw. Firewall sind ja nur doofe "Durchlauferhitzer" für den WG Tunnel, denn sie forwarden ja nur stumpf per Port Forwarding den WG UDP Port auf die jeweiligen WG Server bzw. Client.
Nebenbei übrigens immer ein sehr schlechtes Design aus Sicherheitssicht, denn mit diesen Port Forwarding Löchern in der Firewall/Router schleust du ungeschützen Internet Traffic in deine lokalen IP Netze.
Unverständlich warum du nicht bei IPsec bleibst und von der FritzBox einen stinknormalen IPsec Tunnel auf den Edge Router machst. Wäre doch das Einfachste.
Fazit:
Kardinals Fehler ist dein überflüssiges NAT auf dem WG Server ! Inbound Sessions von der WG Client Seite können die NAT Firewall nicht überwinden. Du kannst also immer nur Sessions vom 192.168.66.0er Netz zum 10.98.33.0er Netz aufmachen aber niemals umgekehrt weil NAT das verhindert.
Ist die übliche NAT Logik die du als alter Netzwerk Profi hier im Forum nun langsam kennen solltest...
2
@Xerebus:
Ja, so vermute ich auch. Ich weiß aber nicht, wie ich ihm das beibringe? Ich habe "eigentlich" folgende Routen konfiguriert:
@aqui:
Anbei das komplette WG-Setup der Büro-Seite. "Synology" ist die Home-Site.
Wie gesagt: Wenn ich von einem Rechner im Büronetz (33.0/26) nen Tracert auf das Home-Netz mache ODER die interne WG-Adressbereiche (200.2 oder 200.1) endet das beim ersten Punkt 10.98.33.1. Irgendwie weiß der dann nicht weiter.
Ich kann auf dem Unraid - dem VPN-Host - selber über die CLI problemlos das Home-Netz pingen.
Anbei auch das Routing-Table des Unraid-NAS:
Ja, so vermute ich auch. Ich weiß aber nicht, wie ich ihm das beibringe? Ich habe "eigentlich" folgende Routen konfiguriert:
@aqui:
Stimmt nicht mit der o.a. Zeichnung überein
Ich habs "zusammengefasst" Anbei das komplette WG-Setup der Büro-Seite. "Synology" ist die Home-Site.In internen Site-to-Site VPN Netzwerken macht man niemals NAT im Tunnel !
Ja, monierst Du ja häufiger und ich habe es deshalb extra noch ergänzt. Daran liegts aber irgendwie auch nicht, weil es auch ohne NAT (siehe Screenshot) oben nicht funktioniert.ein sehr schlechtes Design aus Sicherheitssicht,
Jo, weiß ich. Aber WG am EdgeRouter war nen "Gefrickel" und lässt sich aktuell nicht (neu) installieren. Zum neu aufsetzen des gesamten Routers habe ich aber aktuell keinen Bock. Sollte ne interessante Version des Mikrotik 5009 mit PoE erscheinen wandert der Edge eh auf die "Home-Site" und unterstützt die dortige Fritzbox. Das dauert aber noch einige Monate ... und dann muss der Kram ja auch lieferbar sein. Das ist ja Heute auch keine Selbstverständlichkeit mehr.von der FritzBox einen stinknormalen IPsec Tunnel auf den Edge Router machst
Jo, war ja durchaus eine präferierte Option. Bin aber definitiv zu doof dazu und am Ende funktionierte das l2tp/IPSec auf BüroSeite auch nicht mehr. Die Anleitungen die ich dazu benutzte mit den .config-Files waren aber evtl. auch einfach überholt.Wie gesagt: Wenn ich von einem Rechner im Büronetz (33.0/26) nen Tracert auf das Home-Netz mache ODER die interne WG-Adressbereiche (200.2 oder 200.1) endet das beim ersten Punkt 10.98.33.1. Irgendwie weiß der dann nicht weiter.
Ich kann auf dem Unraid - dem VPN-Host - selber über die CLI problemlos das Home-Netz pingen.
Anbei auch das Routing-Table des Unraid-NAS:
Daran liegts aber irgendwie auch nicht, weil es auch ohne NAT (siehe Screenshot) oben nicht funktioniert.
Wenn auf deinem Unraid tcpdump rennt sieh dir zur Sicherheit nochmal die am wg0 Port eingehenden Pakete dort an WELCHE Absender IP die wirklich haben. Das Verhalten sieht wirklich sehr stark nach NAT aus.Du kannst es ja daran sehen das es in eine Richtung sauber klappt, sprich die Rückroute oder ICMP Antwort kann den Tunnel generell auch in die andere Richtung passieren. Das liegt daran weil es im NAT des Servers einen Session Eintrag gibt. Dieser fehlt wenn du Sessions von der anderen Seite initiierst, dann bleibt das am NAT hängen. Zwischen den beiden Tunnel Endpunkten gibt es ja keinerlei Firewall was sollte da also blocken ?
Ich kann auf dem Unraid - dem VPN-Host - selber über die CLI problemlos das Home-Netz pingen.
Klar, weil du dann eine Absender IP aus dem wg0 Tunnel hast.Um es aber genau zu sagen müsste man mal deine beiden wg0.conf Dateien hier sehen. Ohne die ist das Raten im freien Fall...
Mit IPsec wäre es in der Tat die technisch eleganteste Variante gewesen im Vergleich zu der eigentlich völlig überflüssigen Materialschlacht die du jetzt machst. Fragt man sich warum du 2 gute VPN Router besitzt und diese nicht sinnvoll nutzt ?! Aber egal, zum IPsec Drama sag ich jetzt mal besser nix...
1
... tja, was soll ich sagen. War dann doch ein lehrreicher Nachmittag. Jetzt weiß ich:
a) das es Wireshark nicht für Unraid gibt
b) tcpdump dort bequem über das Plugin "NerdTool" zu installieren ist - wie viele anderen CLI-Tools auch
c) das die Wireguard-Peers auch nach Neuinstallation des WG-Pakets auf Unraid erhalten bleiben
d) ... es weder am Routing noch am WG-Setup lag
Mir fiel auf, dass das Traceroute abhängig vom vLAN unterschiedlich "erfolgreich" war. Nach löschen aller diesbezüglichen Firewall-Regeln geht es. Das hatte ich vorher eher ausgeschlossen, weil ja "eigentlich" alle betroffenen Geräte innerhalb des gleichen vLANs liefen. Das der 200-Endpunkt dann ausgerechnet aus einem anderen vLAN erreichbar war, überraschte mich dann doch etwas. Da muss ich wohl nochmal genauer hinschauen 😏
Vielen Dank an "alle" Tippgeber.
PS:
... besser ist das. Das Thema ärgert mich vermutlich am meisten. Es hängt am Ende schlicht an den von Dir schon mal empfohlenen "Testgeräten". Meine "Selbstverwirklichung" an Geräten des laufenden Betriebs kommt dann doch bei den Möglichkeiten der Fehleranalyse schnell an Grenzen ...
Aber Weihnachten ist nicht weit und das Ziel soll ein durchgängiges Mikrotik-Setup (Wire) hier im Büro sein. Bin schon kräftig am Einlesen (https://help.mikrotik.com/docs/)
a) das es Wireshark nicht für Unraid gibt
b) tcpdump dort bequem über das Plugin "NerdTool" zu installieren ist - wie viele anderen CLI-Tools auch
c) das die Wireguard-Peers auch nach Neuinstallation des WG-Pakets auf Unraid erhalten bleiben
d) ... es weder am Routing noch am WG-Setup lag
Mir fiel auf, dass das Traceroute abhängig vom vLAN unterschiedlich "erfolgreich" war. Nach löschen aller diesbezüglichen Firewall-Regeln geht es. Das hatte ich vorher eher ausgeschlossen, weil ja "eigentlich" alle betroffenen Geräte innerhalb des gleichen vLANs liefen. Das der 200-Endpunkt dann ausgerechnet aus einem anderen vLAN erreichbar war, überraschte mich dann doch etwas. Da muss ich wohl nochmal genauer hinschauen 😏
Vielen Dank an "alle" Tippgeber.
PS:
Aber egal, zum IPsec Drama sag ich jetzt mal besser nix...
... besser ist das. Das Thema ärgert mich vermutlich am meisten. Es hängt am Ende schlicht an den von Dir schon mal empfohlenen "Testgeräten". Meine "Selbstverwirklichung" an Geräten des laufenden Betriebs kommt dann doch bei den Möglichkeiten der Fehleranalyse schnell an Grenzen ...
Aber Weihnachten ist nicht weit und das Ziel soll ein durchgängiges Mikrotik-Setup (Wire) hier im Büro sein. Bin schon kräftig am Einlesen (https://help.mikrotik.com/docs/)
a.) Auf einem NAS hat ehrlich gesagt auch ein VPN Server nix zu suchen !
von Dir schon mal empfohlenen "Testgeräten".
Von so einem Schrott wie dem Edge Router hast du niemals eine Empfehlung bekommen wie du dir sicher denken kannst.
Aktuell geht Funktion über "optimal wäre"
Hier haben sich einfach einige Erkenntnisse und Änderungen ergeben. U.a.
a) Hitzeentwicklung am Einbauort
b) 20 fache Internetanbindung
c) fehlende Performance des Mikrotik-Router-Setups
d) Überarbeitung des Backup-Konzepts
e) Anzahl Clients
f) usw.
Da musste ich mit dem Setup und der vorhanden HW etwas improvisieren ... natürlich im Rahmen meiner sehr limitierten Fähigkeiten. Und das Thema "Testgerät" für Setup-Änderung und Fehleranalyse ohne den laufenden Betrieb unterbrechen zu müssen ist ja durchaus herstellerübergreifend.
... alles im Fluss
Hier haben sich einfach einige Erkenntnisse und Änderungen ergeben. U.a.
a) Hitzeentwicklung am Einbauort
b) 20 fache Internetanbindung
c) fehlende Performance des Mikrotik-Router-Setups
d) Überarbeitung des Backup-Konzepts
e) Anzahl Clients
f) usw.
Da musste ich mit dem Setup und der vorhanden HW etwas improvisieren ... natürlich im Rahmen meiner sehr limitierten Fähigkeiten. Und das Thema "Testgerät" für Setup-Änderung und Fehleranalyse ohne den laufenden Betrieb unterbrechen zu müssen ist ja durchaus herstellerübergreifend.
... alles im Fluss
b) Zu 20 verschiedenen Internet Providern ?? Oder wie ist das zu verstehen ?? 🤔
c) Du meinst die Performance Problematik mit dem Routing über VLAN Interfaces ? Wenn ja, mach das über einen anderen nicht MT L3 Switch
c) Du meinst die Performance Problematik mit dem Routing über VLAN Interfaces ? Wenn ja, mach das über einen anderen nicht MT L3 Switch
natürlich im Rahmen meiner sehr limitierten Fähigkeiten.
Budget technisch limitiert oder wie ist das zu verstehen ? 🤔
b) Ne 50/10 DSL zu 1.000/50 Kabel ... auch wenn die 1.000 eh nie/SELTEN anliegen
c) Jo. In der idealen Welt hätte ich nochmal versucht die vLANs konkret auf den Switch-Chips zu konfigurieren. Offenbar greift ja das Offloading beim Bridge-Setup nicht. Wie ich mittlerweile lernte, gibt es bei Mikrotik 3 Möglichkeiten sowas aufzusetzen. Nur das würde mit meiner fehlenden Erfahrung Tage dauern, bis das alles (vielleicht) wieder läuft.
Deshalb erst Plan B: Den "Kellerfund" EdgeRouter (Dualcore 880 + PoE) für die vLANs davor. Der befeuert den Mikrotik mit PoE welcher aktuell mit SwitchOS läuft. Dieses Setup schafft wenigstens mehr als 160 Mbit/s. Dafür empfinde ich u.a. das WG-Setup in VyOS als ziemlich "speziell". Ich bin mir auch nicht sicher ob die Edge-Serie eine Zukunft bei Unifi hat - scheint immer mehr in die Nische zu rutschen.
Deshalb: Sobald die Mikrotik 5009er Serie lieferbar ist – idealerweise mit PoE – baue ich das Setup einfach parallel/offline "nach"; WG dann im Router integriert und die beiden Mikrotiks mit SFP+/10 Gbit/s verbunden. Die beiden Netzwerkports des UNRAID bekommen bonding und werden als Trunk angebunden ... so der Plan.
Intellektuell oder zumindest "wissenstechnisch" ... meinte ich. Die 300 EUR für das neue Routersetup werde ich gerne wuppen, weil mich das auch technisch interessiert und ich mich damit mal "richtig" ins RouterOS einarbeiten möchte. Aktuell klicke ich ja nur die Anleitungen "nach".
Über die kleinen Hürden der vLAN- und Firewall-Settings stolpere ich ja ganz offenbar erst im laufenden Betrieb ... Airplay klappt z.B. aktuell auch nur teilweise über die vLANs, usw. D.h. derzeit habe ich sogar schon die Anzahl der vLANs wieder reduziert – was aber ja nicht Sinn der Sache ist
Wichtig war mir erstmal, dass meine Backups im NAS des kühlen heimischen Kellers lagern, alle arbeiten könne (auch per VPN) und alle (relevanten) Funktionen jederzeit abrufbar sind.
c) Jo. In der idealen Welt hätte ich nochmal versucht die vLANs konkret auf den Switch-Chips zu konfigurieren. Offenbar greift ja das Offloading beim Bridge-Setup nicht. Wie ich mittlerweile lernte, gibt es bei Mikrotik 3 Möglichkeiten sowas aufzusetzen. Nur das würde mit meiner fehlenden Erfahrung Tage dauern, bis das alles (vielleicht) wieder läuft.
Deshalb erst Plan B: Den "Kellerfund" EdgeRouter (Dualcore 880 + PoE) für die vLANs davor. Der befeuert den Mikrotik mit PoE welcher aktuell mit SwitchOS läuft. Dieses Setup schafft wenigstens mehr als 160 Mbit/s. Dafür empfinde ich u.a. das WG-Setup in VyOS als ziemlich "speziell". Ich bin mir auch nicht sicher ob die Edge-Serie eine Zukunft bei Unifi hat - scheint immer mehr in die Nische zu rutschen.
Deshalb: Sobald die Mikrotik 5009er Serie lieferbar ist – idealerweise mit PoE – baue ich das Setup einfach parallel/offline "nach"; WG dann im Router integriert und die beiden Mikrotiks mit SFP+/10 Gbit/s verbunden. Die beiden Netzwerkports des UNRAID bekommen bonding und werden als Trunk angebunden ... so der Plan.
Budget technisch limitiert oder wie ist das zu verstehen ? 🤔
Intellektuell oder zumindest "wissenstechnisch" ... meinte ich. Die 300 EUR für das neue Routersetup werde ich gerne wuppen, weil mich das auch technisch interessiert und ich mich damit mal "richtig" ins RouterOS einarbeiten möchte. Aktuell klicke ich ja nur die Anleitungen "nach".
Über die kleinen Hürden der vLAN- und Firewall-Settings stolpere ich ja ganz offenbar erst im laufenden Betrieb ... Airplay klappt z.B. aktuell auch nur teilweise über die vLANs, usw. D.h. derzeit habe ich sogar schon die Anzahl der vLANs wieder reduziert – was aber ja nicht Sinn der Sache ist
Wichtig war mir erstmal, dass meine Backups im NAS des kühlen heimischen Kellers lagern, alle arbeiten könne (auch per VPN) und alle (relevanten) Funktionen jederzeit abrufbar sind.
Airplay klappt z.B. aktuell auch nur teilweise über die vLANs
Dafür brauchst du ein Bonjour Gateway aka mDNS Forwarding (Link Local Multicast) sonst klappt das nicht. Gilt generell für alle Dienste die mDNS basierend sind.Ich werde mich mal am Chip basierten Forwarding versuchen auf einem CRS. Ich meine das geht aber nicht für L3. Mal sehen...
Dafür brauchst du ein Bonjour Gateway aka mDNS Forwarding (Link Local Multicast) sonst klappt das nicht. Gilt generell für alle Dienste die mDNS basierend sind.
Ja, im Prinzip ... EdgeOS bringt aber nen mdns reflector und repeater praktischer Weise schon mit. Etwas, was ich von Mikrotik eigentlich auch erwarten würde. Wobei hier ja die Docker-Optionen in Zukunft evtl. etwas Linderung schafft. Mag ja sein, dass so ein "Endkunden-Problem" bei Mikrotik nicht ganz oben auf der Prio-Liste steht Das Problem ist auch nciht, dass ich die nicht über die vLAN-Grenzen hinweg sehe. Wenn ich aber die FW zwischen den vLANs aktiviere sehe ich sie zwar noch kann aber trotz der freigebenen UDP-Ports nichts mehr abspielen. Und irgendwo hatte ich auch den Eindruck, dass macht nen Unterschied ob LAN oder Wifi.
Wobei der Wifi-Trunk am Router direkt hängt und der LAN-Trunk am Mikrotik.
Das ist aber eher ne Petitesse, die schaue ich mir mal irgendwann genauer an. Liegt vermutlich an meinem falschen "Firewall-Verständnis". Wichtig war mir erstmal, dass da ein wenig Ruhe ins Setup kommt. Ich ergänze und tausch ja auch am anderen Ende laufend noch Clients aus.
Ich werde mich mal am Chip basierten Forwarding versuchen auf einem CRS.
Das klingt spannend. Ich gehe schon davon aus, dass - zumindest der CRS aus der 300-Serie - da deutlich mehr auf dem "Chip" hat. Mikrotik bestätigt das mMn. auch hier im aktuellen Video. Da werden die verschiedenen Optionen und Möglichkeiten der HW noch etwas aufgedröselt (auch wenn ich nicht alles verstehe
)https://www.youtube.com/watch?v=395ThUzwISI
EdgeOS bringt aber nen mdns reflector und repeater praktischer Weise schon mit.
Perfekt ! Damit ist das dann einfach zu lösen.Ist auch klar, denn da werkelt ein Linux im Hintergrund:
Netzwerk Management Server mit Raspberry Pi
kann aber trotz der freigebenen UDP-Ports nichts mehr abspielen.
Welche Ports gibst du denn frei und für welchen Dienst bzw. Protokoll ??Bedenke das das immer abhängig ist von den Ports die das finale Protokoll verwendet. Wenn das Sztreaming per RTP usw. ist werden dort z.B. dann dynmaische Ports benutzt so das es mit einem Port nicht erledigt ist sondenr u.U. mit einem ganzen Block. Wireshark ist hier wie immer dein bester Freund !
Welche Ports gibst du denn frei und für welchen Dienst bzw. Protokoll ??
Da muss ich gerade passen, sonst hätte ich das schon vermerkt. Auf jeden Fall "udp" - der Rest war aus meinen Screenshots nicht erkennbar. Habe ja "tabula-rasa" den Kram erstmal gelöscht um Wireguard zum Laufen zu bringen.Und das mit den "weiteren Ports" ist ein wirklich guter Tipp - weil ich das auf keinen Fall berücksichtigt habe!
Wie gesagt. Das mache ich nochmal in Ruhe und ggfs. auch in einem eigenen Thread, sollte ich da nicht weiterkommen.
Veilen Dank
weils ja auch über Performance ging:
Was sollen uns diese kryptischen Zahlen sagen ?! Version 66.0 auf Version 33.0 ? IP Netz .33.0 auf .99.0 ?? 🤔
Hast Recht - habs gelöscht
Zitat von @Visucius:
Dafür brauchst du ein Bonjour Gateway aka mDNS Forwarding (Link Local Multicast) sonst klappt das nicht. Gilt generell für alle Dienste die mDNS basierend sind.
Ja, im Prinzip ... EdgeOS bringt aber nen mdns reflector und repeater praktischer Weise schon mit. Etwas, was ich von Mikrotik eigentlich auch erwarten würde. Wobei hier ja die Docker-Optionen in Zukunft evtl. etwas Linderung schafft. Mag ja sein, dass so ein "Endkunden-Problem" bei Mikrotik nicht ganz oben auf der Prio-Liste steht Hier findet ihr auch eine Lösung zum mDNS Repeating direkt auf einem MIkrotik Router
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86)
Grüße Uwe
