13
Verwirrung Portfreigaben für Cloud SIP in pfsense
Hallo,
habe hier zuhause bei mir eine kleine pfsense Box. Grund war damals, dass ich für mein Kamerasystem einen VPN und Vlans brauchte, was mit einer normalen Fritzbox nicht ging. Das funktioniert auch alles ganz gut. Vor der Box hängt ein reines Modem.
Jetzt möchte ich gerne zwei IP Telefone einrichten über einen Cloud Anbieter (Easybell). Dort gibt es auch Angaben, welche Ports in der Firewall freigeben werden müssen.
Das wären UDP
SIP: 5060,5061
RTP: 20000-50000
Als Hosts sind sip.easybell.de... (und noch ein paar andere) angegeben.
Ich habe jetzt 2 Alias erstellt, einen für die Ports und einen für die Hosts.
Die zwei Telefone befinden sich in einem eigenen Vlan ohne DHCP mit festen IPs...
Jetzt stellt sich mir die Frage, ob ich die Ports auch auf der WAN-Schnittstelle freigeben muss? Habe leider das Problem, dass manchmal das Telefon zwar klingelt, aber keiner hört den anderen. In den Firewall Logs ist aber nichts zu erkennen. Bin mir jetzt ein wenig unsicher, ob vielleicht irgendein anderes Problem besteht.
Auf der anderen Seite kann ich nicht so ganz verstehen, wie das überhaupt funktionieren kann, wenn auf der WAN Schnittstelle diese Ports gar nicht freigegeben sind?
Vielleicht weiß jemand mehr ;)
Liebe Grüße und danke
habe hier zuhause bei mir eine kleine pfsense Box. Grund war damals, dass ich für mein Kamerasystem einen VPN und Vlans brauchte, was mit einer normalen Fritzbox nicht ging. Das funktioniert auch alles ganz gut. Vor der Box hängt ein reines Modem.
Jetzt möchte ich gerne zwei IP Telefone einrichten über einen Cloud Anbieter (Easybell). Dort gibt es auch Angaben, welche Ports in der Firewall freigeben werden müssen.
Das wären UDP
SIP: 5060,5061
RTP: 20000-50000
Als Hosts sind sip.easybell.de... (und noch ein paar andere) angegeben.
Ich habe jetzt 2 Alias erstellt, einen für die Ports und einen für die Hosts.
Die zwei Telefone befinden sich in einem eigenen Vlan ohne DHCP mit festen IPs...
Jetzt stellt sich mir die Frage, ob ich die Ports auch auf der WAN-Schnittstelle freigeben muss? Habe leider das Problem, dass manchmal das Telefon zwar klingelt, aber keiner hört den anderen. In den Firewall Logs ist aber nichts zu erkennen. Bin mir jetzt ein wenig unsicher, ob vielleicht irgendein anderes Problem besteht.
Auf der anderen Seite kann ich nicht so ganz verstehen, wie das überhaupt funktionieren kann, wenn auf der WAN Schnittstelle diese Ports gar nicht freigegeben sind?
Vielleicht weiß jemand mehr ;)
Liebe Grüße und danke
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: 1378347813
Url: https://administrator.de/contentid/1378347813
Printed on: April 19, 2024 at 03:04 o'clock
13 Comments
Latest comment
Moin...
natürlich soll das auf dem WAN port gemacht werden!
Frank
natürlich soll das auf dem WAN port gemacht werden!
Frank
@Vision2015
Nunja was heißt natürlich.
Mich verwirrt es das Ports auf der Wan Schnittstelle freigegeben werden. Meiner Meinung ist es doch so, dass die LAN bzw. VLAN Geräte eigenständig die Kommunikation aufbauen. Also das Telefon registriert sich auf der Cloud an Port 5060. Dieser Port wird dann seitens des Telefons offen gehalten... die Kommunikation Invite, RTP Ports etc. erfolgt dann über diesen Kanal.
Die Cloud ruft ja nicht eigenständig mein Telefon über diesen Port an? Von außen her weiß die Firewall ja sowieso nicht auf welches Gerät die Ports gehen, da es sich ja nicht um Portweiterleitungen handelt, sondern Freigaben. Das ist doch bei allen anderen Ports (z.b. 80,443,1194 ...) genauso?
Hinzukommt, dass beide Telefone doch sowieso den selben Port (5060) benutzen?
Viele "Anleitungen" im Netz sprechen ohnehin von Portweiterleitungen/Portforwarding ... aber das findet doch hier gar nicht statt? Hinzukommt, dass es ja theoretisch auch so funktioniert. Nur so ganz verstehen kann ich es halt nicht, da viele eben sagen, dass man auf der WAN die Ports freigeben muss.
Und wie stelle ich sonst ein, dass die VLAN Geräte ausschließlich mit diesem Anbieter über die Ports kommunizieren können (neben NTP und DNS) und sonst nichts ?
Nunja was heißt natürlich.
Mich verwirrt es das Ports auf der Wan Schnittstelle freigegeben werden. Meiner Meinung ist es doch so, dass die LAN bzw. VLAN Geräte eigenständig die Kommunikation aufbauen. Also das Telefon registriert sich auf der Cloud an Port 5060. Dieser Port wird dann seitens des Telefons offen gehalten... die Kommunikation Invite, RTP Ports etc. erfolgt dann über diesen Kanal.
Die Cloud ruft ja nicht eigenständig mein Telefon über diesen Port an? Von außen her weiß die Firewall ja sowieso nicht auf welches Gerät die Ports gehen, da es sich ja nicht um Portweiterleitungen handelt, sondern Freigaben. Das ist doch bei allen anderen Ports (z.b. 80,443,1194 ...) genauso?
Hinzukommt, dass beide Telefone doch sowieso den selben Port (5060) benutzen?
Viele "Anleitungen" im Netz sprechen ohnehin von Portweiterleitungen/Portforwarding ... aber das findet doch hier gar nicht statt? Hinzukommt, dass es ja theoretisch auch so funktioniert. Nur so ganz verstehen kann ich es halt nicht, da viele eben sagen, dass man auf der WAN die Ports freigeben muss.
Und wie stelle ich sonst ein, dass die VLAN Geräte ausschließlich mit diesem Anbieter über die Ports kommunizieren können (neben NTP und DNS) und sonst nichts ?
aber keiner hört den anderen.
Das zeigt immer das deine RDP Ports nicht durchkommen, denn die reinen Voice Daten an sich werden über RTP übertragen. SIP ist lediglich die Signalisierung (klingeln, wählen usw.).Was dich verwirrt und du vermutlich nicht auf dem Radar hast ist das RTP zufällige Ports eröffnet für die Voice Daten. Diese RTP Kommunikation baut auch der SIP Provider auf also nicht dein Endgerät.
Bei dir in der Range 20000-50000. Da du nicht weisst welcher müsstest du diese Portrange für RTP freigeben. Sicherheitstechnisch natürlich nicht besonders dolle.
Besser ist es dann immer mit STUN zu arbeiten, dann kann man solche Klimmzüge vermeiden.
dass beide Telefone doch sowieso den selben Port (5060) benutzen?
Oben schreibst du aber etwas ganz anderes mit 5060 und 5061 zumindestens was SIP anbetrifft ?! Was denn nun ??Portweiterleitungen/Portforwarding ... aber das findet doch hier gar nicht statt?
Wie denkst du denn soll die vom Provider initiierte RTP Session mit einem Zufallsport dann dein NAT (Adress Translation) überwinden können ?!Nur so ganz verstehen kann ich es halt nicht
Nimm dir mal einen Wireshark oder die Paket Capturing Funktion im Diagnostics Menü und sieh dir mal genau solch eine Voice Session an. Das öffnet Horizonte ! 
dass die VLAN Geräte ausschließlich mit diesem Anbieter über die Ports kommunizieren können
Hast du ja oben schon richtig gemacht. Im Grunde reicht eine einfache DENY IP Regel auf alle RFC 1918 IP Netze von Souce VoiceVLAN und eine PASS all. So ist keinerlei Kommunikation mit lokalen Netzen möglich sondern nur ins Internet. Keep ist simple stupid. Das pfSense_Tutorial hat in den weiterführenden Links unter "VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall" noch einige Tips zu der Thematik.
Danke schonmal für die Antworten.
Der Screenshot oben sind die VLAN rules, nicht die WAN rules. Die sind leer bzw. Wireguard port ist erlaubt.
Leider ist diese SIP Geschichte anscheinend echt kompliziert überhaupt zu verstehen
einerseits könnte das so sein, andererseits ist aber im Firewall Log kein Deny zu sehen... Hatte den firewall Modus jetzt noch auf konservativ, das soll angeblich helfen.
Die Ports werden zwar zufällig geöffnet, aber lediglich in dem angegebenen Range. Soweit ich es verstanden habe, werden die Ports über den offenen Tunnel auf Port 5060 zwischen Server und Gerät kommuniziert. Kann mich aber auch irren.
Es ist lediglich eine Kommunikation von den Geräten im VLAN nach draußen über diese Ports zu dem Provider erlaubt. Viele verwenden auf LAN Interfaces allow all rules, sonst müsste man jede Software einzelnt freigeben. Das macht für mich im Privatbereich glaube ich keinen Sinn. Bei Geräten wie Kamerasysteme, IoT, Telefone .... möchte ich das aber nicht, da die Privatsphäre meiner Meinung nach durch diese Geräte stark gefährdet ist. Ich habe keine Kontrolle darüber, an welche Server diese Geräte noch so Daten senden, wenn ich alles erlauben würde.
Und genau wegen diesem "sicherheitstechnisch nicht so dolle" will ich auf der WAN Schnittstelle doch nicht nen Portrange von 20.000-50.000 freigeben?
Unter Portweiterleitung verstehe ich, dass ich einen Port von der WAN Schnittstelle an ein Gerät weiterreiche. Wenn mich eben von außen jemand auf 5060 anruft, wird diese Kommunikation an das Gerät weitergeleitet. Wenn ich die Ports auf der WAN Schnittstelle freigebe, dann verstehe ich eben nicht, was die Firewall überhaupt damit anfangen soll. In meinem Verständnis müsste dann ja jedes LAN Gerät gefragt werden, ob es gemeint ist?
Wenn ich z.B. einen VPN Tunnel von meinem Netzwerk als Client zu einem Server außerhalb erstelle, kann ich ja auch über diesen Tunnel über den verbundenen VPN Server mit anderen Geräten im Client Netzwerk kommunizieren, wenn das freigegeben ist. Das funktioniert auch komplett ohne Portfreigaben für außen, da die Verbindung aus dem Netzwerk heraus initiert wird. Das habe ich z.B. auf meinem Schiff, wo eben dank LTE keine Portfreigaben für einen eigenen VPN Server erlaubt sind.
Nach meinem Verständnis ist die Kommunikation möglich, wenn das LAN Gerät diese initiert. Nur kann kein Gerät von außen diese eigenständig initieren. Wenn das nicht so ist, dann dürfte ja gar nichts funktionieren ohne das ich alle Ports auf WAN freigebe?
Muss ich mal schauen. Nur leider kommt es relativ selten vor, dass die Verbindung nicht zu stande kommt. Nur wenn, ist es eben nervig.
Ja genau das will ich nicht. Deshalb habe ich ja auch anstelle IPV4 * * * * * .. nur Range 20000-50000 auf den Providerserver freigeben im VLAN selber.
Sowas hatte ich schon gelesen. Wenn man einen lokale PBX betreibt, wie z.b. eine Fritzbox, dann sieht die Welt wohl ganz anders aus und man muss wohl wirklich noch ein paar NAT Einstellungen oder auch Portweiterleitungen machen. Es handelt sich hier aber um einen Cloud Dienst. D.h. jedes Gerät kommuniziert eigenständig mit dem Anbieter. Alles weitere passiert auf deren Servern.
Der Screenshot oben sind die VLAN rules, nicht die WAN rules. Die sind leer bzw. Wireguard port ist erlaubt.
Leider ist diese SIP Geschichte anscheinend echt kompliziert überhaupt zu verstehen
Zitat von @aqui:
Das zeigt immer das deine RDP Ports nicht durchkommen, denn die reinen Voice Daten an sich werden über RTP übertragen. SIP ist lediglich die Signalisierung (klingeln, wählen usw.).
Das zeigt immer das deine RDP Ports nicht durchkommen, denn die reinen Voice Daten an sich werden über RTP übertragen. SIP ist lediglich die Signalisierung (klingeln, wählen usw.).
einerseits könnte das so sein, andererseits ist aber im Firewall Log kein Deny zu sehen... Hatte den firewall Modus jetzt noch auf konservativ, das soll angeblich helfen.
Was dich verwirrt und du vermutlich nicht auf dem Radar hast ist das RTP zufällige Ports eröffnet für die Voice Daten. Diese RTP Kommunikation baut auch der SIP Provider auf also nicht dein Endgerät.
Die Ports werden zwar zufällig geöffnet, aber lediglich in dem angegebenen Range. Soweit ich es verstanden habe, werden die Ports über den offenen Tunnel auf Port 5060 zwischen Server und Gerät kommuniziert. Kann mich aber auch irren.
Bei dir in der Range 20000-50000. Da du nicht weisst welcher müsstest du diese Portrange für RTP freigeben. Sicherheitstechnisch natürlich nicht besonders dolle.
Es ist lediglich eine Kommunikation von den Geräten im VLAN nach draußen über diese Ports zu dem Provider erlaubt. Viele verwenden auf LAN Interfaces allow all rules, sonst müsste man jede Software einzelnt freigeben. Das macht für mich im Privatbereich glaube ich keinen Sinn. Bei Geräten wie Kamerasysteme, IoT, Telefone .... möchte ich das aber nicht, da die Privatsphäre meiner Meinung nach durch diese Geräte stark gefährdet ist. Ich habe keine Kontrolle darüber, an welche Server diese Geräte noch so Daten senden, wenn ich alles erlauben würde.
Und genau wegen diesem "sicherheitstechnisch nicht so dolle" will ich auf der WAN Schnittstelle doch nicht nen Portrange von 20.000-50.000 freigeben?
Besser ist es dann immer mit STUN zu arbeiten, dann kann man solche Klimmzüge vermeiden.
Was für Klimmzüge? STUN muss ich mal nachlesen.Oben schreibst du aber etwas ganz anderes mit 5060 und 5061 zumindestens was SIP anbetrifft ?! Was denn nun ??
Der 5061 ist für die verschlüsselte Kommunikation mit dem Server (SIPS), wenn man das will. Wollte ich mal testen, wie die Verbindung dann ist. Die normale Kommunikation erfolgt immer über SIP 5060.Wie denkst du denn soll die vom Provider initiierte RTP Session mit einem Zufallsport dann dein NAT (Adress Translation) überwinden können ?!
Unter Portweiterleitung verstehe ich, dass ich einen Port von der WAN Schnittstelle an ein Gerät weiterreiche. Wenn mich eben von außen jemand auf 5060 anruft, wird diese Kommunikation an das Gerät weitergeleitet. Wenn ich die Ports auf der WAN Schnittstelle freigebe, dann verstehe ich eben nicht, was die Firewall überhaupt damit anfangen soll. In meinem Verständnis müsste dann ja jedes LAN Gerät gefragt werden, ob es gemeint ist?
Wenn ich z.B. einen VPN Tunnel von meinem Netzwerk als Client zu einem Server außerhalb erstelle, kann ich ja auch über diesen Tunnel über den verbundenen VPN Server mit anderen Geräten im Client Netzwerk kommunizieren, wenn das freigegeben ist. Das funktioniert auch komplett ohne Portfreigaben für außen, da die Verbindung aus dem Netzwerk heraus initiert wird. Das habe ich z.B. auf meinem Schiff, wo eben dank LTE keine Portfreigaben für einen eigenen VPN Server erlaubt sind.
Nach meinem Verständnis ist die Kommunikation möglich, wenn das LAN Gerät diese initiert. Nur kann kein Gerät von außen diese eigenständig initieren. Wenn das nicht so ist, dann dürfte ja gar nichts funktionieren ohne das ich alle Ports auf WAN freigebe?
Nimm dir mal einen Wireshark oder die Paket Capturing Funktion im Diagnostics Menü und sieh dir mal genau solch eine Voice Session an. Das öffnet Horizonte !
Muss ich mal schauen. Nur leider kommt es relativ selten vor, dass die Verbindung nicht zu stande kommt. Nur wenn, ist es eben nervig.
Hast du ja oben schon richtig gemacht. Im Grunde reicht eine einfache DENY IP Regel auf alle RFC 1918 IP Netze von Souce VoiceVLAN und eine PASS all. So ist keinerlei Kommunikation mit lokalen Netzen möglich sondern nur ins Internet. Keep ist simple stupid.
Ja genau das will ich nicht. Deshalb habe ich ja auch anstelle IPV4 * * * * * .. nur Range 20000-50000 auf den Providerserver freigeben im VLAN selber.
Das pfSense_Tutorial hat in den weiterführenden Links unter "VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall" noch einige Tips zu der Thematik.
Sowas hatte ich schon gelesen. Wenn man einen lokale PBX betreibt, wie z.b. eine Fritzbox, dann sieht die Welt wohl ganz anders aus und man muss wohl wirklich noch ein paar NAT Einstellungen oder auch Portweiterleitungen machen. Es handelt sich hier aber um einen Cloud Dienst. D.h. jedes Gerät kommuniziert eigenständig mit dem Anbieter. Alles weitere passiert auf deren Servern.
Die sind leer bzw. Wireguard port ist erlaubt.
Das reicht dann für die zufälligen RTP UDP Ports nicht.Soweit ich es verstanden habe, werden die Ports über den offenen Tunnel auf Port 5060 zwischen Server und Gerät kommuniziert. Kann mich aber auch irren.
Vermutlich ja, denn nun wirds wirr bei dir. Bedenke das das zwei unterschiedliche Protokolle und damit auch zwei völlig unterschiedliche und separate Baustellen sind nämlich SIP und RTP und jedes hat sein eigenes Protokollhandling. Nicht das du jetzt was wild durcheinanderbringst.Kollege @LordGurke hat es hier gut erklärt:
Pfsense mit easybell VoIP Cloud Anlage
VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Was für Klimmzüge?
Eine riesen RTP Range in der Firewall aufzumachen...dass ich einen Port von der WAN Schnittstelle an ein Gerät weiterreiche. Wenn mich eben von außen jemand auf 5060 anruft, wird diese Kommunikation an das Gerät weitergeleitet.
Das ist auch richtig... Es muss aber nicht immer ein Port Forwarding eingerichtet werden. Die meisten Telefone nutzen ein SIP Keepalive zum Provider. Senden also zyklisch Keepalive Frames. Diese halten die Session Table im NAT der Firewall auf so das eingehende SIP Calls dann auch ohne Port Forwarding immer die Telefone erreichen.Bei dir mit 2 oder mehr Telefonen hätte das Port Forwarding eh wenig Sinn, denn es gaht ja nur einmal pro Port (5060) bzw. für ein einziges Telefon.
Der Teufel liegt hier aber auch im Detail. Nutzt das Telefon UDP statt TCP fürs SIP "hält" die Session Table solche UDP Ports je nach Timer ca. 20 Sek. Kommt der Keepalive aber alle 45 Sekunden sind die Telefone immer zyklisch für 20 Sek, nicht erreichbar. Besser also man setzt SIP im Telefon Setup immer auf TCP Encapsulation.
Wenn man einen lokale PBX betreibt, wie z.b. eine Fritzbox, dann sieht die Welt wohl ganz anders aus
Nein, das ist Unsinn, denn so eine PBX macht nichts anderes als deine Telefone auch. Sie nutzt SIP und RTP. Das ist vollkommen gleich. Die Technik und Protokolle sind immer identisch. Solltest du eigentlich auch selber wissen ?!Ob man Cloud Dienste für vertrauliche Telefonate nutzen sollte ist dann wieder eine ganz andere Frage. Jemand der auf Datenschutz achtet macht das sicher nicht.
Zitat von @aqui:
Vermutlich ja, denn nun wirds wirr bei dir. Bedenke das das zwei unterschiedliche Protokolle und damit auch zwei völlig unterschiedliche und separate Baustellen sind nämlich SIP und RTP und jedes hat sein eigenes Protokollhandling. Nicht das du jetzt was wild durcheinanderbringst.
Das sind zwar angeblich zwei unterschiedliche Protokolle, aber laufen doch beide über UDP?Vermutlich ja, denn nun wirds wirr bei dir. Bedenke das das zwei unterschiedliche Protokolle und damit auch zwei völlig unterschiedliche und separate Baustellen sind nämlich SIP und RTP und jedes hat sein eigenes Protokollhandling. Nicht das du jetzt was wild durcheinanderbringst.
Kollege @LordGurke hat es hier gut erklärt:
Pfsense mit easybell VoIP Cloud Anlage
VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Pfsense mit easybell VoIP Cloud Anlage
VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Aber dort steht doch eigentlich genau das selbe ?
Da fragt der Walter doch,
"danke für Deine schnelle Antwort. Also kann ich quasi die Port Weiterleitungen der 3CX alle löschen und nicht weiter neu anlegen ? Ausgehend ist ja sowieso alles frei. Das wäre ja zu einfach um wahr zu sein.
face-smile"D.h. er hat doch auch keine Portfreigaben auf der WAN Schnittstelle?
Was für Klimmzüge?
Eine riesen RTP Range in der Firewall aufzumachen...es sind ausgehende Verbindung über diese Ports erlaubt aus dem VLAN heraus, nicht eingehend über die wan schnittstelle... d.h. das lan gerät kann die verbindung öffnen und halten, geräte von außen aber nicht.
Das ist auch richtig... Es muss aber nicht immer ein Port Forwarding eingerichtet werden. Die meisten Telefone nutzen ein SIP Keepalive zum Provider. Senden also zyklisch Keepalive Frames. Diese halten die Session Table im NAT der Firewall auf so das eingehende SIP Calls dann auch ohne Port Forwarding immer die Telefone erreichen.
genau so dachte ich mir das...
Bei dir mit 2 oder mehr Telefonen hätte das Port Forwarding eh wenig Sinn, denn es gaht ja nur einmal pro Port (5060) bzw. für ein einziges Telefon.
Der Teufel liegt hier aber auch im Detail. Nutzt das Telefon UDP statt TCP fürs SIP "hält" die Session Table solche UDP Ports je nach Timer ca. 20 Sek. Kommt der Keepalive aber alle 45 Sekunden sind die Telefone immer zyklisch für 20 Sek, nicht erreichbar. Besser also man setzt SIP im Telefon Setup immer auf TCP Encapsulation.
Der Teufel liegt hier aber auch im Detail. Nutzt das Telefon UDP statt TCP fürs SIP "hält" die Session Table solche UDP Ports je nach Timer ca. 20 Sek. Kommt der Keepalive aber alle 45 Sekunden sind die Telefone immer zyklisch für 20 Sek, nicht erreichbar. Besser also man setzt SIP im Telefon Setup immer auf TCP Encapsulation.
das ist wahrscheinlich wohl das Problem... angeblich gibts laut dem anderen Thread aber irgendeine Einstellung im Telefon "sym. RTP" .. muss ich gleich mal schauen.
Wenn man einen lokale PBX betreibt, wie z.b. eine Fritzbox, dann sieht die Welt wohl ganz anders aus
Nein, das ist Unsinn, denn so eine PBX macht nichts anderes als deine Telefone auch. Sie nutzt SIP und RTP. Das ist vollkommen gleich. Die Technik und Protokolle sind immer identisch. Solltest du eigentlich auch selber wissen ?!https://youtu.be/C0JgrzxXIBY?t=1521
Na laut dem Video aber schon? Aber wahrscheinlich habe ich wieder nur die hälfte verstanden ;)
Ob man Cloud Dienste für vertrauliche Telefonate nutzen sollte ist dann wieder eine ganz andere Frage. Jemand der auf Datenschutz achtet macht das sicher nicht.
na da kann man bestimmt lange drüber streiten. Wenn ich einen Trunk/Einzelrufnummer benutze, sehe ich nicht unbedingt ein geringeres Risiko als eine Cloud... beides kann irgendwo im Rechenzentrum sicherlich abgegriffen werden. Easybell ist auch kein Anbieter in China / USA. Die unterliegen ja Datenschutzregelungen aus Deutschland.. sprich die Polizei/andere Behörden dürfen alles mithören/speichern und wenn sie gehackt werden, pech. Beim Trunk aber genau das selbe Spiel?
Und diesen China Yealink Geräten traue ich ungefähr 0. Deswegen will ich denen auch kein Internet geben.
Muss ich wohl nochmal nen bisschen nachlesen... Das mit den Ports will nicht in meinen Kopf reingehen ;) .. aber danke trotzdem für die Anregungen.. vielleicht hat ja jemand anders noch ne Meinung zu Easybell/Nat/Ports
aber laufen doch beide über UDP?
Nope !Jedenfalls gilt das nicht für SIP: https://de.wikipedia.org/wiki/Session_Initiation_Protocol
nicht eingehend über die wan schnittstelle...
Es muss aber eingehend sein über WAN denn bei einem eingehenden Anruf macht der Provider ja die RTP Session auf !!Deswegen will ich denen auch kein Internet geben.
Ob die "nach Hause telefonieren" sagt dir ja der Wireshark oder die Packet Capture Option an der FW Das mit den Ports will nicht in meinen Kopf reingehen
https://de.wikipedia.org/wiki/Real-Time_Transport_Protocolhttps://www.3cx.de/voip-sip/rtp/
Zitat von @aqui:
Jedenfalls gilt das nicht für SIP: https://de.wikipedia.org/wiki/Session_Initiation_Protocol
aber laufen doch beide über UDP?
Nope !Jedenfalls gilt das nicht für SIP: https://de.wikipedia.org/wiki/Session_Initiation_Protocol
Hmm... jetzt bin ich noch verwirrter. Easybell gibt für beide an, dass es über UDP läuft.
nicht eingehend über die wan schnittstelle...
Es muss aber eingehend sein über WAN denn bei einem eingehenden Anruf macht der Provider ja die RTP Session auf !!In dem von dir geposteten Thread steht doch genau das Gegenteil?? Das ist ja noch verwirrender...
Zitat von @tikayevent:
Die Technik von Easybell kommt super mit NAT klar. Im Gegensatz zu anderen Anbietern haben die kein Problem mit NAT und passen sich super an.
Du musst nur dafür sorgen, dass die Telefone ausgehend durch die Firewall durchkommen, eingehend ist nicht notwendig, kein Portforwarding, keine Firewallöffnung, kein SIP-ALG oder -Proxy.
Die Technik von Easybell kommt super mit NAT klar. Im Gegensatz zu anderen Anbietern haben die kein Problem mit NAT und passen sich super an.
Du musst nur dafür sorgen, dass die Telefone ausgehend durch die Firewall durchkommen, eingehend ist nicht notwendig, kein Portforwarding, keine Firewallöffnung, kein SIP-ALG oder -Proxy.
Zitat von @LordGurke:
Wichtig ist lediglich (sonst funktioniert es auch mit easybell nicht), dass die Telefone wissen, dass sie hinter einem NAT sitzen und - das ist am wichtigsten - symmetrisches RTP machen. Mit symmetrischem RTP steht und fällt es
Manche Telefone senden ihren RTP-Stream auf Port X, empfangen ihn aber auf Port Y. In dieser Konstellation kommt dann die Sprache der Gegenstelle nicht durch das NAT.
Bei Symmetrischem RTP wird nur ein Port verwendet, auf dem gleichzeitig gesendet und empfangen wird. Dadurch, dass der Port in beide Richtungen genutzt wird, kommt dann auch der Traffic automatisch immer durch das NAT.
Das gilt aber nicht nur für easybell sondern für jeden VoIP-Anbieter. Dass Leute irgendwelche Port-Forwardings einstellen ist, wenn man diese beiden Einstellungen setzt, für Telefone und Telefonanlagen vollkommen unnötig
Wichtig ist lediglich (sonst funktioniert es auch mit easybell nicht), dass die Telefone wissen, dass sie hinter einem NAT sitzen und - das ist am wichtigsten - symmetrisches RTP machen. Mit symmetrischem RTP steht und fällt es
Manche Telefone senden ihren RTP-Stream auf Port X, empfangen ihn aber auf Port Y. In dieser Konstellation kommt dann die Sprache der Gegenstelle nicht durch das NAT.
Bei Symmetrischem RTP wird nur ein Port verwendet, auf dem gleichzeitig gesendet und empfangen wird. Dadurch, dass der Port in beide Richtungen genutzt wird, kommt dann auch der Traffic automatisch immer durch das NAT.
Das gilt aber nicht nur für easybell sondern für jeden VoIP-Anbieter. Dass Leute irgendwelche Port-Forwardings einstellen ist, wenn man diese beiden Einstellungen setzt, für Telefone und Telefonanlagen vollkommen unnötig
???????????
Deswegen will ich denen auch kein Internet geben.
Ob die "nach Hause telefonieren" sagt dir ja der Wireshark oder die Packet Capture Option an der FW Naja meiner Meinung nach gleich alles verbieten, dann muss ich auch nichts capturen ;)
Naja.. 3CX benötigt Portfreigaben, weil die wohl massive NAT Probleme haben (oder so)... das ist aber bekannt (man findet dazu zumindestens einiges im Internet), da die ja eher ihr eigenes Ding machen.
Zitat von @patrickstar2:
Hmm... jetzt bin ich noch verwirrter. Easybell gibt für beide an, dass es über UDP läuft.
https://www.easybell.de/hilfe/fragen/fragen-zum-telefonanschluss/antwort ...
In dem von dir geposteten Thread steht doch genau das Gegenteil?? Das ist ja noch verwirrender...
???????????
Naja meiner Meinung nach gleich alles verbieten, dann muss ich auch nichts capturen ;)
Naja.. 3CX benötigt Portfreigaben, weil die wohl massive NAT Probleme haben (oder so)... das ist aber bekannt (man findet dazu zumindestens einiges im Internet), da die ja eher ihr eigenes Ding machen.
aha... das wäre mir echt neu!Zitat von @aqui:
Jedenfalls gilt das nicht für SIP: https://de.wikipedia.org/wiki/Session_Initiation_Protocol
aber laufen doch beide über UDP?
Nope !Jedenfalls gilt das nicht für SIP: https://de.wikipedia.org/wiki/Session_Initiation_Protocol
Hmm... jetzt bin ich noch verwirrter. Easybell gibt für beide an, dass es über UDP läuft.
nicht eingehend über die wan schnittstelle...
Es muss aber eingehend sein über WAN denn bei einem eingehenden Anruf macht der Provider ja die RTP Session auf !!In dem von dir geposteten Thread steht doch genau das Gegenteil?? Das ist ja noch verwirrender...
Zitat von @tikayevent:
Die Technik von Easybell kommt super mit NAT klar. Im Gegensatz zu anderen Anbietern haben die kein Problem mit NAT und passen sich super an.
Du musst nur dafür sorgen, dass die Telefone ausgehend durch die Firewall durchkommen, eingehend ist nicht notwendig, kein Portforwarding, keine Firewallöffnung, kein SIP-ALG oder -Proxy.
Die Technik von Easybell kommt super mit NAT klar. Im Gegensatz zu anderen Anbietern haben die kein Problem mit NAT und passen sich super an.
Du musst nur dafür sorgen, dass die Telefone ausgehend durch die Firewall durchkommen, eingehend ist nicht notwendig, kein Portforwarding, keine Firewallöffnung, kein SIP-ALG oder -Proxy.
Zitat von @LordGurke:
Wichtig ist lediglich (sonst funktioniert es auch mit easybell nicht), dass die Telefone wissen, dass sie hinter einem NAT sitzen und - das ist am wichtigsten - symmetrisches RTP machen. Mit symmetrischem RTP steht und fällt es
Manche Telefone senden ihren RTP-Stream auf Port X, empfangen ihn aber auf Port Y. In dieser Konstellation kommt dann die Sprache der Gegenstelle nicht durch das NAT.
Bei Symmetrischem RTP wird nur ein Port verwendet, auf dem gleichzeitig gesendet und empfangen wird. Dadurch, dass der Port in beide Richtungen genutzt wird, kommt dann auch der Traffic automatisch immer durch das NAT.
Das gilt aber nicht nur für easybell sondern für jeden VoIP-Anbieter. Dass Leute irgendwelche Port-Forwardings einstellen ist, wenn man diese beiden Einstellungen setzt, für Telefone und Telefonanlagen vollkommen unnötig
Wichtig ist lediglich (sonst funktioniert es auch mit easybell nicht), dass die Telefone wissen, dass sie hinter einem NAT sitzen und - das ist am wichtigsten - symmetrisches RTP machen. Mit symmetrischem RTP steht und fällt es
Manche Telefone senden ihren RTP-Stream auf Port X, empfangen ihn aber auf Port Y. In dieser Konstellation kommt dann die Sprache der Gegenstelle nicht durch das NAT.
Bei Symmetrischem RTP wird nur ein Port verwendet, auf dem gleichzeitig gesendet und empfangen wird. Dadurch, dass der Port in beide Richtungen genutzt wird, kommt dann auch der Traffic automatisch immer durch das NAT.
Das gilt aber nicht nur für easybell sondern für jeden VoIP-Anbieter. Dass Leute irgendwelche Port-Forwardings einstellen ist, wenn man diese beiden Einstellungen setzt, für Telefone und Telefonanlagen vollkommen unnötig
???????????
Deswegen will ich denen auch kein Internet geben.
Ob die "nach Hause telefonieren" sagt dir ja der Wireshark oder die Packet Capture Option an der FW Naja meiner Meinung nach gleich alles verbieten, dann muss ich auch nichts capturen ;)
Naja.. 3CX benötigt Portfreigaben, weil die wohl massive NAT Probleme haben (oder so)... das ist aber bekannt (man findet dazu zumindestens einiges im Internet), da die ja eher ihr eigenes Ding machen.
wir haben 2021 etwa 60 stück 3CX Anlagen eingerichtet, und hatten nicht ein NAT Problem!
Frank
...und hatten nicht ein NAT Problem!
Wenn sie es hätten, hätten es Millionen andere Anlagen beliebiger Hersteller auch. Alle nutzen das gleiche Protokoll und Technik. Der Einwand ist natürlich Unsinn...
Habe das ganze jetzt noch mal in verschiedenen Konstellationen durchgespielt..
eingehende Freigaben auf WAN scheinen sinnlos zu sein, ich kann nicht nachvollziehen was das bringen soll... Mit einem Telefon/Telefonanlage kann man vielleicht noch eine explizite Portweiterleitung definieren, aber mit mehreren Telefonen? Kann nicht verstehen wie das funktionieren soll.
Ich habe zum Test einfach alle eingehenden TCP/UDP Ports von den Easybell IPs freigegeben. In den States war zu sehen, dass manchmal wirklich seitens Easybell eine Verbindung initiert wurde (nachdem ich die States resettet habe). Jedoch ohne jegliches Ziel im eigentlichen Netzwerk. Unter States war nur Single No Traffic zu sehen. Nach einiger Zeit hat das Telefon wieder die Ports geöffnet... Nur das Telefon selber initiert die Verbindung..
TCP wird ebenfalls NIE verwendet. Nur UDP.
Ebenfalls habe ich gesehen, dass Easybell manchmal Ports ausserhalb des angegeben Ranges verwendet.. da hilft dann wohl wirklich nur dem Telefon alle ausgehenden Ports zu erlauben.
Hab jetzt im Telefon NAT Keepalive noch auf 20 reduziert, in pfsense ist glaube ich für UDP 30 eingestellt... sollte also theoretisch passen. Hab die letzten Tage immer mal wieder random das Telefon probiert anzurufen, alle Anrufe kamen durch... Vielleicht waren die Gespräche ohne Audio wirklich nur dem definierten Portrange geschuldet.. muss ich mal weiter testen.
Die paar 100tel Sekunden Delay lassen sich wohl nur schwer in den Griff bekommen. Anrufe zu Telekom Mobil/Festnetz leiden deutlich weniger als z.B. Vodafone. Anrufe zu Easybell selber haben gar kein Delay... fällt wohl auch nur auf wenn man sich selber anruft.
Insgesamt bin ich aber ganz zufrieden. Selbst wenn ich die Glasfaser Leitung rausziehe und die pfsense auf Unitymedia/Vodafone Cable failover geht, kann nach kurzer Zeit wieder telefoniert werden(eingehend) und zwar ohne, dass erst das Telefon einen rausgehenden Anruf tätigt. Das hab ich bei 3CX nicht hinbekommen, obwohl alles so eingestellt war wie die in ihren Hilfeseiten beschrieben haben. Und nein ich will nicht sagen dass es mit 3CX nicht geht, sondern das ICH es nicht geschafft habe es zu realisieren.
eingehende Freigaben auf WAN scheinen sinnlos zu sein, ich kann nicht nachvollziehen was das bringen soll... Mit einem Telefon/Telefonanlage kann man vielleicht noch eine explizite Portweiterleitung definieren, aber mit mehreren Telefonen? Kann nicht verstehen wie das funktionieren soll.
Ich habe zum Test einfach alle eingehenden TCP/UDP Ports von den Easybell IPs freigegeben. In den States war zu sehen, dass manchmal wirklich seitens Easybell eine Verbindung initiert wurde (nachdem ich die States resettet habe). Jedoch ohne jegliches Ziel im eigentlichen Netzwerk. Unter States war nur Single No Traffic zu sehen. Nach einiger Zeit hat das Telefon wieder die Ports geöffnet... Nur das Telefon selber initiert die Verbindung..
TCP wird ebenfalls NIE verwendet. Nur UDP.
Ebenfalls habe ich gesehen, dass Easybell manchmal Ports ausserhalb des angegeben Ranges verwendet.. da hilft dann wohl wirklich nur dem Telefon alle ausgehenden Ports zu erlauben.
Hab jetzt im Telefon NAT Keepalive noch auf 20 reduziert, in pfsense ist glaube ich für UDP 30 eingestellt... sollte also theoretisch passen. Hab die letzten Tage immer mal wieder random das Telefon probiert anzurufen, alle Anrufe kamen durch... Vielleicht waren die Gespräche ohne Audio wirklich nur dem definierten Portrange geschuldet.. muss ich mal weiter testen.
Die paar 100tel Sekunden Delay lassen sich wohl nur schwer in den Griff bekommen. Anrufe zu Telekom Mobil/Festnetz leiden deutlich weniger als z.B. Vodafone. Anrufe zu Easybell selber haben gar kein Delay... fällt wohl auch nur auf wenn man sich selber anruft.
Insgesamt bin ich aber ganz zufrieden. Selbst wenn ich die Glasfaser Leitung rausziehe und die pfsense auf Unitymedia/Vodafone Cable failover geht, kann nach kurzer Zeit wieder telefoniert werden(eingehend) und zwar ohne, dass erst das Telefon einen rausgehenden Anruf tätigt. Das hab ich bei 3CX nicht hinbekommen, obwohl alles so eingestellt war wie die in ihren Hilfeseiten beschrieben haben. Und nein ich will nicht sagen dass es mit 3CX nicht geht, sondern das ICH es nicht geschafft habe es zu realisieren.
moin..
die Telefone machen das von innen sozusagen selber!
Ich habe zum Test einfach alle eingehenden TCP/UDP Ports von den Easybell IPs freigegeben. In den States war zu sehen, dass manchmal wirklich seitens Easybell eine Verbindung initiert wurde (nachdem ich die States resettet habe). Jedoch ohne jegliches Ziel im eigentlichen Netzwerk. Unter States war nur Single No Traffic zu sehen. Nach einiger Zeit hat das Telefon wieder die Ports geöffnet... Nur das Telefon selber initiert die Verbindung..
richtig, in deinem fall baut das Telefon die verbindung auf, und hält die verbindung offen!
TCP wird ebenfalls NIE verwendet. Nur UDP.
jo..
Ebenfalls habe ich gesehen, dass Easybell manchmal Ports ausserhalb des angegeben Ranges verwendet.. da hilft dann wohl wirklich nur dem Telefon alle ausgehenden Ports zu erlauben.
Hab jetzt im Telefon NAT Keepalive noch auf 20 reduziert, in pfsense ist glaube ich für UDP 30 eingestellt... sollte also theoretisch passen. Hab die letzten Tage immer mal wieder random das Telefon probiert anzurufen, alle Anrufe kamen durch... Vielleicht waren die Gespräche ohne Audio wirklich nur dem definierten Portrange geschuldet.. muss ich mal weiter testen.
Die paar 100tel Sekunden Delay lassen sich wohl nur schwer in den Griff bekommen. Anrufe zu Telekom Mobil/Festnetz leiden deutlich weniger als z.B. Vodafone. Anrufe zu Easybell selber haben gar kein Delay... fällt wohl auch nur auf wenn man sich selber anruft.
Insgesamt bin ich aber ganz zufrieden. Selbst wenn ich die Glasfaser Leitung rausziehe und die pfsense auf Unitymedia/Vodafone Cable failover geht, kann nach kurzer Zeit wieder telefoniert werden(eingehend) und zwar ohne, dass erst das Telefon einen rausgehenden Anruf tätigt. Das hab ich bei 3CX nicht hinbekommen, obwohl alles so eingestellt war wie die in ihren Hilfeseiten beschrieben haben. Und nein ich will nicht sagen dass es mit 3CX nicht geht, sondern das ICH es nicht geschafft habe es zu realisieren.
dabei ist die 3CX sehr einfach... wenn es jetzt aber geht, ist ja alles prima
Frank
Zitat von @patrickstar2:
Habe das ganze jetzt noch mal in verschiedenen Konstellationen durchgespielt..
eingehende Freigaben auf WAN scheinen sinnlos zu sein, ich kann nicht nachvollziehen was das bringen soll... Mit einem Telefon/Telefonanlage kann man vielleicht noch eine explizite Portweiterleitung definieren, aber mit mehreren Telefonen? Kann nicht verstehen wie das funktionieren soll.
nun, ohne eigene Telefon Anlage, brachst du keine port weiterleitung!Habe das ganze jetzt noch mal in verschiedenen Konstellationen durchgespielt..
eingehende Freigaben auf WAN scheinen sinnlos zu sein, ich kann nicht nachvollziehen was das bringen soll... Mit einem Telefon/Telefonanlage kann man vielleicht noch eine explizite Portweiterleitung definieren, aber mit mehreren Telefonen? Kann nicht verstehen wie das funktionieren soll.
die Telefone machen das von innen sozusagen selber!
Ich habe zum Test einfach alle eingehenden TCP/UDP Ports von den Easybell IPs freigegeben. In den States war zu sehen, dass manchmal wirklich seitens Easybell eine Verbindung initiert wurde (nachdem ich die States resettet habe). Jedoch ohne jegliches Ziel im eigentlichen Netzwerk. Unter States war nur Single No Traffic zu sehen. Nach einiger Zeit hat das Telefon wieder die Ports geöffnet... Nur das Telefon selber initiert die Verbindung..
TCP wird ebenfalls NIE verwendet. Nur UDP.
Ebenfalls habe ich gesehen, dass Easybell manchmal Ports ausserhalb des angegeben Ranges verwendet.. da hilft dann wohl wirklich nur dem Telefon alle ausgehenden Ports zu erlauben.
Hab jetzt im Telefon NAT Keepalive noch auf 20 reduziert, in pfsense ist glaube ich für UDP 30 eingestellt... sollte also theoretisch passen. Hab die letzten Tage immer mal wieder random das Telefon probiert anzurufen, alle Anrufe kamen durch... Vielleicht waren die Gespräche ohne Audio wirklich nur dem definierten Portrange geschuldet.. muss ich mal weiter testen.
Die paar 100tel Sekunden Delay lassen sich wohl nur schwer in den Griff bekommen. Anrufe zu Telekom Mobil/Festnetz leiden deutlich weniger als z.B. Vodafone. Anrufe zu Easybell selber haben gar kein Delay... fällt wohl auch nur auf wenn man sich selber anruft.
Insgesamt bin ich aber ganz zufrieden. Selbst wenn ich die Glasfaser Leitung rausziehe und die pfsense auf Unitymedia/Vodafone Cable failover geht, kann nach kurzer Zeit wieder telefoniert werden(eingehend) und zwar ohne, dass erst das Telefon einen rausgehenden Anruf tätigt. Das hab ich bei 3CX nicht hinbekommen, obwohl alles so eingestellt war wie die in ihren Hilfeseiten beschrieben haben. Und nein ich will nicht sagen dass es mit 3CX nicht geht, sondern das ICH es nicht geschafft habe es zu realisieren.
Frank
TCP wird ebenfalls NIE verwendet. Nur UDP.
Nicht bei SIP. SIP ist für beides spezifiziert ! Die FritzBox z.B. supportet mit neuerer Firmware z.B. ausschliesslich nur noch TCP Encapsulation bei SIP !Wenn's das denn nun war bitte nicht vergessen den Thread hier als gelöst zu markieren !
How can I mark a post as solved?
