toby97897
Goto Top

FritzBox 7490 hinter Mikrotik Routerboard NAT, kein VoiIP

Hallo zusammen,

ich bekomme in meinem Heimnetzwerk mein VoIP nicht zum laufen. Folgendes Setup liegt vor: Vigor 120 ADSL Modem das an einem Mikrotik Routerboard eine PPPoE Verbindung aufbaut und so als WAN Gateway dient. Am Mikrotik Routerboard hängt mein Heimnetz 192.168.0.0/24. Das Interface das sich im Heimnetz befindet hat die IP 192.168.0.254 und dient als Gateway für die Geräte im Heimnetz. Klappt soweit alles sehr gut auch die Firewall mit SRC -NAT im Mikrotik funktioniert.

Im Heimnetz befindet sich noch eine FritzBox 7490 im IP Client Modus. Die Box soll nichts anderes tun als eine VoIP Verbindung zu meinem Anbieter Inexio aufzubauen und dort die Telefonnummern zu registrieren. Vom Anbieter bekomme ich eine öffentliche IPv4, kein Dual Stack Lite oder ähnliches. Wenn ich nun die Zugangsdaten in der FritzBox eintrage meldet die FB in den Logs "Registrierung der Rufnummer nicht erfolgreich, Ursache: Gegenstelle antwortet nicht. Zeitüerschreitung".
Die FritzBox hat aber definitiv Internetzugang, die Prüfung auf Updates klappt und in der Weboberfläche leuchtet der Internetknopf grün.

Folgende Einstellungen wurden noch gesetzt:
- Portweiterleitung des Internet-Routers für Telefonie aktiv halten
- STUN, ich hab mal versucht einen STUN Server zu verwenden: stun.t-online.de Bin mir aber nicht sicher ob das mit fremden VoIP Providern klappt?

Aja wenn die FritzBox des Anbieters die mitgeliefert wird direkt als Router den Verbindungsaufbau macht klappt die VoIP Telefonie. Ich vermute also stark das es am NAT oder so liegt. Mir ist bewusst das ich wegen dem NAT Ports nach außen Öffnen muss.
Auf dem Routerbaord von Mikrotik wurde deswegen UDP Port 5060 und 5061 sowie 7077-7110 per DST NAT auf die IP der FritzBox gemappt. Die Ports habe ich von der AVM Hilfeseite.


Alle geöffneten Ports helfen aber nicht, die FritzBox mag die Nummer nicht registrieren... Bin langsam am verzweifeln! Muss ich in der Forward Chain des Mikrotik noch was freischalten?
Danke für die Hilfe.

Grüße Tobi

Content-ID: 317482

Url: https://administrator.de/contentid/317482

Ausgedruckt am: 21.11.2024 um 23:11 Uhr

aqui
aqui 11.10.2016, aktualisiert am 12.10.2016 um 00:02:56 Uhr
Goto Top
Vermutlich reicht wie immer die Range nicht, denn SIP und RTP nutzen dynamische Port Ranges so das weiterhin SIP geblockt ist.
Nimm testweise mal einen Softclient wie den Phoner:
http://www.phoner.de
und baue damit eine Verbindung zu Inexio auf.
Sehr wahrscheinlich wird das auch scheitern, oder ? Hier hast du aber jetzt die Option mit dem Wireshark mal zu checken warum indem du dir den SIP Sessionaufbau mal genau ansiehst.
Da du ein Modem hast kannst du auch mal den Wireshark zw. WAN Port und Modem einschleifen. Hier siehst du ganz genau was zum Provider rausgeht und vor allen Dingen mit welchen Ports das zurückkommt die dann bei dir in der Firewall hängenbleiben. Der Kabelhai ist also dein bester Freund hier !
Sieh dir zusätzlich in diesem Tutorial mal die weiterführenden Links an unter VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Dort findest du eine Menge hilfreiche Tips welche Port Ranges im Forwarding bei VoIP sinnvoll und hilfreich sind.
Diese Problematik tritt bei allen Firewalls auf die kein internes Application Gateway haben was diese Ports dynamisch öffnet.
Einen fremden STUN Server kannst du niemals verwenden, denn die Provider blocken logischerweise ihre internen Netze komplett gegen jeglichen Voice Traffic zu Mitbewerbern die eigene Voice Netze betreiben. Ausgenommen davon sind reine VoIP Hoster wie SIPgate usw. ohne eigene Infrastruktur.
Das kann also niemals klappen. Du musst wenn schon dann natürlich einen STUN Server von Inexio verwenden. Andere gehen de facto nicht.
Mit STUN kannst du dir dann das ganze Port Forwarding sparen. Das wäre eigentlich das Sinnvollste.
toby97897
toby97897 12.10.2016 um 15:59:23 Uhr
Goto Top
Ja ich vermute auch schwer die Ports. Den Wireshark werde ich mal einsetzen, was anderes bleibt mir nicht über...

