[Frage] Portfreischaltungen RTP-Ports, Rätsel über Rästel

schlorky

Neuer User
Mitglied seit
5 Apr 2014
Beiträge
32
Punkte für Reaktionen
0
Punkte
0
Hallo Zusammen,

ich versuche gerade VoIP zu konfigurieren. Es sieht nicht so schlecht aus, aber vor allem bzgl. der RTP-Ports stochere ich noch voll im Nebel.

Was habe ich soweit:

Modem ---[öffentl. IP-Adresse]--- Router/Firewall (pfSense) ---[RFC1918-IP-Adresse]--- Fritzbox Fon 5050 ----- analoges Fon

Das ganze an einem Telekom-DSL-16000-Anschluß.

  • Ich habe mir eine sipgate-Rufnummer zugelegt und in der FritzBox konfiguriert.
  • Sipgate zeigt mir die Fritzbox als registriert an, die Fritzbox zeigt an, daß die Rufnummer registriert ist.
  • Ich kann rein und raus telefonieren.
  • Sipgate zeigt die Liste der Telefonate an, die Fritzbox ebenfalls.
  • Ich habe soweit ich das feststellen konnte akzeptable Tonqualität (das analoge Telefon ist ein älteres Siemens mit mieser Tonqualität, insofern ist die Beurteilung erschwert).

Alles scheint soweit ok.

Jetzt kommen die Unsicherheiten. Vielleicht kann mir hier jemand zu mehr Verständnis helfen:

Der ausgehende Port 5060 der Fritzbox ist in der Firewall als static deklariert (wird also durch pfSense beim NAT nicht geändert).

Ich habe nach einigem Experimentieren in der Firewall eine Port-Weiterleitung der Ports 5060/5061 sowie 7078-7109 auf die Fritzbox konfiguriert. Welche davon brauche ich wirklich?

Soweit ich herausgefunden habe, verwendet die Fritzbox die Ports 7078-7109 für bis zu 16 Sessions für RTP. Aber mein Firewall-Log zeigt mir diverse geblockte UDP-Pakete an im zeitlichen Zusammenhang zu Telefonaten an. Was ist da los?

Wie finde ich heraus, welche Ports für RTP noch benötigt werden? Egal wo ich suche finde ich da völlig unterschiedliche Angaben. Ich habe kein Problem mit Port-Weiterleitungen und Freigaben auf der Firewall, aber ich kann ja nicht alle Ports > 1023 auf die FritzBox mappen ...

Dann habe ich entgegen der Empfehlung bei sipgate in der Fritzbox einen STUN-Server konfiguriert. Davor hatte ich "one-way-audio" (ins lokale Netz eingehende Tonsignal hat gefehlt), danach ging es in beiden Richtungen. Hat die Verwendung eines STUN-Servers wiederum Einfluß darauf welche Port-Weiterleitungen ich brauche?

Sorry, wenn die Fragen alle etwas wirr sind, aber mir fehlen hier offenbar einfach noch Grundlagen.
 
Hallo

Eigentlich brauchst du TCP/UDP 5060 und für RTP UDP 7078+32, also bis 7110.
Probier mal.

Aus der F!B 7360SL

/var/flash/voip.cfg
Code:
voipcfg {
        dnsport = 7077;
        rtpport_start = 7078;
        sip_srcport = 5060;
 ...

/var/flash/ar7.cfg
Code:
        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";
 ...
 
Zuletzt bearbeitet:
Hallo koyaanisqatsi,

danke, das hilft! Die geblockten Ports auf der Firewall waren die auf der Außenseite. Bei weiteren Testtelefonaten habe ich jetzt gesehen, daß seitens Fritzbox die Ports 7078 (eingehend) und 7079 (ausgehend) genutzt wurden. Auf der WAN-Seite sind es ganz andere Ports. Ich muß also den Zugriff durch die Fritzbox auf beliebige UDP-Ports in der Firewaall freigeben, eingehend reichen die Ports ab 7078.

Außerdem müssen alle Ports static sein, d.h. die Firewall darf die Ports nicht ummappen. Damit haben meine Tests jetzt einwandfrei auch ohne STUN geklappt.

Jetzt bin ich glücklich. :)
 
Hallo, ich habe ein ähnliches Problem und blicke irgendwie gar nicht durch. Habe einen Technicolor-Router vor der FB (der selbst einen VOIP Anschluss verwaltet) und die FB dahinter, die drei 1&1 VOIP Nummern verwaltet. Da der Technicolor selbst VOIP macht, habe ich in der FB die Konfiguration angepasst:

