Telekom VoIP kann mit manchen Telekom VoIP Anschlüssen nicht telefonieren
-
@hbauer
Wie war das mit dem "disable scrub", von dem du in einem anderen Thread schriebst?
https://forum.netgate.com/topic/114858/telekom-voip-von-manchen-anrufern-nicht-erreichbar -
da habe ich kein Kreuz.
-
Mit "disable scrub" funktioniert die Telefonie gar nicht.
Die "alten" zusätzlichen Port Forwards von @hbauer habe ich ausprobiert, das ändert leider nichts.
Und auch ganz ohne Forward spezieller Ports, nur mit Outbound NAT, geht es nicht besser (oder schlechter)...Komisch.
-
Wie wäre es auf der Firewall mit Packet Capture die VOIP Kommunikation und dann z. B. mit Wireshark
die Unterschiede zu klären? Hier scheint ein Problem mit SIP/RTP an der Gegenstelle (Fritzbox?) aufzutreten.Wie schon gesagt habe ich solche Probleme bisher nicht festgestellt und mußte meine ursprüngliche
VOIP Konfiguration auf pfSense/Fritzbox noch nie ändern. -
Bitte mal folgendes versuchen:
Bei der Fritz!Box die Rufnummer bearbeiten und bei Telefonie-Anbieter "anderer Anbieter" auswählen.
Es erscheinen neue Felder, das Feld "STUN-Server" leeren und speichern. -
STUN-Server leeren führt zu keinem anderen Ergebnis.
Ich habe nun mal tcpdump auf der pfSense laufen lassen, Port 5060. Vielleicht gibt das jemandem einen Hinweis, wo das Problem liegen könnte?
Ich habe TCPDUMP unmittelbar vor den Anrufversuchen gestartet und diese dann nach ein paar Sekunden jeweils wieder abgebrochen. Ergebnisse:Eingehender Anruf erfolgreich:
Eingehender Anruf nicht erfolgreich:
Wenn man mich fragt, kommt hier beim zweiten Anrufversuch nur ... Datenmüll? (fragmented IP protocol) an, das scheint nicht erkennbar was mit SIP zu tun zu haben. Die Pakete kommen auch nur bei solchen fehlgeschlagenen Anrufen. Wenn nichts passiert, habe ich nur "binding response" und hin und wieder 36 Byte Pakete von 5060 hier zu 5060 beim Telekom-Server (oder vice versa).
-
Die entfernte Fritzbox (es soll ja eine im Spiel sein) auf Werkseinstellungen rücksetzen und
die gesicherte Konfiguration aufspielen. Danach ist man möglicherweise schlauer. -
Also wenn das der Mitschnitt auf der pfsense zwischen pfsense und Telekom ist dann würde vermuten das die dahinterliegende Fritzbox noch garnicht im Spiel ist wenn diese fragmentierten Pakete ankommen. Ist aber nur eine Vermutung.
Vielleicht liegt das Problem auf dem Draytek Router
https://www.heise.de/forum/heise-online/News-Kommentare/VDSL-Router-fuer-PC-Einbau-mit-Modem-Option/Draytek-Router-nicht-fuer-VOIP-geeignet/posting-28797585/show/
vielleicht die mtu size? https://www.youtube.com/watch?v=6Whbg_KnumM
-
Man könnte auch an der Firmware des (Version Modem x) Vigor 130 schrauben. Was ist denn jetzt drauf?
Braucht VDSL100 eine andere als die jetzt verwendete?Da ich weder VDSL100 noch einen Vigor 130 im Einsatz habe, kann ich nur im Nebel stochern.
Andererseits wird es die oben genannte Kombination wohl noch öfter geben und es meldet
sich mal ein kompetenter Anwender zu Wort.Ich bin hier raus.
LG -
Zunächst einmal vielen Dank für Eure Hilfe und Euer Mitdenken!!!
@Gladius: Da die entfernte Fritzbox bei Anrufversuchen hier sogar eine Fehlermeldung bekommt (s.o.), habe ich die Anschlussinhaber mal gebeten, die bei Auftreten dieses Fehlers von AVM empfohlenen Schritte zur Problemlösung zu befolgen. Wobei es schon komisch wäre, wenn es an der entfernten Fritzbox läge, da ich dort zu Vodafone-Zeiten problemlos anrufen konnte.
Anderereits: Wenn die Fritzbox auf der anderen Seite nicht läuft, wird eine Telefonverbindung zur zugehörigen Sprachbox der Telekom problemlos aufgebaut.
@hbauer: Dass es am Vigor liegt, glaube ich nicht. In dem heise-Artikel steht u.a.
So lange sich an dem Verhalten nichts ändert, kann man Draytek Router für VOIP nicht empfehlen. Das gilt aber nur, wenn sie als Router betrieben werden. Wenn sie als Modem konfiguriert sind, sind sie eher nicht daran Schuld, wenn es Probleme mit VOIP gibt.Und das Vigor läuft hier ja als Modem, MTU 1492.
Ich habe an Firmwares für das Vigor versucht die 3.83 (aktuell) Modem 7 (läuft, allerdings zeigt das Vigor bei den DSL Diagnostics dort als Path-Mode "Interleave" an:
Mit der 3.83 Modem8 Firmware (wie hier empfohlen) gibt es den Path-Mode Fast:
Auch die 3.8.1.2 Modem7 habe ich versucht. Die bietet im Downstream den Path-Mode Fast, im Upstream Interleaved.
Telefontechnisch macht das alles keinen Unterschied.
-
Hallo,
meine Vermutung: der Port 5060 ist von Außen nicht erreichbar bzw. wird nicht auf die Fritz!Box weitergeleitet.
Daher funktioniert das Anrufen, aber nicht das angerufen werden.Zum Testen: https://www.sinologic.net/proyectos/checkSecurity/
-
Die Website verstehe ich nicht. Soll ich da meine IP eintragen? Mit der funktioniert es nicht, die Website sagt "Nothing has been received (CLOSED PORT OR SIP SERVER DON'T AVAILABLE?)".
Allerdings nochmal zur Vermeidung von Missverständnissen: Die allermeisten Anschlüsse kann ich anrufen, und ich kann von denen auch angerufen werden. Es sind nur (sehr) wenige Anschlüsse, bei denen es nicht klappt. Vorher, mit Vodafone, klappte es überall.
Nachtrag: Dieser Test sagt, dass Port 5060 TCP geschlossen, UDP aber "open/filtered" sei.
-
Ok, das Problem ist die MTU size, und zwar konkret und ausschließlich die in der pfSense eingestellte MTU size.
Das Setup hier sieht so aus:
Modem -(1)-> pfSense -(2)-> Switch -(3)-> Switch -(4)-> Fritzbox
(1) ist 1GBit Ethernet, MTU 1492 (pfSense: WAN)
(2) ist 20GBit Ethernet (2x 10GBase-T LAGG), MTU 9000 (pfSense: LAN)
(3) ist 10GBit Ethernet (1x 10GBase-T), Jumbo Frames enabled auf beiden Switches
(4) ist 1GBase-TWenn ich (2) auf MTU 1492 ändere, sind die sporadischen Probleme mit einigen Gegenstellen weg. Dafür habe ich im LAN keine Jumbo Frames mehr.
Ich habe versucht, die Fritte in ein separates VLAN zu stecken und für das separate VLAN eine kleinere MTU size anzugeben. Das klappt zwar in der pfSense GUI, ifconfig auf der Konsole zeigt aber, dass dennoch für das VLAN dieselbe MTU wie für die physikalische Schnittstelle verwendet wird.
Ich mache wg. der MTU size im VLAN mal einen neuen, englischen Thread auf.
-
@highc nimm mal die Modem 4, da sollte auch der upstream höher sein.
Gruß
pfadmin -
Ich teste gerade mal Modem4. Soweit sieht das nicht nach deutlich schnellerem Upstream aus:
3.8.1.2 Modem7:
3.8.3 Modem 4:
Übrigens hat auch hier eine testweise angeschlossene Fritzbox nur 30 Mbps Upstream gebracht.
Mal schauen, wie die Verbindungsstabilität mit der Modem 4 Firmware so ist.
-
Fastpath ist jetzt wieder aktiv...
-
Hallo zusammen,
ich würde das Thema gerne noch mal aufgreifen. Ich kämpfe auch seit einer Woche mit TELEKOM ALL-IP VDSL 50 Anschluss mit folgendem Aufbau:
DRAYTEK VIGOR 130 (Modem 7) > PFSENSE (aktuell FW) ->FritzBox (aktuelle FW / Nur Telefonie)
Wenn ich die im Internet gefundenen Anleitungen mir durchlese sind diese mehr als widersprüchlich (NAT ja oder nein ? / Scrub ja oder nein).
Wenn ich mir die Firewall LOGS anschaue und die Telekom VOIP Server (verschiedene IP´s) über den UDP Port 5060 kommen und direkt an die WAN Adresse der Pfsense anklopfen (dyn. Ports) muss meiner Meinung nach ein NAT erfolgen. Dabei spielt es doch meiner Meinung nach keine Rolle ob die FritzBox diese über die Outbound regel offen hält, wenn die VOIP Telekom Server mit verschiedenen IP´s anklopfen.
Eine Vollständige Erklärung mit einer funktionierenden Konfig habe ich leider noch nicht gefunden.
Die einzige Konfig die bei mir funktioniert (mir aber auch gleichzeitig Kopfweh bereitet ist diese) (Scrub ist aus)
Ohne diese NAT Regel kann ich keinen Ton auf beiden Seiten hören.
Hier das Firewall Protokoll wenn ich das Telefon annehme (kein Ton).
Das ist denke ich nicht die richtige Lösung oder ?
Für Anregungen wäre ich dankbar.
-
Hast Du denn die in meinen Screenshots und meiner Beschreibung abgebildete Config ausprobiert? Die funktioniert so hier mittlerweile.
-
Ja habe ich, sieht aber so aus das das mit Telekom nicht funktioniert. Wie geschrieben ohne NAT klingelt das Telefon, wenn ich abhebe kommt kein Ton (siehe Firewall Log, alle anderen Ports werden blockiert).
Ach ja, habe in einem Telekom Forum die Info gelesen Link TELEKOM, dass die VOIP Server aus dem IP Adressenband 217.0.0.0/32 kommen. Somit kann ich zumindest die IP (Source) eingrenzen.
-
Deine Outbound NAT Regel für die Fritzbox greift ja so auch gar nicht, aus der Anleitung: https://www.netgate.com/docs/pfsense/nat/static-port.html
Rules are processed from the top down and the first match is used. If the rule is below any other rule that can match the same traffic, then the new rule would never be used.
Und warum hast die automatischen Regeln überhaupt nochmal zu den Mappings hinzugefügt, im Hybrid Modus werden die doch von der pfSense selbst verwaltet. Also bitte nochmal gründlich die Anleitung, oder noch besser das pfSense Buch, lesen.