Nein der Softclient funktioniert auch nicht.

Danke für die Link, leider habe ich da nirgends was von den angesprochenen Port Ranges gefunden. Hab ich Tomaten auf den Augen?
aqui
aqui 12.10.2016 um 16:57:18 Uhr
Goto Top
131026
131026 12.10.2016 aktualisiert um 17:08:03 Uhr
Goto Top
Der Mikrotik hat auch einen SIP-NAT-Helper an Bord, eventuell steht der auch in Konflikt mit den bestehenden Regeln.
http://wiki.mikrotik.com/wiki/Manual:IP/Services
Das also auch mal checken.

R.
Freezer2602
Freezer2602 12.10.2016 um 18:39:48 Uhr
Goto Top
Hey,

ich habe dazu kürzlich ein Video gesehen, allerdings nicht im Zusammenhang mit Mikrotik sondern mit Ubiquiti. Auch hier gab es viele "Probleme" mit der Fritzbox als VOIP Client. Ist hier ganz gut erklärt:
https://idomix.de/fritzbox-als-ip-client-telefonanlage-mit-unifi-securit ...

Eventuell ist das auch dein Problem.

Viele Grüße
Matze
toby97897
toby97897 13.10.2016 um 18:33:28 Uhr
Goto Top
Der SIP-NAT Helper wurde von mir deaktiviert. Jetzt hab ich mir bei Sipgate eine Nummer besorgt und stehe vor dem gleichen Problem. Selbst mit STUN Server... face-sad
Ich muss aber auch zugeben dass ich noch nicht zum Wireshark aufzeichnen gekommen bin, aber das wird der nächste Schritt.

Hier der Mikrotik export:

/ip firewall nat
add action=masquerade chain=srcnat comment="NAT Inexio WAN" \  
    out-interface-list=ListPPPoE_Intf
add action=dst-nat chain=dstnat comment="VoIP FritzBox" dst-port=5060 \  
    protocol=udp to-addresses=192.168.0.240 to-ports=5060
add action=dst-nat chain=dstnat dst-port=5004 protocol=udp to-addresses=\
    192.168.0.240 to-ports=5004
add action=dst-nat chain=dstnat dst-port=3478 protocol=udp to-addresses=\
    192.168.0.240 to-ports=3478
add action=dst-nat chain=dstnat dst-port=7078-7085 protocol=udp to-addresses=\
    192.168.0.240 to-ports=7078-7085


/ip firewall service-port
set sip disabled=yes


/ip firewall filter
add action=accept chain=forward dst-address=192.168.0.240 in-interface-list=\
    ListPPPoE_Intf
add action=accept chain=input comment="ALLOW all ICMP" protocol=icmp  
add action=accept chain=input comment=\
    "ACCEPT established and related packets on INPUT" connection-state=\  
    established,related
add action=drop chain=input comment="DROP all from WAN" in-interface-list=\  
    ListPPPoE_Intf
add action=accept chain=forward comment=\
    "Accept established and related packets on FORWARD" connection-state=\  
    established,related
add action=drop chain=forward comment="DROP all invalid packets" \  
    connection-state=invalid
add action=drop chain=forward comment="Drop all packets arriving at the WAN in\  
    terface and traversing the router towards the LAN, unless there's a explic\  
    it dst-nat rule matching it, i.e. a port forwarding from the router to an \
    inside host." connection-nat-state=!dstnat connection-state=new \  
    in-interface-list=ListPPPoE_Intf