Code:
voipcfg {
        dnsport = 7077;
        rtpport_start = 9078;
        sip_srcport = 5061;
...


Code:
voip_forwardrules = "udp 0.0.0.0:5061 0.0.0.0:5061",
                            "tcp 0.0.0.0:5061 0.0.0.0:5061",
                            "udp 0.0.0.0:9078+32 0.0.0.0:9078";

Somit, gehen sich die beiden Router aus dem Weg, und die Signalisierung von Anrufen funktioniert zu 100%! Auch ausgehende Anrufe+Gespräche funktioneren zu 100%. Allerdings eben nicht der Gesprächsaufbau bei eingehenden Anrufen.
Meine Paketmitschnitte zeigen, dass die FB korrekt kommuniziert, auch mit dem 1und1 STUN Server, und dieser jeweils VOR dem Gesprächsaufabau kontaktiert wird. (Siehe folgende Bilder).

Auf dem Technicolor habe ich ein Portforwarding eingerichtet, dass die jeweiligen Custom VOIP Ports auf die FB weiterleitet. Eigentlich sollte die FB damit komplett unabhängig vom Technicolor Router funktionieren.

104175 104176 104177
[Edit Novize. Bilder gemäß der Forumsregeln auf Vorschau geschrumpft]
Allerdings funktioniert bei mir alles sehr sporadisch. Richte ich auf dem dem Technicolor ein statisches Portforwarding auf die Fritzbox von

Code:
Technicolor 9078:9109 -> FB 9078:9109

ein, dann klappt der Aufbau nicht. Wenn ich das Port Forwarding allerdings komplett auf den Port 9078 umbiege, dann klappt es zumindest gefühlt jedes
2te Mal:
Code:
Technicolor 9078:9109 -> FB 9078

Mir scheint, die FB baut jedes 2te ankommene Gespräch über einen anderen RTP Port auf, z.B. 9082. Manchmal klappt dies, manchmal bekomme ich dann wieder ICMP Pakete, dass Port 9078 nicht erreichbar ist. Usw. Alles sehr verwurmt, obwohl ich eigentlich beide router sauber voneinander getrennt habe. Auch zeigen die FB Settings

Code:
voip_forwardrules = "...
                            "udp 0.0.0.0:9078+32 0.0.0.0:9078";

dass eh aller eingehender Verkehr auf den Port 9078 umgebogen wird in der FB.

Vielleicht sieht jemand einen Fehler den ich gemacht habe. Aussdem wundert mich, dass die FB bei jedem Gesprächsaufbau den STUN Server kontaktiert. Auch wenn die Auflösung hier korrekt aussieht, bauen eingehende Anrufe nicht unbedingt Gespräche auf dem per STUN sichtbaren Port auf.
 
Zuletzt bearbeitet von einem Moderator:
Bist Du Dir sicher, dass der Technicolor auch wirklich Port-Ranges kann; was passiert beispielsweise, wenn Du für die ersten acht RTP-Ports jeweils eine Weiterleitung anlegst?
 
Bist Du Dir sicher, dass der Technicolor auch wirklich Port-Ranges kann; was passiert beispielsweise, wenn Du für die ersten acht RTP-Ports jeweils eine Weiterleitung anlegst?

Der Technicolor zeigt mir zumindest genau diese Schreibweise an. Wenn ich einen Range mit 9078-9109 angebe, zeigt er mir den Warnhinweis, dass es 9078:9109 heißen muss. Außerdem habe ich genau deinen Ratschlag schon einmal befolgt, und alle Postweiterleitungen einzeln und nicht als Range angegeben. Und als Dritten Versuch habe ich die FB beim Technicolor in die DMZ geschoben. Laut Technicolor Handbuch, sollten somit alle WAN Pakete die FB auch erreichen und keine Firewall auf dem Technicolor passieren. Deshalb verstehe ich nicht, warum die FB bei jedem 2ten Mal per ICMP eine Nicherreichbarkeit des jeweiligen Ports (für RTP) anzeigt.

Ich kann den Technicolor als Fehlerquele nicht ganz ausschliessen, aber ich habe beim Forwarding eigentlich schon alle Möglichkeiten durchgespielt. In der FB, werden laut Original Config eh der ganze Portrange für VOIP auf eine Adresse geforwarded. ennt jemand den Sinn, oder warum das in der FB intern so gehandhabt wird?

Code:
"udp 0.0.0.0:9078+32 0.0.0.0:9078";
 
Ich wüsste auch nicht, was jetzt noch schief ist. Daher ein Workaround: 1&1 erlaubt Telefonie auch über IPv6. Dadurch brauchst Du keine Port-Forwardings oder Modifikationen in der voipcfg. Die FRITZ!Box öffnet sich selbst die Ports in der Firewall des Technicolor (wenn der denn überhaupt eine Firewall hat). FRITZ!Box → Web-Oberfläche → Telefonie → Eigene Rufnummern → (Rufnummern) 1&1 Internet (Taste Bearbeiten) → Internettelefonie-Anbieter kontaktieren: nur via IPv6.
 
Der Technicolor hat eine Firewall. Einen Versuch wäre es wert, aber leider lässt mich der Technicolor kaum was einstellen.
 
Ja, bei den Teilen ist manchmal (nur) NAT die Firewall. Und weil bei IPv6 kein NAT, keine Firewall. Aber mit IPv6 dürftest Du im Technicolor gar nichts einstellen müssen, weil sich die FRITZ!Box um alles kümmern sollte.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.