9
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 465735
Url: https://administrator.de/contentid/465735
Ausgedruckt am: 05.11.2024 um 16: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...
Also die Fritzbox ist als Bridgemode von meinem ISP gesetzt wurden auf anfrage von mir. Hab FTTH als Anschluss. Da aber gleichzeitig auch Telefon auf einem Vlan mitübertragen wird. Telefon über die Fritzbox und Internet wird über die Bridge gemacht. Zugangsdaten musste ich im MT eingeben.
So und nun warum ich die Fritzbox über eine zweite Lanverbindung angeschlossen habe. Im Bridgemode ist das Webinterface auf Lan 4 nicht erreichbar. Über die anderen Lanports 2 und 3 ist es jedenfalls erreichbar. Hab ich mit einem Laptop direkt getestet mit statischer Ip und per DHCP. Ging halt beides nicht.
Das mit dem NAT hatte ich irgendwo mal gelesen. Müsste ich sonst mal suchen gehen wo das stand. Naja jedenfalls über den zweiten Anschluss hab ich Verbdindung zur FB. Ich sehe auch in den Logs der oben genannten FW Regel das er auf Port 1012 und 49000 zugreifen möchte von meinem Server.
Ich hoffe ich konnte was Licht ins Dunke bringen.
So und nun warum ich die Fritzbox über eine zweite Lanverbindung angeschlossen habe. Im Bridgemode ist das Webinterface auf Lan 4 nicht erreichbar. Über die anderen Lanports 2 und 3 ist es jedenfalls erreichbar. Hab ich mit einem Laptop direkt getestet mit statischer Ip und per DHCP. Ging halt beides nicht.
Das mit dem NAT hatte ich irgendwo mal gelesen. Müsste ich sonst mal suchen gehen wo das stand. Naja jedenfalls über den zweiten Anschluss hab ich Verbdindung zur FB. Ich sehe auch in den Logs der oben genannten FW Regel das er auf Port 1012 und 49000 zugreifen möchte von meinem Server.
Ich hoffe ich konnte was Licht ins Dunke bringen.
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
Also ich werde das mal mit den Capture probierem. Aber der Server sollte schon in meinem Internen Netz stehen. Hier läuft ja nicht nur die Kommunikation mit der Fritzbox. Darüber greife ich halt meine Telefondaten ab und löse einen Rundruf aus der als Ersatz für meine Haustürklingel dient.
Ich werde mich melden sobald ich den Capture habe.
Grüße
Ich werde mich melden sobald ich den Capture habe.
Grüße
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.2lG
areanod
Hallo,
also ich hab mal so geguckt gehabt. Ja mein KNX Server (Visualisierung) hat das richtige Standardgateway (10.10.9.254).
Über Torch hab ich mal auf dem Interface ether9 gelauscht (siehe Anhang). Also wenn ich das richtig sehe dann taucht dort Port 1012 und 49000 auf.
Statische Route hatte ich schon gesetzt in der FB.
Hab mal ein Rundruf ausgelöst und nebenbei das Capture der FB mitlaufen lassen. Gut was mir schonmal auffällt ist das er irgendwo immer noch die 8.8.8.8 drinstehen hat.
Okay also die NAT Regel hab ich mal rausgelöscht.
Wie und wo kann man sich den Header angucken?
Welche Inputchain wäre die richtige um den Verkehr zwischen dem MT und der FB zu erlauben?
Wie gesagt für mich ich das alles noch recht neu mit ipchains zu arbeiten.
Grüße
Jascha
also ich hab mal so geguckt gehabt. Ja mein KNX Server (Visualisierung) hat das richtige Standardgateway (10.10.9.254).
Über Torch hab ich mal auf dem Interface ether9 gelauscht (siehe Anhang). Also wenn ich das richtig sehe dann taucht dort Port 1012 und 49000 auf.
Statische Route hatte ich schon gesetzt in der FB.
Hab mal ein Rundruf ausgelöst und nebenbei das Capture der FB mitlaufen lassen. Gut was mir schonmal auffällt ist das er irgendwo immer noch die 8.8.8.8 drinstehen hat.
Okay also die NAT Regel hab ich mal rausgelöscht.
Wie und wo kann man sich den Header angucken?
Welche Inputchain wäre die richtige um den Verkehr zwischen dem MT und der FB zu erlauben?
Wie gesagt für mich ich das alles noch recht neu mit ipchains zu arbeiten.
Grüße
Jascha
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
Hi,
danke für deine kurze Erklärungen noch einmal für die Chains.
Also die Porst 49000 und 1012 sind tatsächlich für TR-64. Hierüber baut der KNX mit der IP 10.10.9.10 eine Verbdingung zu einem Webserver in der Fritz auf und steuert diesen dann mit Variablen. Was ich nach vielem rumsuche rausgefundne habe das nur jedes zweite Mal eine Anmeldung möglich war und der Rundruf auch auf der Fritzbox angekommen ist nur diese das alles nicht verarbeitet hat. Komisch den an der Fritz wurde bis auf die Umstellung auf BridgeMode sonst nichts verändert.
Naja kurzerhand mal die Fritzbox resetet und die Telefone neu eingerichten. Uns siehe da sie klingeln auf einmal wenn der Server den Befehl dazu senden. Warum und wieso bleibt nur zu raten da er bei der Umstellung einen Weg bekommen hat.
Aber ansonsten danke ich euch trotzdem allen die Versucht haben zu helfen und ich habe wieder etwas gelernt dabei.
Grüße und sonniges Wochenende
Jascha
danke für deine kurze Erklärungen noch einmal für die Chains.
Also die Porst 49000 und 1012 sind tatsächlich für TR-64. Hierüber baut der KNX mit der IP 10.10.9.10 eine Verbdingung zu einem Webserver in der Fritz auf und steuert diesen dann mit Variablen. Was ich nach vielem rumsuche rausgefundne habe das nur jedes zweite Mal eine Anmeldung möglich war und der Rundruf auch auf der Fritzbox angekommen ist nur diese das alles nicht verarbeitet hat. Komisch den an der Fritz wurde bis auf die Umstellung auf BridgeMode sonst nichts verändert.
Naja kurzerhand mal die Fritzbox resetet und die Telefone neu eingerichten. Uns siehe da sie klingeln auf einmal wenn der Server den Befehl dazu senden. Warum und wieso bleibt nur zu raten da er bei der Umstellung einen Weg bekommen hat.
Aber ansonsten danke ich euch trotzdem allen die Versucht haben zu helfen und ich habe wieder etwas gelernt dabei.
Grüße und sonniges Wochenende
Jascha
