29
VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Hallo,
habe da eine Verständnisfrage zur VoIP-Telefonie mit dem SIP-Client "Zoiper" (für Windows, Android).
Habe folgenden Testaufbau hier:
Internet -- FritzBox (7560), 192.168.1.1/24 --- 192.168.1.2/24 EdgeRouter (als Firewall) 192.168.2.1/24 -- Windows-PC (Windows 10), Subnetz 192.168.2.0/24
Auf dem EdgeRouter habe ich was die VoIP-Telefonie betrifft ausschließlich den SIP-Port 5060 (UDP-Protokoll) aus dem 192.168.2.0/24er-Netz
in Richtung der 192.168.1.1/24 (IP-Adresse der FritzBox) erlaubt.
Ansonsten habe ich für die VoIP-Telefonie keinerlei weitere Ports geöffnet / erlaubt.
Ich bin nur sehr verwundert darüber, dass trotzdem die VoIP-Telefonie problemlos funktioniert und zwar in beide Richtungen.
Sprich, ich kann den anderen Gesprächsteilnehmer hören und er mich ebenfalls.
Müssen für VoIP-Telefonie nicht normalerweise noch Ports für die Audioübertragung (RTP-Ports)
geöffnet werden?
Einen STUN-Server verwende ich übrigens nicht,
der ist in den Einstellungen von "Zoiper" (der SIP-Client auf dem Windows-PC) ausgeschaltet/deaktiviert.
Kann mir jemand erklären, warum die VoIP-Telefonie bei mir funktioniert,
obwohl ich nur den SIP-Port 5060 (UDP) in Richtung meiner FritzBox erlaubt habe?
Bin da wirklich sehr überrascht drüber und verstehe es nicht wirklich.
Habe erwartet, dass ich wie gesagt noch die RTP-Ports freischalten muss ^^.
Über hilfreiche Infos von Euch würde ich mich sehr freuen.
Gruß, Datax
habe da eine Verständnisfrage zur VoIP-Telefonie mit dem SIP-Client "Zoiper" (für Windows, Android).
Habe folgenden Testaufbau hier:
Internet -- FritzBox (7560), 192.168.1.1/24 --- 192.168.1.2/24 EdgeRouter (als Firewall) 192.168.2.1/24 -- Windows-PC (Windows 10), Subnetz 192.168.2.0/24
Auf dem EdgeRouter habe ich was die VoIP-Telefonie betrifft ausschließlich den SIP-Port 5060 (UDP-Protokoll) aus dem 192.168.2.0/24er-Netz
in Richtung der 192.168.1.1/24 (IP-Adresse der FritzBox) erlaubt.
Ansonsten habe ich für die VoIP-Telefonie keinerlei weitere Ports geöffnet / erlaubt.
Ich bin nur sehr verwundert darüber, dass trotzdem die VoIP-Telefonie problemlos funktioniert und zwar in beide Richtungen.
Sprich, ich kann den anderen Gesprächsteilnehmer hören und er mich ebenfalls.
Müssen für VoIP-Telefonie nicht normalerweise noch Ports für die Audioübertragung (RTP-Ports)
geöffnet werden?
Einen STUN-Server verwende ich übrigens nicht,
der ist in den Einstellungen von "Zoiper" (der SIP-Client auf dem Windows-PC) ausgeschaltet/deaktiviert.
Kann mir jemand erklären, warum die VoIP-Telefonie bei mir funktioniert,
obwohl ich nur den SIP-Port 5060 (UDP) in Richtung meiner FritzBox erlaubt habe?
Bin da wirklich sehr überrascht drüber und verstehe es nicht wirklich.
Habe erwartet, dass ich wie gesagt noch die RTP-Ports freischalten muss ^^.
Über hilfreiche Infos von Euch würde ich mich sehr freuen.
Gruß, Datax
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: 426334
Url: https://administrator.de/contentid/426334
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
29 Kommentare
Neuester Kommentar
Prinzipiell ist das richtig - jedoch: Wenn du dich als Client anmeldest musst du eigentlich überhaupt keine Ports manuell öffnen oder weiterleiten.
Die Router resp. deren NAT-Connectiontracker erkennen selbst, welche Pakete zu einer von innen nach außen geöffneten Verbindung gehören und welche nicht. Da Zoiper - wie alle ordentlichen SIP-Clients - symmetrisches RTP verwendet, passiert folgendes:
Sobald per SIP die Verbindung aufgebaut ist, beginnt Zoiper damit, RTP-Daten in Richtung Fritzbox zu senden.
Das geschieht von Source-Port 12345 zur FritzBox an Port 9876.
Der Connection-Tracker auf dem NAT registriert nun also, dass du Pakete von deiner Source-IP und Source-Port 12345 zur FritzBox schickst.
Die Fritte schickt nun ihrerseits von Port 9876 an deinen Zoiper auf Port 12345 die RTP-Pakete für die Gegenrichtung.
Bei diesen Paketen stimmen also Source-IP und Source-Port dahingehend überein, dass sie zu den Zieladressen passen, an die du bereits ausgehend RTP sendest.
Dein NAT-Router erkennt darin Antwort-Pakete zu deinem ausgehenden RTP-Stream und kann diese Pakete an dich zustellen.
Bei asymmetrischem RTP würden unterschiedliche Port-Kombinationen verwendet, bei denen nur in jeweils eine Richtung gesendet wird (also vom Client von Port A nach Port B und vom Server von Port C an Port D) - da ist der Connection-Tracker machtlos.
Da würde dann - falls der Edge-Router das kann und es aktiviert ist - SIP-ALG helfen, wo die SDP-Daten aus den SIP-Paketen ausgewertet werden um zu ermitteln, welche Ports für RTP benötigt werden, die dann entsprechend dem Connection-Tracker bereits vorab registriert werden, bevor überhaupt Traffic darauf entsteht.
Wenn du also nicht explizit ausgehenden Traffic vom LAN des Edge-Router nach außen hin eingeschränkt hast: Works as expected.
Die Router resp. deren NAT-Connectiontracker erkennen selbst, welche Pakete zu einer von innen nach außen geöffneten Verbindung gehören und welche nicht. Da Zoiper - wie alle ordentlichen SIP-Clients - symmetrisches RTP verwendet, passiert folgendes:
Sobald per SIP die Verbindung aufgebaut ist, beginnt Zoiper damit, RTP-Daten in Richtung Fritzbox zu senden.
Das geschieht von Source-Port 12345 zur FritzBox an Port 9876.
Der Connection-Tracker auf dem NAT registriert nun also, dass du Pakete von deiner Source-IP und Source-Port 12345 zur FritzBox schickst.
Die Fritte schickt nun ihrerseits von Port 9876 an deinen Zoiper auf Port 12345 die RTP-Pakete für die Gegenrichtung.
Bei diesen Paketen stimmen also Source-IP und Source-Port dahingehend überein, dass sie zu den Zieladressen passen, an die du bereits ausgehend RTP sendest.
Dein NAT-Router erkennt darin Antwort-Pakete zu deinem ausgehenden RTP-Stream und kann diese Pakete an dich zustellen.
Bei asymmetrischem RTP würden unterschiedliche Port-Kombinationen verwendet, bei denen nur in jeweils eine Richtung gesendet wird (also vom Client von Port A nach Port B und vom Server von Port C an Port D) - da ist der Connection-Tracker machtlos.
Da würde dann - falls der Edge-Router das kann und es aktiviert ist - SIP-ALG helfen, wo die SDP-Daten aus den SIP-Paketen ausgewertet werden um zu ermitteln, welche Ports für RTP benötigt werden, die dann entsprechend dem Connection-Tracker bereits vorab registriert werden, bevor überhaupt Traffic darauf entsteht.
Wenn du also nicht explizit ausgehenden Traffic vom LAN des Edge-Router nach außen hin eingeschränkt hast: Works as expected.
1
Super erklärt.
Das müsste man hier eigentlich als festen Link etablieren, da es gefühlt wöchentlich 3mal gefragt wird wenns um VoIP und NAT Router geht.
Das müsste man hier eigentlich als festen Link etablieren, da es gefühlt wöchentlich 3mal gefragt wird wenns um VoIP und NAT Router geht.
Danke für diese Rückmeldung und Erläuterung.
Mir war nicht bewusst,
dass der EdgeRouter auch Connection-Tracking unterstützt ^^.
Hätte mir eigentlich klar sein müssen,
aber bin trotzdem nicht drauf gekommen.
Die RTP-Ports "9876" (FritzBox) und "12345" (Zoiper) waren aber jetzt nur beispielhaft von
dir ausgedacht gewesen, oder!?
Bei mir werden nämlich andere Ports verwendet.
Bei einem Test-Anruf gerade konnte ich per "tcpdump" sehen,
dass die FritzBox UDP-Port 7078 für RTP verwendet und der SIP-Client UDP-Port 8000 (ist entsprechend auch so in Zoiper eingestellt).
Die FritzBox hat einen vordefinierten Portbereich für RTP,
das sind die Ports 7078 - 7110 (UDP).
Siehe dazu auch folgender Link:
https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_port_rt ...
Noch eine kurze Frage:
Die RTP-Ports, die für die Audioübertragung genutzt werden,
werden doch während der SIP-Aushandlung (ich nenne das mal so) zwischen der FritzBox und dem SIP-Client "vereinbart", richtig!?
Bin gerade dabei mich etwas in die VoIP-Technik einzuarbeiten.
Sind dir noch gute Links zur Funktionsweise der VoIP-Technik bekannt?
Gruß, Datax
Mir war nicht bewusst,
dass der EdgeRouter auch Connection-Tracking unterstützt ^^.
Hätte mir eigentlich klar sein müssen,
aber bin trotzdem nicht drauf gekommen.
Die RTP-Ports "9876" (FritzBox) und "12345" (Zoiper) waren aber jetzt nur beispielhaft von
dir ausgedacht gewesen, oder!?
Bei mir werden nämlich andere Ports verwendet.
Bei einem Test-Anruf gerade konnte ich per "tcpdump" sehen,
dass die FritzBox UDP-Port 7078 für RTP verwendet und der SIP-Client UDP-Port 8000 (ist entsprechend auch so in Zoiper eingestellt).
Die FritzBox hat einen vordefinierten Portbereich für RTP,
das sind die Ports 7078 - 7110 (UDP).
Siehe dazu auch folgender Link:
https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_port_rt ...
Noch eine kurze Frage:
Die RTP-Ports, die für die Audioübertragung genutzt werden,
werden doch während der SIP-Aushandlung (ich nenne das mal so) zwischen der FritzBox und dem SIP-Client "vereinbart", richtig!?
Bin gerade dabei mich etwas in die VoIP-Technik einzuarbeiten.
Sind dir noch gute Links zur Funktionsweise der VoIP-Technik bekannt?
Gruß, Datax
Ja, ist doch eine gute Idee :D.
Ich bin immer noch auf der Suche nach einem gut verständlichen Artikel über die Funktionsweise
der VoIP-Technik.
Sprich, einen Artikel, wo im Detail erklärt wird,
welche Verbindungen in welche Richtung zustande kommen.
Auch auf die Verwendung eines STUN-Servers und ggf. notwendigen DNAT-Regeln (Portweiterleitungen) bei der Nutzung
der VoIP-Technik sollte eingegangen werden.
Sind dir dazu entsprechende Webseiten bekannt?
Gruß, Datax
Ich bin immer noch auf der Suche nach einem gut verständlichen Artikel über die Funktionsweise
der VoIP-Technik.
Sprich, einen Artikel, wo im Detail erklärt wird,
welche Verbindungen in welche Richtung zustande kommen.
Auch auf die Verwendung eines STUN-Servers und ggf. notwendigen DNAT-Regeln (Portweiterleitungen) bei der Nutzung
der VoIP-Technik sollte eingegangen werden.
Sind dir dazu entsprechende Webseiten bekannt?
Gruß, Datax
Natürlich, das waren nur beispielhafte Angaben.
Grundsätzlich kannst du natürlich beliebige Ports verwenden (mit Ausnahme des SIP-Ports, natürlich). Wie du richtig bemerkt hast, werden die beim Verbindungsaufbau ausgehandelt.
Dazu schickt beim INVITE einfach jede Seite als eine Art Anhang zur SIP-Nachricht den SDP (Session Description Protocol) mit.
Hier in diesem Fall ist das eine SIP-Nachricht, welche von meinem Telefon an den SIP-Server gesendet wurde.
Das Telefon hat die IP 192.168.1.8 und teilt dem SIP-Server mit, dass es Media-Streams unter dieser IP entgegen nimmt und diese an Port 16466 gerichtet werden sollen.
Dazu gibt es eine Liste von unterstützten Codecs, die in Reihenfolge der Präferenz dort aufgelistet sind. Es soll dann der Codec genommen werden, der als erster auf beiden Seiten unterstützt wird.
Hier siehst du auch den "Codec" "telephone-event" mit der ID 101. Das ist die Information, wie DTMF (also die Zifferntasten des Telefons) übertragen werden soll - in diesem Fall per SIP-Paket ("SIP INFO").
Es ist ein wenig komplizierter, da das Telefon unter Umständen verschiedene Typen Media-Streams über verschiedene Protokolle gleichzeitig empfangen könnte (z.B. Audio und Video und Text), deshalb werden die Ports für jedes Mediaformat separat angegeben. In der freien Wildbahn wirst du aber eigentlich immer nur die Situation haben, dass RTP/AVP als Transport verwendet wird und alle Mediaformate ("Codecs") den gleichen Port verwenden.
Lediglich bei Fax über T.38 wirst du manchmal etwas anderes erleben, da hier explizit zwischen Audioübertragung und der Übertragung einer TIFF- oder JPEG-Datei unterschieden werden muss. Da werden dann in der Regel unterschiedliche Ports für Audio und Bilddatei ausgehandelt.
Im oben gezeigten Beispiel hat das Telefon die IP 192.168.1.8 und Port 16466 bekannt gegeben.
Die Telefonanlage hat, was hier nicht zu sehen ist, ihrerseits IP-Adresse 192.168.0.3 und Port 44148 durchgesagt.
Beide haben sich auf den Codec G.722 geeinigt und so fließt dann jetzt auch der RTP-Stream (symmetrisch) entsprechend:
Dass die im SDP genannte IP-Adresse jetzt die IP-Adresse des Telefons ist, ist natürlich zu erwarten - muss aber nicht zwingend so sein.
Denn SIP ist ja erstmal nur dazu da, eine solche Verbindung zu steuern - was dann später über eine solche ausgehandelte Verbindung für Daten übertragen werden, interessiert SIP nicht
Es gibt daher durchaus SIP-Server, die unter IP-Adresse A erreichbar sind, aber angeben, dass die Media-Daten alle an IP-Adresse B gerichtet werden sollen (und natürlich dann auch von dort kommen), weil dort dann z.B. ein Media-Proxy läuft. Oder - bei internen Telefonanlagen - wird direkt die IP-Adresse des angerufenen Telefons dort angegeben, damit die RTP-Daten nicht erst noch einen Umweg laufen müssen.
Da diese Sache in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Dann schickt die Gegenstelle den RTP-Stream an eine IP, die sie möglicherweise gar nicht erreichen kann - und dann hast du den Effekt, dass der Angerufene dich hort, aber kein Audio zu dir kommt.
Dazu würde der Client dann STUN oder ICE verwenden, um herauszubekommen welche IP per NAT herauskommt und diese dann stattdessen in den SDP schreiben.
Grundsätzlich kannst du natürlich beliebige Ports verwenden (mit Ausnahme des SIP-Ports, natürlich). Wie du richtig bemerkt hast, werden die beim Verbindungsaufbau ausgehandelt.
Dazu schickt beim INVITE einfach jede Seite als eine Art Anhang zur SIP-Nachricht den SDP (Session Description Protocol) mit.
Hier in diesem Fall ist das eine SIP-Nachricht, welche von meinem Telefon an den SIP-Server gesendet wurde.
Das Telefon hat die IP 192.168.1.8 und teilt dem SIP-Server mit, dass es Media-Streams unter dieser IP entgegen nimmt und diese an Port 16466 gerichtet werden sollen.
Dazu gibt es eine Liste von unterstützten Codecs, die in Reihenfolge der Präferenz dort aufgelistet sind. Es soll dann der Codec genommen werden, der als erster auf beiden Seiten unterstützt wird.
Hier siehst du auch den "Codec" "telephone-event" mit der ID 101. Das ist die Information, wie DTMF (also die Zifferntasten des Telefons) übertragen werden soll - in diesem Fall per SIP-Paket ("SIP INFO").
Es ist ein wenig komplizierter, da das Telefon unter Umständen verschiedene Typen Media-Streams über verschiedene Protokolle gleichzeitig empfangen könnte (z.B. Audio und Video und Text), deshalb werden die Ports für jedes Mediaformat separat angegeben. In der freien Wildbahn wirst du aber eigentlich immer nur die Situation haben, dass RTP/AVP als Transport verwendet wird und alle Mediaformate ("Codecs") den gleichen Port verwenden.
Lediglich bei Fax über T.38 wirst du manchmal etwas anderes erleben, da hier explizit zwischen Audioübertragung und der Übertragung einer TIFF- oder JPEG-Datei unterschieden werden muss. Da werden dann in der Regel unterschiedliche Ports für Audio und Bilddatei ausgehandelt.
Im oben gezeigten Beispiel hat das Telefon die IP 192.168.1.8 und Port 16466 bekannt gegeben.
Die Telefonanlage hat, was hier nicht zu sehen ist, ihrerseits IP-Adresse 192.168.0.3 und Port 44148 durchgesagt.
Beide haben sich auf den Codec G.722 geeinigt und so fließt dann jetzt auch der RTP-Stream (symmetrisch) entsprechend:
Dass die im SDP genannte IP-Adresse jetzt die IP-Adresse des Telefons ist, ist natürlich zu erwarten - muss aber nicht zwingend so sein.
Denn SIP ist ja erstmal nur dazu da, eine solche Verbindung zu steuern - was dann später über eine solche ausgehandelte Verbindung für Daten übertragen werden, interessiert SIP nicht
Es gibt daher durchaus SIP-Server, die unter IP-Adresse A erreichbar sind, aber angeben, dass die Media-Daten alle an IP-Adresse B gerichtet werden sollen (und natürlich dann auch von dort kommen), weil dort dann z.B. ein Media-Proxy läuft. Oder - bei internen Telefonanlagen - wird direkt die IP-Adresse des angerufenen Telefons dort angegeben, damit die RTP-Daten nicht erst noch einen Umweg laufen müssen.
Da diese Sache in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Dann schickt die Gegenstelle den RTP-Stream an eine IP, die sie möglicherweise gar nicht erreichen kann - und dann hast du den Effekt, dass der Angerufene dich hort, aber kein Audio zu dir kommt.
Dazu würde der Client dann STUN oder ICE verwenden, um herauszubekommen welche IP per NAT herauskommt und diese dann stattdessen in den SDP schreiben.
Wäre es möglich,
dass ich auf der Schnittstelle des EdgeRouters zur FritzBox hin Masquerading aktiviere?
Würde schon ganz gerne das LAN hinter dem EdgeRouter nach außen maskieren,
dann funktioniert "Zoiper" aber leider nicht mehr.
Welche Konfigurationsänderungen auf dem EdgeRouter wären nötig,
wenn ich Masquerading auf der Schnittstelle zur FritzBox hin aktiviert haben möchte und gleichzeitig "Zoiper" nutzen möchte?
Oder ist dieses Setup so gar nicht möglich?
Gruß, Datax
dass ich auf der Schnittstelle des EdgeRouters zur FritzBox hin Masquerading aktiviere?
Würde schon ganz gerne das LAN hinter dem EdgeRouter nach außen maskieren,
dann funktioniert "Zoiper" aber leider nicht mehr.
Welche Konfigurationsänderungen auf dem EdgeRouter wären nötig,
wenn ich Masquerading auf der Schnittstelle zur FritzBox hin aktiviert haben möchte und gleichzeitig "Zoiper" nutzen möchte?
Oder ist dieses Setup so gar nicht möglich?
Gruß, Datax
Ich zitiere mich mal selbst:
Probier mal, ob Zoiper und FritzBox ICE können, dann sollte das Problem damit entfallen.
Ansonsten: Gibt es gute Gründe, innerhalb deines lokalen Netzes NAT zu machen? Eigentlich ist das etwas, was man aus Performance-Gründen dringend vermeiden möchte.
Da diese Sache [IP-Adresse in SDP abweichend von der IP der SIP-Gegenstelle] in SIP so vorgesehen ist, kannst du dir in Kombination mit NAT auch gewaltig in den Fuß schießen:
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Denn um die IP-Adresse in den SDP schreiben zu können, muss der Client seine IP kennen. Und der nimmt natürlich an, dass dort die IP-Adresse hinein gehört, die an seinem Netzwerk-Interface konfiguriert ist.
Ein Telefon würde da also - wie hier - seine lokale IPv4-Adresse hinein schreiben, mit etwas Pech wird aber an irgendeinem Router NAT gemacht und die IP stimmt so nicht mehr.
Probier mal, ob Zoiper und FritzBox ICE können, dann sollte das Problem damit entfallen.
Ansonsten: Gibt es gute Gründe, innerhalb deines lokalen Netzes NAT zu machen? Eigentlich ist das etwas, was man aus Performance-Gründen dringend vermeiden möchte.
Nein, gibt dafür keinen expliziten Grund.
Bei der Einrichtung des EdgeRouters hatte ich mal den Setup-Assistenten verwendet.
Der hat mir auf "eth0" (192.168.1.2/24, Schnittstelle zur FritzBox hin) automatisch das Masquerading aktiviert.
Bei der Nutzung von "Zoiper" ist mir dann aufgefallen,dass die VoIP-Telefonie nur dann funktioniert,
wenn ich auf "eth0" das Masquerading ausschalte.
Jetzt habe ich inzwischen verstanden, warum das so ist.
Mich hat jetzt nur mal interessiert,
ob es denn technisch grundsätzlich auch weiterhin mit aktiviertem Masquerading funktionieren könnte.
Habe jetzt das Masquerading auf "eth0" auf jeden Fall ausgeschaltet und es funktioniert alles wie gewünscht.
Gruß, Datax
Bei der Einrichtung des EdgeRouters hatte ich mal den Setup-Assistenten verwendet.
Der hat mir auf "eth0" (192.168.1.2/24, Schnittstelle zur FritzBox hin) automatisch das Masquerading aktiviert.
Bei der Nutzung von "Zoiper" ist mir dann aufgefallen,dass die VoIP-Telefonie nur dann funktioniert,
wenn ich auf "eth0" das Masquerading ausschalte.
Jetzt habe ich inzwischen verstanden, warum das so ist.
Mich hat jetzt nur mal interessiert,
ob es denn technisch grundsätzlich auch weiterhin mit aktiviertem Masquerading funktionieren könnte.
Habe jetzt das Masquerading auf "eth0" auf jeden Fall ausgeschaltet und es funktioniert alles wie gewünscht.
Gruß, Datax
dass ich auf der Schnittstelle des EdgeRouters zur FritzBox hin Masquerading aktiviere?
Das ist vermutlich zwangsweise aktiviert !M.E. ist der ER einer dieser billigen Provider
<edit>Falsch ! Er er ist ein kleiner mit halbwegs gutem Featureset ausgestatteter Router von Ubiquity aber mit einer sehr gruseligen und schwer verständlichen Konfig Syntax </edit>
Hier hat Kollege @LordGurke Recht das man, wenn immer möglich, sowas im internen Netz vermeiden sollte. Gerade wegen der oben schon angesprochenen Problematiken bei RDP und nicht nur da.
Details zum Thema Doppeltes NAT in Kaskaden und Nachteile findest du hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
und auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
@aqui:
Die Edge-Router lassen sich ziemlich gut anpassen. Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Der Setup-Assistent ist aber halt darauf ausgelegt, dass es in 90% der Fälle sofort funktioniert - hier haben wir halt die 10%, wo man von Hand konfigurieren muss
Die Edge-Router lassen sich ziemlich gut anpassen. Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Der Setup-Assistent ist aber halt darauf ausgelegt, dass es in 90% der Fälle sofort funktioniert - hier haben wir halt die 10%, wo man von Hand konfigurieren muss
Ja, okay.
Sehe ich wie du,
der EdgeRouter-X kostet ca. 50 €.
Für das Geld ist der schon echt super.
Kennst du dich mit der Konfiguration des EdgeRouters aus?
Habe vorhin mal überprüfen wollen,
ob denn das Masquerading auch wirklich funktioniert,
wenn es aktiviert ist.
Konnte aber über die WAN-Schnittstelle (in diesem Fall "eth0" des EdgeRouters) problemlos
eine SSH-Verbindung zu einem System hinter dem EdgeRouter aufbauen.
Und das obwohl für das Subnetz des SSH-Servers das Masquerading auf "eth0" aktiviert ist.
Portweiterleitungen sind auf dem EdgeRouter keine eingerichtet,
deshalb wundert mich gerade sehr, dass ich trotzdem eine SSH-Verbindung aufbauen konnte ^^.
Sehe ich wie du,
der EdgeRouter-X kostet ca. 50 €.
Für das Geld ist der schon echt super.
Kennst du dich mit der Konfiguration des EdgeRouters aus?
Habe vorhin mal überprüfen wollen,
ob denn das Masquerading auch wirklich funktioniert,
wenn es aktiviert ist.
Konnte aber über die WAN-Schnittstelle (in diesem Fall "eth0" des EdgeRouters) problemlos
eine SSH-Verbindung zu einem System hinter dem EdgeRouter aufbauen.
Und das obwohl für das Subnetz des SSH-Servers das Masquerading auf "eth0" aktiviert ist.
Portweiterleitungen sind auf dem EdgeRouter keine eingerichtet,
deshalb wundert mich gerade sehr, dass ich trotzdem eine SSH-Verbindung aufbauen konnte ^^.
Schrott-Router würde ich nicht sagen, das ist ziemlich ordentliche Hard- und Software für das Geld.
Betonung liegt auf "für das Geld" vermutlich. OK belassen wir es dabei der EdgeRouter-X kostet ca. 50 €.
Muss man dann auch sicher nicht weiter kommentieren...Verglichen mit dem
https://varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941-2nd- ...
liegen da sicher Lichtjahre dazwischen wenns um das Feature Set geht.
Aber egal...jeder bekommt den Router den er verdient.
Für das Geld ist der schon echt super.
Eine Frage des Horizonts, wie immer.Konnte aber über die WAN-Schnittstelle problemlos eine SSH-Verbindung aufbauen.
Ist das irgendwie relevant für das eigentliche Thema oben ?Und das obwohl für das Subnetz des SSH-Servers das Masquerading auf "eth0" aktiviert ist.
Warum sollte es deiner meinung nach nicht gehen ? Für Outbound Session ist das doch absolut normales Verhalten.Vielleicht doch etwas Grundlagen dazu lesen:
https://de.wikipedia.org/wiki/Port_Address_Translation
dass ich trotzdem eine SSH-Verbindung aufbauen konnte ^^.
Oder falsche oder fehlerhafte Konfig. Oder auch Bug in der ER Firmware ?!
Das stimmt so nicht.
Das Masquerading ist nicht zwangsweise aktiviert.
Man hat die Wahl, ob man bei der Konfiguration einen Assistenten verwendet,
der dann je nach ausgewähltem Setup beispielsweise auf "eth0" das Masquerading aktiviert
oder ob man alles "zu Fuß" konfiguriert.
Besten Dank für die beiden Links.
Das Masquerading ist nicht zwangsweise aktiviert.
Man hat die Wahl, ob man bei der Konfiguration einen Assistenten verwendet,
der dann je nach ausgewähltem Setup beispielsweise auf "eth0" das Masquerading aktiviert
oder ob man alles "zu Fuß" konfiguriert.
Besten Dank für die beiden Links.
Die Router von "Mikrotik" kenne ich ebenfalls,
sind natürlich preislich und vom Funktionsumfang noch eine Nummer besser als die "EdgeRouter".
Da gebe ich dir vollkommen Recht.
Die angesprochene SSH-Verbindung war keine Outbound-Verbindung,
es war eine über die WAN-Schnittstelle eingehende Verbindung zur (privaten) IP-Adresse des SSH-Servers.
Mit dem Masquerading ist das irgendwie komisch bei den "EdgeRoutern" oder ich konfiguriere es wirklich falsch.
Habe dazu bereits die Artikel von "Ubiquiti" gelesen und mich daran gehalten.
Weiß noch nicht genau, warum die genannte SSH-Verbindung zustande kommt,
muss ich mich mal genauer mit befassen.
Aber egal, vielen Dank erstmal für Eure Infos ;).
LG
sind natürlich preislich und vom Funktionsumfang noch eine Nummer besser als die "EdgeRouter".
Da gebe ich dir vollkommen Recht.
Die angesprochene SSH-Verbindung war keine Outbound-Verbindung,
es war eine über die WAN-Schnittstelle eingehende Verbindung zur (privaten) IP-Adresse des SSH-Servers.
Mit dem Masquerading ist das irgendwie komisch bei den "EdgeRoutern" oder ich konfiguriere es wirklich falsch.
Habe dazu bereits die Artikel von "Ubiquiti" gelesen und mich daran gehalten.
Weiß noch nicht genau, warum die genannte SSH-Verbindung zustande kommt,
muss ich mich mal genauer mit befassen.
Aber egal, vielen Dank erstmal für Eure Infos ;).
LG
Das Masquerading ist nicht zwangsweise aktiviert.
War auch nur eine Vermutung denn in der Regel ist das bei den billigen Provider Routern immer der Fall. Mag sein das der ER eine (sehr) seltene aber dann rühmliche Ausnahme ist. es war eine über die WAN-Schnittstelle eingehende Verbindung zur (privaten) IP-Adresse des SSH-Servers.
Oha, böses Faul ! Und das mit aktiviertem NAT ??Das sollte dir aber schwer zu denken geben, denn der NAT Prozess sollte sowas auch ohne Firewall sicher verhindern. Wenn du wirklich keinen Konfig Fehler gemacht hast ist das ziemlich beunruhigend, denn das lässt auf einen gravierenden Firmware Bug schliessen. Kann man sich sehr schwer vorstellen das sowas den Entwicklern nicht aufgefallen ist. Deshalb ist doch eher zu vermuten das du einen Konfig Fehler gemacht hast.
Wie Kollege LordGurke oben schon sehr richtig beschrieben hat kann eine inbound Session über ein aktives NAT OHNE gültigen Eintrag in der Session Tabelle niemals etabliert werden. Das wäre technisch unmöglich.
Bugfreies Verhalten mal vorausgesetzt.
ist das irgendwie komisch bei den "EdgeRoutern" oder ich konfiguriere es wirklich falsch.
Ist aber sehr zu vermuten das da was schief läuft...?!Hier steht wie man es richtig macht:
https://help.ubnt.com/hc/en-us/articles/204976494-EdgeRouter-Source-NAT
Du hast aber Recht: Die Konfig Syntax ist recht "schräg" um es mal vorsichtig zu formulieren.
Weiß noch nicht genau, warum die genannte SSH-Verbindung zustande kommt,
Wireshark ist wie immer dein bester Freund
Inzwischen hab' ich den Fehler gefunden ^^.
Es gab auf der WAN-Schnittstelle eine "Alles erlauben"-Regel,
die also auch sämtliche eingehende Verbindungen erlaubt hat.
Jetzt habe ich dies "Alles erlauben"-Regel mal entfernt und schon bekomme ich natürlich
auch keine SSH-Verbindung mehr :D.
Okay, Fehler also schon mal (Gott sei Dank) gefunden.
Habe aber nochmal eine Verständnisfrage zu "Masquerading":
Das Masquerading bezieht sich ja in diesem Fall (Masquerading auf der WAN-Schnittstelle "eth0") auf
die Datenpakete, die über "eth0 rausgeroutet werden, sprich auf über "eth0" ausgehende Datenpakete.
Warum kann ich dann per "Wireshark" auf meinem Notebook (befindet sich im gleichen Subnetz wie die WAN-Schnittstelle, 192.168.178.0/24)
nicht die Antwortpakete des SSH-Servers (192.168.2.2) sehen, bei denen die Quell-IP-Adresse durch den "EdgeRouter" ersetzt wurde?
Dass die SSH-Verbindung nicht zustande kommt ist logisch,
weil die Antwortpakete von einer anderen Quell-IP-Adresse kommen, deshalb scheitert ja dann entsprechend der Verbindungsaufbau.
Aber müsste ich die Antwortpakete nicht trotzdem zumindest per "Wireshark" auf dem Notebook sehen können?
Oder kann es sein, dass der "EdgeRouter" die Antwortpakete nach dem Masquerading gar nicht erst ausspuckt,
weil es in der NAT-Tabelle keinen Eintrag gibt, der besagt wo dieses betreffende Antwortpakete hingeschickt werden soll!?
Sieht für mich nämlich so aus, weil in Wireshark wie gesagt keine Antwortpakete zu sehen sind (siehe angehängten Screenshot).
Es gab auf der WAN-Schnittstelle eine "Alles erlauben"-Regel,
die also auch sämtliche eingehende Verbindungen erlaubt hat.
Jetzt habe ich dies "Alles erlauben"-Regel mal entfernt und schon bekomme ich natürlich
auch keine SSH-Verbindung mehr :D.
Okay, Fehler also schon mal (Gott sei Dank) gefunden.
Habe aber nochmal eine Verständnisfrage zu "Masquerading":
Das Masquerading bezieht sich ja in diesem Fall (Masquerading auf der WAN-Schnittstelle "eth0") auf
die Datenpakete, die über "eth0 rausgeroutet werden, sprich auf über "eth0" ausgehende Datenpakete.
Warum kann ich dann per "Wireshark" auf meinem Notebook (befindet sich im gleichen Subnetz wie die WAN-Schnittstelle, 192.168.178.0/24)
nicht die Antwortpakete des SSH-Servers (192.168.2.2) sehen, bei denen die Quell-IP-Adresse durch den "EdgeRouter" ersetzt wurde?
Dass die SSH-Verbindung nicht zustande kommt ist logisch,
weil die Antwortpakete von einer anderen Quell-IP-Adresse kommen, deshalb scheitert ja dann entsprechend der Verbindungsaufbau.
Aber müsste ich die Antwortpakete nicht trotzdem zumindest per "Wireshark" auf dem Notebook sehen können?
Oder kann es sein, dass der "EdgeRouter" die Antwortpakete nach dem Masquerading gar nicht erst ausspuckt,
weil es in der NAT-Tabelle keinen Eintrag gibt, der besagt wo dieses betreffende Antwortpakete hingeschickt werden soll!?
Sieht für mich nämlich so aus, weil in Wireshark wie gesagt keine Antwortpakete zu sehen sind (siehe angehängten Screenshot).
nicht die Antwortpakete des SSH-Servers (192.168.2.2) sehen
Wenn du an einem Switchport steckst kann das nicht gehen, denn der Switch forwardet das Paket ja nur an dem Port wo auch die Mac Adresse des SSH Servers ist.Wenn, dann musst du den Wireshark mit einer Bridge dort einschleifen:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Oder sofern du einen managebaren Switch hast musst du den Port über einen Mirror Port (Siegel- oder SPAN Port) auf den Wireshark spiegeln.
Warum das so ist ist hier erklärt:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Abschnitt: "Hardware aufsetzen".
weil es in der NAT-Tabelle keinen Eintrag gibt, der besagt wo dieses betreffende Antwortpakete hingeschickt werden soll!?
Wenn es keine inbound Session dazu in der NAT Session Tabelle gibt dem die Antwortpakete zugeordnet werden können dann ja.Du kannst niemals an einem NAT/Masquerading Port eine Session von außen initiieren. Dazu kann es ja keinen NAT Session Eintrag geben und der NAT Router verwirft (dropped) dann solche Pakete logischerweise sofort.
Das ist der NAT Firewall Effekt. Guckst du auch hier:
https://de.wikipedia.org/wiki/Netzwerkadressübersetzung
Danke für deine Erklärung.
Noch eine Frage an der Stelle:
Wann werden denn auf dem Router,
der am Internet angeschlossen ist, überhaupt Portweiterleitungen benötigt?
Ich spreche von dem Router,
über den der SIP-Client ins Internet geht.
Wären Portweiterleitungen zum Beispiel notwendig,
wenn der SIP-Client über einen SIP-Server kommuniziert,
der im Internet "steht" (also sich nicht im eigenen LAN befindet)?
Noch eine Frage an der Stelle:
Wann werden denn auf dem Router,
der am Internet angeschlossen ist, überhaupt Portweiterleitungen benötigt?
Ich spreche von dem Router,
über den der SIP-Client ins Internet geht.
Wären Portweiterleitungen zum Beispiel notwendig,
wenn der SIP-Client über einen SIP-Server kommuniziert,
der im Internet "steht" (also sich nicht im eigenen LAN befindet)?
Portweiterleitungen brauchst du nur dann, wenn du eingehend neue Verbindungen erwartest, die nicht zu einer bestehenden Verbindung gehören.
Also kurz gesagt: Solange du nur Client bist, brauchst du im Normalfall keine Portweiterleitungen.
Also kurz gesagt: Solange du nur Client bist, brauchst du im Normalfall keine Portweiterleitungen.
Ach so, okay.
Wie sieht es aus, wenn man hinter einem (NAT)-Router, der ans Internet angeschlossen ist,
eine VoIP-Telefonanlage betreiben möchte?
Müssten dann Ports weitergeleitet werden (für SIP, RTP)?
Wie sieht es aus, wenn man hinter einem (NAT)-Router, der ans Internet angeschlossen ist,
eine VoIP-Telefonanlage betreiben möchte?
Müssten dann Ports weitergeleitet werden (für SIP, RTP)?
Nicht zwingend. Wenn die Anlage ein Keepalive macht oder ALG hat dann hält sie den Port in der NAT Firewall offen. Auch bei Verwendung von STUN benötigt man es in der Regel nicht.
Oft löst aber rein nur die Weiterleitung von TCP/UDP 5060 (SIP) auf die IP der dahinterliegenden Anlage so manches Problem.
Kollege @LordGurke hat ja oben schon alle diese Mechanismen hinreichend erklärt !
Oft löst aber rein nur die Weiterleitung von TCP/UDP 5060 (SIP) auf die IP der dahinterliegenden Anlage so manches Problem.
Kollege @LordGurke hat ja oben schon alle diese Mechanismen hinreichend erklärt !
Hi, habe nochmal eine Frage zum Ablauf der Verbindungen bei einem VoIP-Gespräch.
Der erste Schritt ist ja, dass der VoIP-Client eine Verbindung zum SIP-Port
des SIP-Servers aufbaut (z.B. zum SIP-Port des SIP-Servers der FritzBox).
Während der SIP-Verbindung werden ja dann die RTP-Ports für die Übertragung
der Sprache ausgehandelt.
Frage(n) zum darauf folgenden Ablauf:
Welcher der beiden Kommunikationspartner sendet denn nach der Aushandlung der RTP-Ports
als Erster zum Gegenüber?
Sendet der SIP-Server zuerst zum SIP-Client oder umgekehrt?
Ich frage deshalb, weil ich ursprünglich hier ja angegeben habe,
dass ich in der Firewall des EdgeRouters keinerlei RTP-Ports freigegeben habe.
Kann der EdgeRouter also in die SIP-Verbindung "reinschauen" und erkennen,
dass er den kurz danach losgehenden RTP-Traffic von Port X des SIP-Servers zu Port Y des SIP-Clients
erlauben muss (weil der RTP-Traffic ja die Folge einer zuvor durch einen Client initiierten SIP-Sitzung ist)?
Sprich, der RTP-Traffic wird dann vollautomatisch vom EdgeRouter erlaubt!?
Gehört das also ebenfalls zum "Connection Tracking" moderner Router!?
Ist es dabei egal, welcher der beiden Kommunikationspartner zuerst RTP-Daten zum Gegenüber sendet?
Datax
Der erste Schritt ist ja, dass der VoIP-Client eine Verbindung zum SIP-Port
des SIP-Servers aufbaut (z.B. zum SIP-Port des SIP-Servers der FritzBox).
Während der SIP-Verbindung werden ja dann die RTP-Ports für die Übertragung
der Sprache ausgehandelt.
Frage(n) zum darauf folgenden Ablauf:
Welcher der beiden Kommunikationspartner sendet denn nach der Aushandlung der RTP-Ports
als Erster zum Gegenüber?
Sendet der SIP-Server zuerst zum SIP-Client oder umgekehrt?
Ich frage deshalb, weil ich ursprünglich hier ja angegeben habe,
dass ich in der Firewall des EdgeRouters keinerlei RTP-Ports freigegeben habe.
Kann der EdgeRouter also in die SIP-Verbindung "reinschauen" und erkennen,
dass er den kurz danach losgehenden RTP-Traffic von Port X des SIP-Servers zu Port Y des SIP-Clients
erlauben muss (weil der RTP-Traffic ja die Folge einer zuvor durch einen Client initiierten SIP-Sitzung ist)?
Sprich, der RTP-Traffic wird dann vollautomatisch vom EdgeRouter erlaubt!?
Gehört das also ebenfalls zum "Connection Tracking" moderner Router!?
Ist es dabei egal, welcher der beiden Kommunikationspartner zuerst RTP-Daten zum Gegenüber sendet?
Datax
Kollege @LordGurke hat es oben doch im ersten Post wunderbar erklärt. Da muss man eigentlich nichts mehr hinzufügen.
https://kompendium.infotip.de/voip-voice-over-ip.html
https://de.wikipedia.org/wiki/IP-Telefonie#Verbindungsaufbau_mit_SIP
usw.
https://kompendium.infotip.de/voip-voice-over-ip.html
https://de.wikipedia.org/wiki/IP-Telefonie#Verbindungsaufbau_mit_SIP
usw.
dass ich in der Firewall des EdgeRouters keinerlei RTP-Ports freigegeben habe.
Dann hat die FW des Routers ein Voice Application Gateway SIP-ALG) und macht das automatisch.Kann der EdgeRouter also in die SIP-Verbindung "reinschauen" und erkennen,
Ja, die ALG Funktion "sieht" dann ins Paket.
Perfekt, danke dir ^^.
Hallo, dieser Thread ist schon etwas länger her.
Bei mir ist noch eine Frage aufgekommen.
Warum ist in Bedienungsanleitungen von dem ein oder anderen VoIP-Telefon zu lesen,
dass der SIP- sowie die RTP-Ports auf dem NAT-Router per Portweiterleitung an das VoIP-Telefon weitergeleitet werden müssen?
Dazu hier beispielhaft die Hinweise für den Betrieb von "Siemens Gigaset"-VoIP-Telefonen für den
Betrieb hinter einem NAT-Router:
https://www.gigaset.com/de_de/cms/service/faq-detail/faq/hinweise-zum-be ...
Auf Seite 2 ist dann zu lesen, dass ggf. (falls eingehend- oder ausgehend bei der Sprachverbindung Störungen auftreten) Portweiterleitungen eingerichtet werden müssen.
Bei mir ist noch eine Frage aufgekommen.
Warum ist in Bedienungsanleitungen von dem ein oder anderen VoIP-Telefon zu lesen,
dass der SIP- sowie die RTP-Ports auf dem NAT-Router per Portweiterleitung an das VoIP-Telefon weitergeleitet werden müssen?
Dazu hier beispielhaft die Hinweise für den Betrieb von "Siemens Gigaset"-VoIP-Telefonen für den
Betrieb hinter einem NAT-Router:
https://www.gigaset.com/de_de/cms/service/faq-detail/faq/hinweise-zum-be ...
Auf Seite 2 ist dann zu lesen, dass ggf. (falls eingehend- oder ausgehend bei der Sprachverbindung Störungen auftreten) Portweiterleitungen eingerichtet werden müssen.
Ich verstehe nach wie vor nicht,
warum man in Bedienungsanleitungen von VoIP-Telefonen und auch auf verschiedenen Internetseiten lesen kann,
dass Portweiterleitungen eingerichtet werden sollen.
warum man in Bedienungsanleitungen von VoIP-Telefonen und auch auf verschiedenen Internetseiten lesen kann,
dass Portweiterleitungen eingerichtet werden sollen.
Das machen die für DAUs die nicht wissen was STUN und SIP Keepalives sind und die oft auch noch billige Provider Schrottrouter haben one Voice Application Gateway in der Firewall um auf Nummer sicher zu gehen das die nicht immer die Hotline anrufen.
Es gibt eben mehrere Schrauben zum Finetuning. Mit einem Port Forwarding forwardest du ja zwangsweise immer eingehende SIP Calls am Router auf die Telefone oder Telefonanlage so das diese Calls immer (DAU) sicher ankommen.
Mit Keepalives, Voice Application Gateways oder STUN geht es aber eben auch ohne.
Es gibt eben mehrere Schrauben zum Finetuning. Mit einem Port Forwarding forwardest du ja zwangsweise immer eingehende SIP Calls am Router auf die Telefone oder Telefonanlage so das diese Calls immer (DAU) sicher ankommen.
Mit Keepalives, Voice Application Gateways oder STUN geht es aber eben auch ohne.
Ach so, okay.
Danke, dann weiß ich da jetzt auch Bescheid
.
Danke, dann weiß ich da jetzt auch Bescheid
.