aqui
aqui 14.10.2016 um 19:42:06 Uhr
Goto Top
toby97897
toby97897 15.10.2016 um 19:30:26 Uhr
Goto Top
Hm ich komme nicht weiter bei dem Problem. Was mich aber stutzig macht, ich deaktiviere alle Filterregel im Mirkrotik und trotzdem kann sich die Fritzbox nicht verbinden?!
Das müsste doch gehen oder?
aqui
aqui 15.10.2016 aktualisiert um 19:51:54 Uhr
Goto Top
Hast du denn auch NAT bzw. das Masquerading deaktiviert ??? Wohl kaum, denn sonst würdest du nicht ins Internet kommen !
Der Knackpunkt ist ja gerade das Masquerading bzw. NAT. Das lässt inbound Sessions ja nicht zu am WAN Port die keine aktive Outbound Session haben die dazu korrespondiert. Ein normales Verhalten bei NAT.
Eine inbound SIP Connection wird also so geblockt. Dafür reicht schon allein NAT.

Ohne einen Sniffer Trace kommst du nicht weiter ! Hast du das schon gemacht.
Schleife also den Kabelhai ein zw. MT und FB und checke ob dort überhaupt inbound SIP Calls reinkommen von außen.
Du stocherst do ohne das nur im Trüben und machst Trial and Error. Klar das das auf die Dauer frustriert.
toby97897
toby97897 15.10.2016 um 20:03:08 Uhr
Goto Top
Ja stimmt da hast du Recht. Danke sehr anschaulich erklärt, ich verstehe nun das die Filter nichts helfen...

Einmal habe ich versucht den Mikrotik Port an dem das Modem hängt an einen anderen Port rauszuspiegeln und dann mit dem Wireshark aufzuzeichnen. Klappt auch aber ich konnte nicht direkt einen SIP Verbindungsaufbau erkennen. Möglich das die FritzBox neu gestartet werden muss.

Grundsätzlich sollte der Modem Port aber der richtige für das Mirroring sein oder?
aqui
aqui 16.10.2016 um 12:15:31 Uhr
Goto Top
und dann mit dem Wireshark aufzuzeichnen. Klappt auch aber ich konnte nicht direkt einen SIP Verbindungsaufbau erkennen.
Oooops....das wäre aber sehr komisch !! Das würde dann im Endeffekt bedeuten das da gar kein SIP und damit überhaupt keine telefonie ankommt.
Das kann aber gar nicht sein...eigentlich.
Das Modem ist ja ein reiner, passiver Medienwandler macht also kein Routing oder irgendwas. Das ganze PPPoE Handling macht ja dein MT.
Das aber ist dann geneua der Punkt !!
Bedenke das alle Pakete dann PPPoE enkapsuliert sind. Du musst im Wireshark also in den PPPoE Header reinsehen was dort für ein IP Paket drin ist. Der TCP oder UDP Port sagt dir das dann.
Wireshark müsste das auch erkennen.
Du kannst wenn du einen Laptop hast dir mit einem preiswerten USB Ethernet Adapter eine Bridge bauen und den Wireshark daran betreiben. So brauchst du keine externen Mirrorports:
Netzwerk Management Server mit Raspberry Pi
Mit Mirrorport gehts natürlich auch....
Wenn du auf dem MT Port Forwarding eingerichtet hast für SIP (TCP 5060) dann sollten aber auch inbound SIP Pakets im lokalen LAN zu sehen sein.
Du forwardest diese ja auf die interne FB IP. Testweise kannst du die FB mal abklemmen und einen Laptop dort anklemmen mit Wireshark und dem Phoner Softclient.
Dann rufst du von außen mal an und checkst ob am LAN Port dort eingehende SIP Pakets kommen.
SIP musst du ersmal sicher forwarden, denn das ist der Call Aufbau. Wenigstens klingelt es dann am Telefon.
toby97897
toby97897 16.10.2016 aktualisiert um 15:59:21 Uhr
Goto Top
Jetzt versuche ich mich am Phoner Lite von meinem Windows 7 Rechner aus. Ich sehe im Wireshark das das STUN Protokoll wohl erfolgreich ist.

