Erreichbarkeit Fritzbox (BridgeMode) über Mikrotik
Hallöchen,
so ich habe da mal wieder eine Frage bzw. benötige ich wieder einmal eure Hilfe. Für mich ist die Lernkurve von Fritzbox zu Mikrotik schon recht steil aber es wird langsam.
Also folgendes Problem ist vorhanden. Ich habe einen KNX Server der auf die Fritzboxtelefoniedaten zugreifen möchte über Port 1012 und 49000.
Also mit der Fritzbox hat vorher alles wunderbar geklappt nur jetzt macht sich alles ein wenig schwer.
Ich habe die Fritzbox in den Bridgemode (Lanport 4) versetzen lassen und der MT macht das komplette Routing über pppoe an Ether 1 am MT. Mein Lan ist am Ether 10 angeschlossen. Zusätzlich habe ich Fritzbox über Lanport 3 (192.168.178.1) mit dem Ether 9 am MT angeschlossen und dem Interface die IP 192.168.178.2 zugewiesen.
In der Firewall habe ich folgende Regel gesetzt:
Ich kann die Fritzbox aufrufen und auch die Seite http://192.168.178.1:49000/tr64desc.xml funktionier aus dem Lan raus.
Nur scheint aber irgendwas noch nicht ganz zu klappen da mein KNX Server aus irgendeinem Grund keinen Rundruf starten möchte was mit der Fritzbox noch ohne weiteres machbar war.
Könnte mir jemand dabei helfen den Fehler zu finden oder wie ich das Problem weiter eingrenzen kann?
Grüße
Jascha
so ich habe da mal wieder eine Frage bzw. benötige ich wieder einmal eure Hilfe. Für mich ist die Lernkurve von Fritzbox zu Mikrotik schon recht steil aber es wird langsam.
Also folgendes Problem ist vorhanden. Ich habe einen KNX Server der auf die Fritzboxtelefoniedaten zugreifen möchte über Port 1012 und 49000.
Also mit der Fritzbox hat vorher alles wunderbar geklappt nur jetzt macht sich alles ein wenig schwer.
Ich habe die Fritzbox in den Bridgemode (Lanport 4) versetzen lassen und der MT macht das komplette Routing über pppoe an Ether 1 am MT. Mein Lan ist am Ether 10 angeschlossen. Zusätzlich habe ich Fritzbox über Lanport 3 (192.168.178.1) mit dem Ether 9 am MT angeschlossen und dem Interface die IP 192.168.178.2 zugewiesen.
In der Firewall habe ich folgende Regel gesetzt:
/ip firewall filter
add action=accept chain=forward comment="accept LAN->cable modem" dst-address=192.168.178.1 in-interface=bridge1 out-interface=ether9 src-address=10.10.9.0/24
/ip firewall nat
add action=masquerade chain=srcnat comment="masquerade LAN->cable modem" dst-address=192.168.178.1 out-interface=ether9 src-address=10.10.9.0/24
Ich kann die Fritzbox aufrufen und auch die Seite http://192.168.178.1:49000/tr64desc.xml funktionier aus dem Lan raus.
Nur scheint aber irgendwas noch nicht ganz zu klappen da mein KNX Server aus irgendeinem Grund keinen Rundruf starten möchte was mit der Fritzbox noch ohne weiteres machbar war.
Könnte mir jemand dabei helfen den Fehler zu finden oder wie ich das Problem weiter eingrenzen kann?
Grüße
Jascha
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 465735
Url: https://administrator.de/contentid/465735
Ausgedruckt am: 23.11.2024 um 10:11 Uhr
9 Kommentare
Neuester Kommentar
Was etwas unverständlich ist warum du die FritzBox über eine 2te Schnittstelle kontaktierst und nicht direkt über die mit der sie am MT angeschlossen ist.
Das zweite Mysterium ist die Frage warum du sinnloserweise NAT auf diesem 2en Port machst was ja gar nicht nötig ist.
Wenn die FritzBox also nur als reines Modem arbeitet wäre es so oder so sinnlos, da dann alle IP basierten Funktione deaktiviert sind.
So bleibt der Verdacht das du sie eben nicht als Modem benutzt sondern doch wieder als Router Kaskade, denn "Rundruf" lässt ja schliessen das sie dennoch als Telefonanlage benutzt wird was dann impliziert das sie doch weiter als Router arbeitet.
Etwas verwirrend das ganze Konstrukt weil man es nicht wirklich versteht...
Das zweite Mysterium ist die Frage warum du sinnloserweise NAT auf diesem 2en Port machst was ja gar nicht nötig ist.
Wenn die FritzBox also nur als reines Modem arbeitet wäre es so oder so sinnlos, da dann alle IP basierten Funktione deaktiviert sind.
So bleibt der Verdacht das du sie eben nicht als Modem benutzt sondern doch wieder als Router Kaskade, denn "Rundruf" lässt ja schliessen das sie dennoch als Telefonanlage benutzt wird was dann impliziert das sie doch weiter als Router arbeitet.
Etwas verwirrend das ganze Konstrukt weil man es nicht wirklich versteht...
Wenn @aqui: schon da ist, traut man sich ja kaum noch herumzustümpern... LG
Hier ist es, wie vom TO beschrieben. Man kommt eben nicht von der gebridgten Schnittstelle auf die weiter vorhandenen Funktionen der Büchsen, die ja auch ihren eigenen IP-Range behalten. Eben kein Modem... Anders, als skyacer das angedacht hat, wird das kaum gehen, denn das einfache setzen einer Route geht ja eben nicht, da über LAN4 nicht ansprechbar.
Hast du keine Möglichkeit, den Server über eine 2. Leitung direkt mit der FB zu verbinden?
Ich kenne mich mit dem Mikrotik Null aus (Schande...), aber im Prinzip musst du jetzt checken, ob evtl. die Antworten geblockt werden. "Er versucht, sich zu verbinden" ist gut. Aber dann?
Allow Regel TCP und UDP für beide Interfaces zu und von FB gesetzt? (Nur FB!)
Eher theoretische Frage (evtl. Quatsch), aber was passierte denn, wenn MT und FB im selben Range wären? Akso FB 192.168.179.1 und MT 192.168.179.2 ? Und "Dein-Leben-wird-so-einfach-Server" 192.168.179.3? Sollte gehen? Oder vernebelt mir der Wetterauer Apfel grad das Hirn?
Aqui hat sicher eine Idee, wie man das mit dem Kabelhai diagnostiziert.
Buc
Hier ist es, wie vom TO beschrieben. Man kommt eben nicht von der gebridgten Schnittstelle auf die weiter vorhandenen Funktionen der Büchsen, die ja auch ihren eigenen IP-Range behalten. Eben kein Modem... Anders, als skyacer das angedacht hat, wird das kaum gehen, denn das einfache setzen einer Route geht ja eben nicht, da über LAN4 nicht ansprechbar.
Hast du keine Möglichkeit, den Server über eine 2. Leitung direkt mit der FB zu verbinden?
Ich kenne mich mit dem Mikrotik Null aus (Schande...), aber im Prinzip musst du jetzt checken, ob evtl. die Antworten geblockt werden. "Er versucht, sich zu verbinden" ist gut. Aber dann?
Allow Regel TCP und UDP für beide Interfaces zu und von FB gesetzt? (Nur FB!)
Eher theoretische Frage (evtl. Quatsch), aber was passierte denn, wenn MT und FB im selben Range wären? Akso FB 192.168.179.1 und MT 192.168.179.2 ? Und "Dein-Leben-wird-so-einfach-Server" 192.168.179.3? Sollte gehen? Oder vernebelt mir der Wetterauer Apfel grad das Hirn?
Aqui hat sicher eine Idee, wie man das mit dem Kabelhai diagnostiziert.
Buc
Moin,
Wenn man auf die Adminoberfläche der Fritte kommt, kann man da natürlich den eingebauten sniffer mithören lassen, ob und was vom KNX kommt.
lks
Hallo Skyacer,
Bei mir ist es genau umgekehrt zu the-buccaneer, ich beschäftige mich viel mit Mikrotik und nur wenig mit der Fritzbox
Zu allererst sei geschrieben, dass ich annehme, dass der Buskoppler (KNX) ein Standardgateway besitzt und dieses auch wirklich benutzen kann. Ein Kunde meinerseits (ein mittelständisches Unternehmen im Hausautomationsbereich) generiert mir den meisten Umsatz damit, dass ich deren Mitarbeitern erkläre, dass auch ein Buskoppler oder eine Visualisierung ein StandardGW braucht, wenn es denn in ein fremdes Netz will
Nachdem was du geschrieben hast zu deinem Setup würde ich zu allererst mal schauen ob der KNX Server Traffic vom Mikrotik über den von dir beschriebenen Port ETHER9 bekommt.
Die einfachste Variante das zu tun ist über das Tool TORCH (Menüpunkt TOOLS --> Torch). Einfach Interface auswählen, "Entry Timeout" auf etwas bedeuten höheres als die 3 Sekunden Standard einstellen und dann mal gucken ob KNX tatsächlich über den Port versucht eine Verbindung aufzubauen UND auch Antwort bekommt. Wenn keine Antwort zurückkommt: schau mal ob der Tik eine Firewall Regel hat, die Antworten von der FB überhaupt zulässt, in deinem Code Snippet hab ich nämlich nur eine ausgehende Forward Regel gesehen, keine eingehende.
Aus Unwissenheit nehme ich jetzt einfach mal an, dass das Telefonieprotokoll SIP/RTP ist? Wenn dass der Fall ist und die TCP/IP Kommunikation zwischen FB und KNX eigentlich funktioniert, würde ich mir mal die Header von den SIP-Paketen anschauen. Eventuell wird hier etwas umgeschrieben was nicht umgeschrieben werden sollte.
Abschließend die Frage, warum NATtest du anstatt zu routen?
Meines Wissens nach kann die FB IPv4 Routing für verschiedene Subnetze im LAN. Wenn man NAT (speziell mit SIP) vermeiden kann sollte man es vermeiden. In der Fritzbox eine statische Route unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> ipv4 einrichten. Wenn "ipv4" nicht sichtbar ist muss die Erweitere Ansicht aktiviert werden". Statische Route auf der Fritzbox würde dann (lt. deinen geposteten Settings heißen
lG
areanod
Bei mir ist es genau umgekehrt zu the-buccaneer, ich beschäftige mich viel mit Mikrotik und nur wenig mit der Fritzbox
Zu allererst sei geschrieben, dass ich annehme, dass der Buskoppler (KNX) ein Standardgateway besitzt und dieses auch wirklich benutzen kann. Ein Kunde meinerseits (ein mittelständisches Unternehmen im Hausautomationsbereich) generiert mir den meisten Umsatz damit, dass ich deren Mitarbeitern erkläre, dass auch ein Buskoppler oder eine Visualisierung ein StandardGW braucht, wenn es denn in ein fremdes Netz will
Nachdem was du geschrieben hast zu deinem Setup würde ich zu allererst mal schauen ob der KNX Server Traffic vom Mikrotik über den von dir beschriebenen Port ETHER9 bekommt.
Die einfachste Variante das zu tun ist über das Tool TORCH (Menüpunkt TOOLS --> Torch). Einfach Interface auswählen, "Entry Timeout" auf etwas bedeuten höheres als die 3 Sekunden Standard einstellen und dann mal gucken ob KNX tatsächlich über den Port versucht eine Verbindung aufzubauen UND auch Antwort bekommt. Wenn keine Antwort zurückkommt: schau mal ob der Tik eine Firewall Regel hat, die Antworten von der FB überhaupt zulässt, in deinem Code Snippet hab ich nämlich nur eine ausgehende Forward Regel gesehen, keine eingehende.
Aus Unwissenheit nehme ich jetzt einfach mal an, dass das Telefonieprotokoll SIP/RTP ist? Wenn dass der Fall ist und die TCP/IP Kommunikation zwischen FB und KNX eigentlich funktioniert, würde ich mir mal die Header von den SIP-Paketen anschauen. Eventuell wird hier etwas umgeschrieben was nicht umgeschrieben werden sollte.
Abschließend die Frage, warum NATtest du anstatt zu routen?
Meines Wissens nach kann die FB IPv4 Routing für verschiedene Subnetze im LAN. Wenn man NAT (speziell mit SIP) vermeiden kann sollte man es vermeiden. In der Fritzbox eine statische Route unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> ipv4 einrichten. Wenn "ipv4" nicht sichtbar ist muss die Erweitere Ansicht aktiviert werden". Statische Route auf der Fritzbox würde dann (lt. deinen geposteten Settings heißen
IPv4 Netzwerk 10.10.9.0
Subnetzmaske 255.255.255.0
Gateway 192.168.178.2
lG
areanod
Hallo,
Bitte bestätige mir nochmal, welche interne IP Adresse hat bei dir der KNX Server?
Nachdem mir die TCP-Ports 49000 und 1012 überhaupt nichts gesagt haben, habe ich eine kurze Recherche durchgeführt und bin zur Erkenntnis gekommen, dass diese Ports so wirklich gar nichts mit mir bekannten VoIP Protokollen zu tun hat. TCP/49000 ist ein (mir bis dato unbekannt gewesenes) Protokoll TR-064, welches (analog zu TR-069) Fernkonfiguration der Fritzbox ermöglicht. TCP/1012 scheint ein properitäres Protokoll zum Monitoring von Anrufen zu sein.
Was mir hier aber wirklich fehlt sind UDP Pakete die auf den Port 5060 auf der Fritzbox verbinden wollen. UDP/5060 ist der Default-Port über den SIP Verbindungsdaten zwischen Proxy und Clients austauscht und meines Wissens nach unterstützt die Fritzbox auf IP Basis nur SIP (bitte korrigiert mich wer, wenn ich hier falsch liege).
tl;dr:
Ich sehe in deinen Screenshots (sowohl vom Tik als auch in WIreshark) nichts, dass einen Registrierung, ein Keep-Alive oder einen Rufaufbau zeigen würde. Wenn der KNX-Server früher tatsächlich Telefonie nutzen konnte und jetzt nicht gibt's meiner Einschätzung nach eigentlich nur noch zwei Möglichkeiten:
1) Der KNX-Server versucht sich gar nicht mehr anzumelden; Gründe können mannigfaltigst sein, hier will ich nicht spekulieren.
2) Der Tik fängt die Pakete bereits auf der Bridge ab.
Ad Chains:
Faustregel ist, jeglicher Traffic der den Router nicht direkt betrifft sondern diesen als Zwischenstation benutzt (z.B. vom KNX Server zur FB) ist in der FW in der Chain "FORWARD".
Pakete die an eine am Router vergebene IP Adresse adressiert sind, sprich: Für den Router direkt gedacht sind (z.B. Winbox, Terminal, DNS,...) sind über die Chain "INPUT" definiert.
Pakete die den Router als URSPRUNGSGERÄT haben, d.h. eine DNS Anfrage vom Tik an die FB, werden über die Chain "OUTPUT" geregelt.
Das Standardverhalten ALLER Chains ist per Default "ACCEPT". Wenn du keine Firewallregeln definiert hast wird automatisch alles durchgelassen.
Ich empfehle explizit NICHTeinen Router (egal ob Tik oder was anderes) mit direkter Internetverbindung ohne Firewallregeln zu betreiben.
lG
Bitte bestätige mir nochmal, welche interne IP Adresse hat bei dir der KNX Server?
Nachdem mir die TCP-Ports 49000 und 1012 überhaupt nichts gesagt haben, habe ich eine kurze Recherche durchgeführt und bin zur Erkenntnis gekommen, dass diese Ports so wirklich gar nichts mit mir bekannten VoIP Protokollen zu tun hat. TCP/49000 ist ein (mir bis dato unbekannt gewesenes) Protokoll TR-064, welches (analog zu TR-069) Fernkonfiguration der Fritzbox ermöglicht. TCP/1012 scheint ein properitäres Protokoll zum Monitoring von Anrufen zu sein.
Was mir hier aber wirklich fehlt sind UDP Pakete die auf den Port 5060 auf der Fritzbox verbinden wollen. UDP/5060 ist der Default-Port über den SIP Verbindungsdaten zwischen Proxy und Clients austauscht und meines Wissens nach unterstützt die Fritzbox auf IP Basis nur SIP (bitte korrigiert mich wer, wenn ich hier falsch liege).
tl;dr:
Ich sehe in deinen Screenshots (sowohl vom Tik als auch in WIreshark) nichts, dass einen Registrierung, ein Keep-Alive oder einen Rufaufbau zeigen würde. Wenn der KNX-Server früher tatsächlich Telefonie nutzen konnte und jetzt nicht gibt's meiner Einschätzung nach eigentlich nur noch zwei Möglichkeiten:
1) Der KNX-Server versucht sich gar nicht mehr anzumelden; Gründe können mannigfaltigst sein, hier will ich nicht spekulieren.
2) Der Tik fängt die Pakete bereits auf der Bridge ab.
Ad Chains:
Faustregel ist, jeglicher Traffic der den Router nicht direkt betrifft sondern diesen als Zwischenstation benutzt (z.B. vom KNX Server zur FB) ist in der FW in der Chain "FORWARD".
Pakete die an eine am Router vergebene IP Adresse adressiert sind, sprich: Für den Router direkt gedacht sind (z.B. Winbox, Terminal, DNS,...) sind über die Chain "INPUT" definiert.
Pakete die den Router als URSPRUNGSGERÄT haben, d.h. eine DNS Anfrage vom Tik an die FB, werden über die Chain "OUTPUT" geregelt.
Das Standardverhalten ALLER Chains ist per Default "ACCEPT". Wenn du keine Firewallregeln definiert hast wird automatisch alles durchgelassen.
Ich empfehle explizit NICHTeinen Router (egal ob Tik oder was anderes) mit direkter Internetverbindung ohne Firewallregeln zu betreiben.
lG