137340
May 30, 2020
4013
6
0
Nur mit ALG Anmeldung aus dem Internet an LAN-Fritzbox
Liebe Fachleute,
ich beschäftige mich derzeit mit der Einrichtung VOIP im Heimnetz:
Konstruktion: Netcologne --> Vigor165 (Modem) --> Draytek Vigor 2960 (Router) --> Fritzbox als Telefonzentrale <--- IP-Telefone / Zoiper Softphone
Das heisst, auf der Fritzbox sollen sich die IP-Telefon-Clients anmelden. Und das klappt auch. IP-Telefonate sind problemlos möglich, z.B. die Zoiper-Softphone APP auf dem Iphone kann sich problemlos aus dem WAN auf der FB anmelden, Telefonate sind möglich.
Aber, und das ist es, was ich nicht verstehe: Eine Anmeldung aus dem WAN (z.B. mit Zoiper) an die FB - funktioniert nur, wenn ich im Vigor 2960 ALG aktiviere.
Es klappt nicht, wenn ich im Vigor ALG deaktiviere, stattdessen im Router die bekannten Portweiterleitungen (sip / rtp) auf die FB einrichte. Teilnehmer können dann zwar ganz normal anrufen, der integrierte Anrufbeantworter der FB springt auch an - aber wie geschrieben, eine Anmeldung von IP-Clients aus dem WAN ist nicht /(mehr) möglich. Es funktioniert nur eine Anmeldung von Clients im LAN.
Bitte helft mir auf die Sprünge: Wenn ich die Portweiterleitung 5060 im Vigor auf die FB einrichte - dann muss doch eine Anmeldung möglich sein? Warum klappt das nur mit aktiviertem ALG?
Der Hintergrund der Frage ist, dass vom ALG ja häufig abgeraten wird ("ALG vertut" sich). Obwohl es bei mir bislang anstandslos funktioniert.
Zusatzfrage: Ich habe gelesen, dass bei aktiven ALG das ALG selbst QoS für IP-Telefonie macht bzw. IP-Telefonie im Heimnetz priorisiert. Ist dem so? Denn dann müsste ich ja gar keine QoS-Regeln extra einrichten.
Ich danke Euch!
ich beschäftige mich derzeit mit der Einrichtung VOIP im Heimnetz:
Konstruktion: Netcologne --> Vigor165 (Modem) --> Draytek Vigor 2960 (Router) --> Fritzbox als Telefonzentrale <--- IP-Telefone / Zoiper Softphone
Das heisst, auf der Fritzbox sollen sich die IP-Telefon-Clients anmelden. Und das klappt auch. IP-Telefonate sind problemlos möglich, z.B. die Zoiper-Softphone APP auf dem Iphone kann sich problemlos aus dem WAN auf der FB anmelden, Telefonate sind möglich.
Aber, und das ist es, was ich nicht verstehe: Eine Anmeldung aus dem WAN (z.B. mit Zoiper) an die FB - funktioniert nur, wenn ich im Vigor 2960 ALG aktiviere.
Es klappt nicht, wenn ich im Vigor ALG deaktiviere, stattdessen im Router die bekannten Portweiterleitungen (sip / rtp) auf die FB einrichte. Teilnehmer können dann zwar ganz normal anrufen, der integrierte Anrufbeantworter der FB springt auch an - aber wie geschrieben, eine Anmeldung von IP-Clients aus dem WAN ist nicht /(mehr) möglich. Es funktioniert nur eine Anmeldung von Clients im LAN.
Bitte helft mir auf die Sprünge: Wenn ich die Portweiterleitung 5060 im Vigor auf die FB einrichte - dann muss doch eine Anmeldung möglich sein? Warum klappt das nur mit aktiviertem ALG?
Der Hintergrund der Frage ist, dass vom ALG ja häufig abgeraten wird ("ALG vertut" sich). Obwohl es bei mir bislang anstandslos funktioniert.
Zusatzfrage: Ich habe gelesen, dass bei aktiven ALG das ALG selbst QoS für IP-Telefonie macht bzw. IP-Telefonie im Heimnetz priorisiert. Ist dem so? Denn dann müsste ich ja gar keine QoS-Regeln extra einrichten.
Ich danke Euch!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 575893
Url: https://administrator.de/contentid/575893
Printed on: April 18, 2024 at 12:04 o'clock
6 Comments
Latest comment
Das Problem ist, dass in den SIP-Nachrichten die IP-Adresse auch eingetragen ist. Die NAT-Funktion eines Routers verändert nur die Quell-IP im IP-Header. Damit bleibt die IP auf Layer 7, also SIP, unverändert und eine private IP-Adresse. Die öffentliche IP ist hinter dem NAT nicht bekannt und kann daher nicht in die SIP-Nachrichten eingebaut werden. Dafür gibt es u.a. STUN.
Das SIP-ALG selbst versteht die SIP-Nachrichten und greift hier verändernd ein, weil dem Draytek ja seine eigene WAN-IP bekannt ist.
PS: Es ist grundsätzlich eine ganz schlechte Idee, SIP auf seiner eigenen Telefonanlage vom WAN aus zuzulassen. Zumindest nicht ohne VPN. Es gibt genug Scriptkiddies, die explizit danach Ausschau halten und irgendwie versuchen, dieses zu missbrauchen. Ich glaube AVM war selbst schonmal Opfer davon. Meine Session Border Controller sehen fast mehr Nachrichten solcher Scriptkiddies als welche für reale Telefonie.
Das SIP-ALG selbst versteht die SIP-Nachrichten und greift hier verändernd ein, weil dem Draytek ja seine eigene WAN-IP bekannt ist.
PS: Es ist grundsätzlich eine ganz schlechte Idee, SIP auf seiner eigenen Telefonanlage vom WAN aus zuzulassen. Zumindest nicht ohne VPN. Es gibt genug Scriptkiddies, die explizit danach Ausschau halten und irgendwie versuchen, dieses zu missbrauchen. Ich glaube AVM war selbst schonmal Opfer davon. Meine Session Border Controller sehen fast mehr Nachrichten solcher Scriptkiddies als welche für reale Telefonie.
eine Anmeldung von IP-Clients aus dem WAN ist nicht /(mehr) möglich.
Nur mal nebenbei: Das machst du vollkommen ungeschützt, also ohne VPN ? Sprich also sowohl deine SIP Daten als auch der RTP Voice Traffic geht dann vollkommen ungeschützt über das Internet ?Kollege @tikayevent hegt ja oben zu Recht auch schon diesen bösen Verdacht und hat alles zu solch einem Unsinn gesagt.
Schmeiss den Wireshark an und trace einen RTP Stream eines deiner Telefonate mit. Aus den Sniffer Daten machst du dann mit einem simplen Mausklick das komplette Telefonat hörbar. Sowas zu machen zeugt eher von laienhaftem IT Wissen und fahrlässigem Umgang mit sensiblen Daten...aber egal. Musst du ja wissen.
Was ebenso unverständlich ist ist dein Design. Genau, wie die FritzBox angeschlossen ist. Wenn die einfach nur VoIP Anlage ist, dann reicht es ja wenn sie einfach mit ihrem LAN Anschluss am internen Netz hängt. Default Router auf den Vigor und gut iss.
Bei dir ist nicht ganz klar ob du sie unsinnigerweise als Router Kaskade konfiguriert hast. Damit hättest du dann doppelts NAT was die Voice Problematik erheblich verschlimmert, denn RTP nutzt dynamische Ports die so ohne ein ALG nicht über die Firewall gehen. Wenn man einm ALG hat sollte man das auch tunlichst immer nutzen.
Der Fehler rührt aber vermutlich an deinem faschen Design mit der Kaskade.
Was der Unsinn zweier kaskadierter Router mit doppeltem NAT und doppelter Firewall so oder so soll erschliesst sich auch nicht wirklich. Sowas ist meist ein Performance Killer aber wie gesagt ob das so ist wird nicht ersichtlich aus deiner Schilderung. Es reicht die FB einfach nur "einbeinig" übers LAN anzzuklemmen ohne diese unsägliche Kaskade.
dass bei aktiven ALG das ALG selbst QoS für IP-Telefonie macht bzw. IP-Telefonie im Heimnetz priorisiert. Ist dem so?
Das ist unmöglich zu beantworten, denn sowas ist immer Hersteller proprietär. Jeder Hersteller macht da was er will.Um das zu verifizieren ob das so ist solltest du mal einen Wireshark Sniffer anklemmen und den RTP Flow bzw. SIP Traffic mitschneiden.
Dort kannst du dann genau sehen ob und wie der Traffic priorisiert ist. Siehe dazu auch hier:
Kaufberatung - Switches mit VoIP-Priorisierung
@aqui: Es ist keine Routerkaskade, die FB ist eine reine VOIP-Telefonzentrale im LAN, kein doppeltes NAT. Der Vigor 165 als reines Modem, der Draytek 2960 betreibt die Einwahl und ist der VPN-Server, die FB als LAN-Client.
@ tikayevent: Danke für die Erläuterung. Das erklärt meine Frage (und mir auch die Funktion von STUN).
@ beide: Ja, Ihr habt selbstverständlich recht, aus Sicherheitsgründen den SIP/VOIP nicht aus dem WAN zuzulassen, sondern nur per VPN. Mir ging es eher um das Verstehen, warum ALG überhaupt nötig ist/wäre. Und das führt mich zu der Aussage von aqui:
Denn es heisst häufig: "ALG am besten abschalten, die meisten VOIP-Probleme rühren aufgrund von ALG her, da ALG gerne mal die Ports verwechselt."
Heisst das, Du würdest beim VOIP-Client-Zugriff per VPN dennoch ALG aktivieren/aktiviert lassen (sofern es keine Probleme macht)? Oder wäre es hierbei eigentlich unnötig?
Zur Frage QoS: Ok, das werde ich mit Wireshark genauer analysieren.
Besten Dank schon einmal!
@ tikayevent: Danke für die Erläuterung. Das erklärt meine Frage (und mir auch die Funktion von STUN).
@ beide: Ja, Ihr habt selbstverständlich recht, aus Sicherheitsgründen den SIP/VOIP nicht aus dem WAN zuzulassen, sondern nur per VPN. Mir ging es eher um das Verstehen, warum ALG überhaupt nötig ist/wäre. Und das führt mich zu der Aussage von aqui:
Wenn man einm ALG hat sollte man das auch tunlichst immer nutzen.
Denn es heisst häufig: "ALG am besten abschalten, die meisten VOIP-Probleme rühren aufgrund von ALG her, da ALG gerne mal die Ports verwechselt."
Heisst das, Du würdest beim VOIP-Client-Zugriff per VPN dennoch ALG aktivieren/aktiviert lassen (sofern es keine Probleme macht)? Oder wäre es hierbei eigentlich unnötig?
Zur Frage QoS: Ok, das werde ich mit Wireshark genauer analysieren.
Besten Dank schon einmal!
Ein SBC ist einem ALG immer vorzuziehen. Das Problem ist einfach, dass viel zu viele SIP-Dialekte auf dem Markt sind und es da immer wieder zu Problemen kommt. Jeder Hersteller hat da so seine Eigenheiten, die am Ende dazu führen, dass es durch den gemeinsamen Nenner SIP irgendwie läuft, aber auch immer mit Problemen verbunden ist.
Manche Routerhersteller haben Vereinbarungen oder Partnerschaften mit Telefon(anlagen)herstellern, so dass hier das ALG angepasst wird, aber andere bleiben dann halt auf der Strecke. Ich glaube, eine der beliebtesten Macken am Markt ist hier das LANCOM SIP-ALG mit der BLF-Funktion von snom.
QoS sollte auch ohne ALG funktionieren, wenn beide Seiten z.B. DiffServ richtig beherrschen und konfiguriert haben. WAN-seitig ist es immer etwas schwieriger, da die Telekom es definitiv ignoriert und ich meine sogar entfernt. Wie NetCologne damit umgeht, keine Ahnung.
Manche Routerhersteller haben Vereinbarungen oder Partnerschaften mit Telefon(anlagen)herstellern, so dass hier das ALG angepasst wird, aber andere bleiben dann halt auf der Strecke. Ich glaube, eine der beliebtesten Macken am Markt ist hier das LANCOM SIP-ALG mit der BLF-Funktion von snom.
QoS sollte auch ohne ALG funktionieren, wenn beide Seiten z.B. DiffServ richtig beherrschen und konfiguriert haben. WAN-seitig ist es immer etwas schwieriger, da die Telekom es definitiv ignoriert und ich meine sogar entfernt. Wie NetCologne damit umgeht, keine Ahnung.
1da die Telekom es definitiv ignoriert und ich meine sogar entfernt.
Generell alle Provider machen das durch die Bank. Am heimischen Router ist sofort Schluss mit QoS. Ist auch verständlich und logisch aus Providersicht, denn würde man das nicht unterbinden könnte sich jeder nach Belieben einen Vorteil im Netz verschaffen. Sowas geht bei Providern durch die Bank wenn überhaupt nur für Business Kunden und dann nur gegen Geld.
Ja, bei Businessanschlüssen geht es, aber da garantiert auch keiner was. Unser Provider für die guten Leitungen bietet es kostenfrei im eigenen Netz mit an, ab dem Übergabepunkt an irgendein anderes Netz keine Versprechungen mehr.
Die DLAN Connect IP können es auch und das ist fies, weil hier die standardmäßige Flatrate nur für BE gilt. Für Low Loss und Los Delay hat man pro Monat 3GB frei und dann laufen die Euros durch.
Die Telekom scheint aber bei den Endkundenanschlüssen auch irgendwas zu haben, weil in der 1TR112 ist was in Richung QoS definiert.
Bei den heutigen Bandbreiten ist für Voice zum Glück nicht mehr ein so massiver Einsatz von QoS notwendig. Die Leitungsanforderungen für die Telefonie sind annähernd gleich geblieben, die Leitungen sind dafür aber schneller geworden. Wenn es dennoch häufig zu hörbaren Problemen kommen sollte, sollte man in der Regel doch eher sein Verhalten im Internet überdenken (ich rede jetzt nur von Privatpersonen).
Die DLAN Connect IP können es auch und das ist fies, weil hier die standardmäßige Flatrate nur für BE gilt. Für Low Loss und Los Delay hat man pro Monat 3GB frei und dann laufen die Euros durch.
Die Telekom scheint aber bei den Endkundenanschlüssen auch irgendwas zu haben, weil in der 1TR112 ist was in Richung QoS definiert.
Bei den heutigen Bandbreiten ist für Voice zum Glück nicht mehr ein so massiver Einsatz von QoS notwendig. Die Leitungsanforderungen für die Telefonie sind annähernd gleich geblieben, die Leitungen sind dafür aber schneller geworden. Wenn es dennoch häufig zu hörbaren Problemen kommen sollte, sollte man in der Regel doch eher sein Verhalten im Internet überdenken (ich rede jetzt nur von Privatpersonen).