STUN 130 Binding Success Response MAPPED-ADDRESS: <WANIP>:5060 XOR-MAPPED-ADDRESS: <IP>:5060

Trotzdem zeigt mir der PhonerLite "sipgate, nicht registriert an <REQUEST TIMEOUT>"

Was aber sehr verwunderlich ist, setze ich den filter "sip" erscheint kein einziger Eintrag im Wireshark?! Anmerkung, es wird der Verkehr des Mikrotik Ports gespiegelt in dem mein Heimnetz und somit der PhonerLite hängt.
131026
131026 16.10.2016 aktualisiert um 18:11:31 Uhr
Goto Top
Da ist ein Komplett-Reset des Mikrotik angesagt, wenn schon das nicht hin haut.
Was aber sehr verwunderlich ist, setze ich den filter "sip" erscheint kein einziger Eintrag im Wireshark?!
Normal wenn nichts zurück kommt.
toby97897
toby97897 17.10.2016 um 18:47:08 Uhr
Goto Top
So nun hab ich nochmal weiter geforscht und den StarTrinity SIP Tester ausgegraben. Mit diesem Tool kann ich auf einem PC im lokalen Netz(wo auch die FritzBox hängt) mich per sipgate registrieren! Und oh Wunder ich sehe auch SIP Pakete im Wireshark.
Status: 200 OK (1 binding)

Warum sehe ich von der FritzBox keine Versuche eine SIP Verbindung aufzubauen?! Ist was mit dem IP Client Modus im argen?

Übrigens, bin nun auf den MirkroTik Packet Sniffer umgestiegen, der tut auch recht schön!

@131026:
Warum sollte ein Reset des Mikrotik helfen? Das würde mich sehr überraschen...
131026
131026 17.10.2016 aktualisiert um 18:50:32 Uhr
Goto Top
Zitat von @toby97897:
@131026:
Warum sollte ein Reset des Mikrotik helfen? Das würde mich sehr überraschen...
Bei dem kann es durchaus zu Inkonsistenzen kommen wenn man soviel rum spielt. Wenn ein SIP-Register mit komplett offener FW und Source-NAT mit dem Phoner nicht läuft kann nur was mit der Config am Mikrotik im argen liegen.
Ich vermute unter Umständen eine falsche MTU auf dem PPPoE Interface.
toby97897
toby97897 17.10.2016 aktualisiert um 19:54:24 Uhr
Goto Top
Hm das mit der MTU hatte ich auch schon mal in Erwägung gezogen. Mein PPPoE zeigt eine MTU von 1480 an. Mit einer Mangle Rule wird die TCP MSS angepasst damit sie in das PPPoE Paket passt:

chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp 
      out-interface-list=ListPPPoE_Intf tcp-mss=1441-65535 log=no log-prefix=""   

Oh shit das wird aber nicht für UDP gemacht, hier könnte wohl der Hund begraben liegen...?


Hm für UDP wird das wohl nicht gebraucht sagt mir Tante Google.

Mit Wireshark sehe ich das die SIP Register Befehle des PhonerLite den lokalen PC verlassen aber mehr auch nicht. Es kommt definitiv keine Antwort zurück. Anscheinend kommen Sie aber nicht mal am PPPoE/WAN Interface des Mikrotik an denn das überwache ich auch mit dem Wireshark.

19:37:34,015: T: 217.10.79.9:5060 (UDP)
REGISTER sip:sipgate.de SIP/2.0

Das kann ich mir aber noch weniger erklären... Was kann meine UDP Pakete kaputt machen? Hab auch kurzzeitig mal alle Filterregeln ausgeschaltet.
131026
131026 18.10.2016 um 08:16:11 Uhr
Goto Top
Hier klappt das ohne Probleme. Cleane Config nur SRC NAT.
toby97897
toby97897 24.10.2016 um 21:50:49 Uhr
Goto Top
So ich hab das Ganze nun mit einem parallelen IPv6 Subnetz gelöst. Das wird nur für VoIP verwendet, ohne NAT keine Probleme face-smile