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...

easybell vlan


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

Content-Key: 1378347813

Url: https://administrator.de/contentid/1378347813

Ausgedruckt am: 24.10.2021 um 14:10 Uhr

Mitglied: Vision2015
Vision2015 12.10.2021 um 06:39:36 Uhr
Goto Top
Moin...

natürlich soll das auf dem WAN port gemacht werden!

Frank
Mitglied: patrickstar2
patrickstar2 12.10.2021 aktualisiert um 10:03:32 Uhr
Goto Top
@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 ?
Mitglied: aqui
aqui 12.10.2021 aktualisiert um 10:06:14 Uhr
Goto Top
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 ! ;-) face-wink
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. ;-) face-wink
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.
Mitglied: patrickstar2
patrickstar2 12.10.2021 aktualisiert um 11:03:20 Uhr
Goto Top
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 :( face-sad

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.).

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 ! ;-) face-wink

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. ;-) face-wink

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.
Mitglied: aqui
aqui 12.10.2021 um 11:11:57 Uhr
Goto Top
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:
https://administrator.de/forum/pfsense-easybell-voip-cloud-anlage-665346 ...
https://administrator.de/content/detail.php?id=426334&token=259
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.
Mitglied: patrickstar2
patrickstar2 12.10.2021 aktualisiert um 12:38:19 Uhr
Goto Top
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?



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 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.

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
Mitglied: aqui
aqui 12.10.2021 um 12:58:20 Uhr
Goto Top
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 ;-) face-wink
Das mit den Ports will nicht in meinen Kopf reingehen
https://de.wikipedia.org/wiki/Real-Time_Transport_Protocol
https://www.3cx.de/voip-sip/rtp/
Mitglied: patrickstar2
patrickstar2 12.10.2021 aktualisiert um 14:43:51 Uhr
Goto Top
Zitat von @aqui:

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.
ports
https://www.easybell.de/hilfe/fragen/fragen-zum-telefonanschluss/antwort ...

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.

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 ;-) face-wink
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 ;-) face-wink


???????????

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 ;-) face-wink

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.
Mitglied: Vision2015
Vision2015 12.10.2021 um 17:03:02 Uhr
Goto Top
Zitat von @patrickstar2:

Zitat von @aqui:

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.
ports
https://www.easybell.de/hilfe/fragen/fragen-zum-telefonanschluss/antwort ...

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.

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 ;-) face-wink
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 ;-) face-wink


???????????

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 ;-) face-wink

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!
wir haben 2021 etwa 60 stück 3CX Anlagen eingerichtet, und hatten nicht ein NAT Problem!

Frank
Mitglied: aqui
aqui 12.10.2021 aktualisiert um 17:08:37 Uhr
Goto Top
...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...
Mitglied: patrickstar2
patrickstar2 17.10.2021 aktualisiert um 13:35:07 Uhr
Goto Top
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.
Mitglied: Vision2015
Vision2015 17.10.2021 um 14:23:51 Uhr
Goto Top
moin..
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!
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 :-) face-smile

Frank
Mitglied: aqui
aqui 17.10.2021 aktualisiert um 15:27:49 Uhr
Goto Top
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 !
https://administrator.de/faq/32
Heiß diskutierte Beiträge
question
ASUS H110M-A - TPM-Funktion im BIOS? gelöst SarekHLVor 1 TagFrageCPU, RAM, Mainboards15 Kommentare

Hallo zusammen, weiß jemand sicher, ob das ASUS H110M-A/M.2 eine TPM-Funktion/Emulation im BIOS hat? Hier ist das Board ganz unten als Win11-kompatibel aufgeführt, aber während ...

question
Sfp 100Mbit Switch gesuchtjonasgrafeVor 1 TagFrageSwitche und Hubs16 Kommentare

Hi zusammen, Bei uns der Firma ist heute Nacht ein Einsteckmodul (Lwl SC) von einem Siemens Scalance Switch gestorben. Über diese Module besteht eine Verbindung ...

question
PC zeigt kein Bild mehrben1300Vor 23 StundenFrageHardware12 Kommentare

Hallo zusammen, mein PC geht zwar noch an (LED leuchten und Lüfter laufen), aber ich erhalte kein Bild mehr. Mainboard: MSI B450M Mortar Max Mainboard ...

question
PfSense nach Änderung von "Block private networks and loopback addresses" nicht mehr erreichbarvafk18Vor 1 TagFrageRouter & Routing5 Kommentare

Ich habe an meiner pfSense am entfernten Standort in den WAN-Einstellungen den Haken bei "Block private networks and loopback addresses" gelöscht. Nach dem Bestätigen war ...

question
Browserverhalten bei nicht offizieller TLD im privaten NetzSiegfried36Vor 16 StundenFrageDNS17 Kommentare

Moin, ich hoffe ihr könnt mir helfen Licht ins Dunkel zu bringen. So ganz verstehe ich diesen ganzen Zusammenhang nicht. Ich will in meinem internen ...

question
Jeder druckjob (auf WTS) soll im eventvwr.msc vermerkt werdenManuManu2021Vor 1 TagFrageMicrosoft2 Kommentare

Hallo, die User arbeiten mit TS Server und versenden via Warenwirtschaft mittels Datei/Drucken/Tobit-Faxware-Drucker einzelne Briefe. (ca. 2000 pro monat ausgehend, kein Newsletter) Manchmal funktioniert der ...

question
Prüfen ob Befehl in Variable true zurück gibt gelöst zuzuelqVor 1 TagFrageBatch & Shell7 Kommentare

Hallo liebe Gemeinde, sonst stiller Leser nun Fragender (Powershellbeginner). Steinigt mich bitte nicht, aber ich habe mir die gestrige Nacht um die Ohren geschlagen, und ...

question
JBOD - Platte kopieren möglich?DoKi468Vor 15 StundenFrageFestplatten, SSD, Raid1 Kommentar

Hallo zusammen, eine Frage: Ich habe eine Synology NAS und habe dort ein JBOD eingerichtet mit 2 4TB Platten Allerdings springt bei einer Platte teilweise ...