pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss

ramup

Hallo mike69,
der von dir verlinkte Artikel hat leider nichts mit meinem anliegen gemeinsam. Dort geht es um einen ISDN-Adpater.

Mir geht es darum eine IP-fähige Anlage an einem Telekom SIP-Trunk Anschluss in der pfSense zu konfigurieren.

ramup

Hallo,
ich versuche es jetzt noch einmal. In der pfSense habe ich die UDP Timouts auf moderatere Werte gestellt.
In dem Thread für VoIP für Privatkunden wird empfohlen folgende NAT Regel zu erstellen:

Interface: WAN Protocol: UDP Source: IP/Alias des Telefons/FritzBox
Address: Interface Address Port: Static Port anhaken

Ich denke diese NAT Regel wird bei SIP-Trunk nicht funktionieren. Im technischen Handbuch der Telekom steht unter anderem:

"Es wird empfohlen, kein statisches Port-Mapping zu verwenden, sondern dynamisches Pinholing in Kombination mit Keep-Alive."

Kann mir das jemand in "pfSense deutsch" übersetzen? So wie ich es verstehe, funktioniert das Ganze mit der "Normalen" Automatic NAT Rule? Oder was ist dynamisches Pinholing? Keep-Alive betrifft ja dann eher die Telefonanlage meinem Verständnis nach.

Auszüge aus dem Handbuch:

5.5 siP oVer tcP (kein udP)
Der SIP-Trunk-Dienst der Telekom unterstützt ausschließlich TCP für die SIP-Signalisierung. UDP wird (im Gegensatz zu den Privatkundenprodukten der Telekom) nicht unterstützt. Nicht alle TK-Anlagen und SIP-Clients der Telekom unterstützen dies per Default.
Die Sprachdaten (RTP) werden über UDP übertragen!

5.6 stun
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung.
• Hierfür muss die TK-Anlage symmetrisches RTP unterstützen, d.h. bei ein- und ausgehenden Gesprächen muss die TK-Anlage den RTP-Strom selbst als erstes aufbauen. Nach drei eingegangen RTP-Paketen erkennt die Plattform den Datenstrom und baut ihrerseits zur selben Port (und IP) eine RTP-Verbindung auf. Die Erkennung basiert auf der abgehenden IP (aus dem SIP-Paket) desangesprochenenTelekomGateways(ausdemSDP)unddenangesprochenenGateway-IP-Ports(SDP). WeitereAngaben im SDP (insb. TK-seitige IPs und Ports) werden ignoriert.
• STUN „torpediert“ diese NAT-Erkennung, da die Plattform NAT nicht mehr erkennen kann.
• Wenn STUN zum Einsatz kommt, muss aus jeden Fall sichergestellt sein, dass eingehende RTP-Verbindungen akzeptiert werden (mit einer normalen NAT-Firewall ist dies normalerweise nicht möglich), da die Plattform kein symmetrisches RTP
anwendet.
• STUN sollte daher nur in Ausnahmefällen eingesetzt werden.
• Mit symmetrischen NAT ist eine Verbindung in Verbindung mit STUN in der Regel gar nicht möglich. Einige Router (z.B. Bintec)
bieten aber mittels eines Assistenten die Möglichkeit, auf "Full Cone" NAT umzustellen. Damit ist dann eine Verbindung auch möglich, wenn die TK-Anlage STUN erzwingt.

5.7 symmetrisches rtP / nAt-erkennung /stun
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung. Hierfür muss die TK-Anlage symmetrisches RTP unterstützen. STUN „torpediert“ diese NAT-Erkennung und sollte nur in Ausnahmefällen eingesetzt werden.

11.3 iP & Port-rAnges
Für vom Kunden initiierte Verbindungen zu SP-SSEs der Deutschen Telekom werden die in Kapitel 5.7 genannten Zielports verwendet:
Da jede Verbindung vom Client initiiert und am Leben erhalten werden soll, werden TCP-Sitzungen auf Basis von RFC5923 wiederverwendet. NAT-Pinholing- und Firewall-Richtlinien sollten für diese einzelne Sitzung dynamisch durch das erste TCP-Paket festgelegt werden.
Der Quellport für RTP wird durch die PBX definiert und es wird davon ausgegangen, dass alle NAT-Bindungs- und Firewall-Regeln durch die ursprünglichen ausgehenden RTP-Pakete festgelegt werden. Der Ziel-Port für die RTP-Payload wird innerhalb des SDP- Angebots/Antwort von SP-SSE definiert.
Es wird empfohlen, für RTP und RTCP ein aufeinander folgendes Paar Ports gemäß RFC 3550 zu verwenden. Auch das RTCP- Attribut in SDP wird gemäß RFC 3605 unterstützt.
Da symmetrisches RTP verwendet wird, ist es nicht notwendig, Ports für eingehenden Datenverkehr zu konfigurieren.
Es wird empfohlen, kein statisches Port-Mapping zu verwenden, sondern dynamisches Pinholing in Kombination mit Keep-Alive.
Wenn Sie den Static Mode verwenden, müssen Sie Ihren listening port für SIP definieren. Die Verwendung des Static Mode ohne vom Client initiierte Verbindungen würde zu einem hohen Risiko eines Pinhole für die SIP-Kommunikation führen. Aufgrund hochskalierbarer Cluster von SP-SSEs der Deutschen Telekom ist es nicht geeignet, die Quell-IPs der Deutschen Telekom einzuschränken. Es ist vorzuziehen, stattdessen Client-initiierte Verbindungen zu verwenden und jeglichen eingehenden Datenverkehr außer dieser Verbindung zu blockieren.
Bitte beachten Sie, dass die Deutsche Telekom über verschiedene Mechanismen verfügt, um jede Art von Missbrauch zu vermeiden. Daher ist es nicht erlaubt, beliebig viele TCP-Sessions einzurichten (z.B. eine separate TCP-Session für jeden Anruf / INVITE), da die Anzahl der TCP-Sessions auf fünf pro IP-Adresse beschränkt ist.

11.4 stun
STUN sowie TURN und ICE werden für DeutschlandLAN SIP-Trunk nicht unterstützt. Diese führen dauerhaft zu Problemen - z.B. bei der Verwendung von symmetrischem NAT - , daher wird dringend empfohlen, diese Funktionen nicht zu nutzen. Bitte beachten Sie die Hinweise zu STUN in Kapitel 5.5.
Konkret führt die Verwendung von STUN dazu, dass die IP-Adressen im TCP mit den IP-Adressen im SDP übereinstimmen. Daher kann die SP-SSE nicht mehr feststellen, ob NAT vorliegt und führt dementsprechend auch kein symmetrisches RTP mehr durch.
Bitte beachten Sie die Empfehlung für NAT (siehe Kapitel 5.5 ff.), um Schwierigkeiten durch die private Netzwerktopologie zu überwinden.
Bitte beachten Sie:
Einige ältere vordefinierte Konfigurationsvorlagen sowie einige Vorlagen für Retail und DeutschlandLAN IP Voice/Data enthalten Einstellungen für STUN. Diese Vorlagen sollten nicht verwendet werden und durch Firmware-Updates der SIP-PBX-Hersteller ersetzt werden. Alternativ können Sie versuchen, es im Setup zu deaktivieren, wenn Probleme auftreten.

11.5 nAt trAVersAl
Durch die Verknüpfung des lokalen Netzwerks (LAN) des Unternehmens mit dem Wide Area Network (WAN) ist die Verwendung von Network Address Translation (NAT) eine gängige und weit verbreitete Methode. RFC 3489, Kapitel 5.5 ff., gibt einen groben Überblick über die relevanten NAT-Typen. Dennoch kann das spezifische NAT-Verhalten der PBX-Anbieter variieren.
Diese Mechanismen führen häufig zu Ausfällen der SIP-Kommunikation, da SIP IP-Adressen und Transportportnummern verwendet werden, die in Header (z.B. SDP) und verschiedenen Header-Feldern kodiert sind. Im LAN enthaltene Telefonanlagen verwenden ihre private lokale IP-Adresse für diesen Header, es sei denn, sie haben Informationen über das IP- und Port-Mapping in das Internet. Ohne diese Adressen und Ports sind die in Headern gesendeten Informationen im Prinzip unbrauchbar. Es wurden Mechanismen eingeführt, um Informationen über die öffentlich erreichbaren IP- und Transportports zu erhalten, wie Session Traversal Utilities for NAT (STUN, RFC 5389), Traversal Using Relays around NAT (TURN, RFC 5766) oder Interactive Connectivity Establishment (ICE,
29 Deutsche Telekom AG | Oktober 2018
DeutschlandLAN SIP-Trunk | Technische Unterlage
RFC 5245). Aber sie sind unzuverlässig und leiden unter einer Reihe von Problemen, insbesondere bei einigen NAT-Typen (z.B. symmetrisches NAT).
DeutschlandLAN SIP-Trunk bietet einen ausgeklügelten Mechanismus für Hosted NAT Traversal. Dieser Mechanismus sucht nach vorhandenen IP-Bindungen zur TK-Anlage und ermittelt die vermutete IP-Adresse und den Transportport anhand des Registrierungskontextes, des Kontaktheaders aus SIP und der Medieninformationen aus SDP oder identifiziert die Quelle anhand der IP-Header-Informationen.
Durch diesen Mechanismus ist jeder NAT-Traversal-Mechanismus an der TK-Anlage überflüssig. STUN, TURN und ICE werden von SIP-Trunking NGN selbst nicht unterstützt, da unbeabsichtigte Nebenwirkungen auftreten können. Wichtig ist, dass alle Protokolle beim Kunden deaktiviert sind.
Auch die Verwendung dieser Mechanismen von anderen Servern wird ausdrücklich nicht empfohlen.
Gemäß 1TR118 sollen SIP UAs, die ihre öffentliche IP-Adresse und Informationen über öffentliche Ports kennen, diese Informationen in VIA und CONTACT-Header senden. Die IPv4-Adresse muss in ihrem oktalen Format dargestellt werden. In IPv6 soll dies RFC 4291 entsprechen.
SIP UAs, die die öffentliche IP-Adresse und Informationen über den öffentlichen Port nicht kennen, senden eine private IP-Adresse (RFC 1918) in VIA und CONTACT-Header. In diesem Fall aktiviert SIP-Trunk eine NAT-Traversal-Funktion und sendet SIP- Nachrichten an den SIP UA mit dem gleichen Transportprotokoll auf der gleichen IP-Adresse und Portnummer wie vom Benutzer empfangen.
Media Sessions müssen die gleichen IP-Adressen verwenden, die auch für die SIP-Signalisierung verwendet werden. Wird eine private Adresse im Kontakt-Header angegeben, dann ignoriert die NAT-Traversal-Helper-Funktion alle m=-Zeilen- oder c=- Zeileninformationen mit Transport IP-Adressen und Portnummern. Die Call-Control verwendet die von der SIP-Signalisierung verwendete IP-Adresse und sendet Medien an diese IP-Adresse. Bei der NAT-Traversal-Funktion wird die Portnummer des zu sendenden Mediums durch das erste vom SIP UE empfangene RTP-Paket bestimmt. In diesem Fall muss SIP UE nach dem Abrufen oder Erzeugen einer SDP-Antwort Medienströme mit mindestens drei RTP-Paketen senden, auch wenn keine Medien abgespielt werden. Inaktive, nur sendende oder nur empfangende Attribute sollten dabei ignoriert werden.

tpf

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Hallo,
ich versuche es jetzt noch einmal. In der pfSense habe ich die UDP Timouts auf moderatere Werte gestellt.
In dem Thread für VoIP für Privatkunden wird empfohlen folgende NAT Regel zu erstellen:

Interface: WAN Protocol: UDP Source: IP/Alias des Telefons/FritzBox
Address: Interface Address Port: Static Port anhaken

Ich denke diese NAT Regel wird bei SIP-Trunk nicht funktionieren. Im technischen Handbuch der Telekom steht unter anderem:

"Es wird empfohlen, kein statisches Port-Mapping zu verwenden, sondern dynamisches Pinholing in Kombination mit Keep-Alive."

Kann mir das jemand in "pfSense deutsch" übersetzen? So wie ich es verstehe, funktioniert das Ganze mit der "Normalen" Automatic NAT Rule? Oder was ist dynamisches Pinholing? Keep-Alive betrifft ja dann eher die Telefonanlage meinem Verständnis nach.

Servus,
vermutlich geht es um einen ggü der Telekom-SIP-Server geöffneten Port, schätzungsweise 5060.
Also eingehend TCP/UDP von TELEKOM an WAN-Adresse auf 5060.

In der normalen Konfig eines SIP-Anschlusses wird von innen zur Telekom eine Verbindung aufgebaut und über den Rückweg seitens Telefkom dann auch z.B. die Anrufsignalisierung geschickt.

Zum Verzicht auf static port kann ich nichts sagen. Ich habe das bisher bei ausnahmslos allen Anschlüssen benötigt. Allerdings war da bisher kein Trunk dabei. Rein technisch sehe ich aktuell nicht, warum das nicht notwendig sein soll. Es geht schließlich darum, den RTP-Stream nicht zu unterbrechen. Zumindest ist das mein Kenntnissstand.

Ich stehe in einigen Wochen aber vor genau der gleichen Situation: 4-B-Kanäle werden auf SIP-Trunk umgestellt.

ramup

Hallo tpf,

vielen Dank für deine Stellungnahme. Da wir wahrscheinlich erst etwas später umgestellt werden, wäre ich dir sehr dankbar, wenn du danach die NAT-Konfiguration posten könntest, die dann funktioniert hat (wenn es denn funktioniert ;D).
Entspricht bei dir die Konfiguration auch gemäß Ziffer 3.2 des oben genannten Dokumentes, also 1 IP-Telefonanlage die sich mit 1 lokalen IP über pfSense mit der Telekom verbindet?
Wir setzen Systemtelefone der Anlage ein, also managed die Telefonanlage die Verbindung mit der Telekom und nicht einzelne Telefone.

Sofern ich vorher etwas seitens der Telekom in Erfahrung bringe, werde ich es hier ebenfalls posten.

slu

Was für eine PBX ist es denn?
Wir haben hier den SIP Trunk der Telekom und andere SIP Anschlüsse, beide kommen komplett ohne Portforwarding aus.
Wichtig ist nur das man qualify=yes setzt.

ramup

@slu said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Was für eine PBX ist es denn?
Wir haben hier den SIP Trunk der Telekom und andere SIP Anschlüsse, beide kommen komplett ohne Portforwarding aus.
Wichtig ist nur das man qualify=yes setzt.

Hallo slu,
wie eingangs geschrieben ist das eine "Unify OpenScape Business X5W".
Nach einer Google Suche gehe ich davon aus, dass ihr eine Asterisk Anlage habt.

Habt ihr im Zuge der Umstellung auf SIP-Trunk überhaupt nichts in der pfSense geändert?
Also auch keine UDP Timeout-Limits, etc.? Ich setzte dabei natürlich voraus, dass die Firewall Rule jeglichen Datenverkehr zum WAN zulässt.

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Habt ihr im Zuge der Umstellung auf SIP-Trunk überhaupt nichts in der pfSense geändert?
Also auch keine UDP Timeout-Limits, etc.? Ich setzte dabei natürlich voraus, dass die Firewall Rule jeglichen Datenverkehr zum WAN zulässt.

Also um den Punkt mal kurz aufzugreifen: Wir mussten bislang an so gut wie keiner Kundeninstallation bezüglich VoIP irgendwelche UDP Timeouts erhöhen, wenn alle Ports und Kommunikationsbeziehungen ordentlich definiert und freigegeben waren. Denn dann fordert entweder die Anlage selbst einen Keepalive an bzw. sendet einen, oder bekommt vom SIP Trunk/Anbieter entsprechend ihr Signalling von extern rein. Aber UDP State Timeouts o.ä. mussten wir noch nirgends verlängern, egal ob mit multiplen SIP Clients oder mit SIP Anlage gearbeitet wurde.

ramup

@jegr said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Wir mussten bislang an so gut wie keiner Kundeninstallation bezüglich VoIP irgendwelche UDP Timeouts erhöhen, wenn alle Ports und Kommunikationsbeziehungen ordentlich definiert und freigegeben waren.

@JeGr Danke für die Stellungnahme. Hast du dabei konkrete Erfahrungen zu den von dir genannten "Definitionen und Freigaben" der Ports und Kommunikationsbeziehungen beim Telekom SIP-Trunk, da es mir gerade darum geht dies vorzubereiten?

slu

wie eingangs geschrieben ist das eine "Unify OpenScape Business X5W".

Hab ich übersehen, sorry.

Nach einer Google Suche gehe ich davon aus, dass ihr eine Asterisk Anlage habt.

Was google alles weiß, ja eine STARFACE PBX.

Habt ihr im Zuge der Umstellung auf SIP-Trunk überhaupt nichts in der pfSense geändert?

Nein, ich hab auf der STARFACE nur das qualify=yes aktiviert, läuft wie eine eins.

An einem Standort haben wir noch den Telekom SIP Trunk, am großen Standort sind wir von der Telekom weg bzw. haben direkt von ISDN auf einen anderen SIP Anbieter gewechselt.

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Definitionen und Freigaben" der Ports und Kommunikationsbeziehungen beim Telekom SIP-Trunk, da es mir gerade darum geht dies vorzubereiten?

Dazu gibt es im Normalfall auch bei der Telekom irgendwo Dokumentation, welche Ports und IPs hier zur Kommunikation freigegeben bzw. -geschaltet werden müssen. 5060/udp als SIP Port wird definitiv dabei sein und ansonsten sind noch einige RTP/RTSP Port-Ranges mit dabei, was aber wie gesagt stark vom Anbieter und Anlage abhängig ist. Da wir selbst Telekom nicht nutzen, kann ich dazu leider keine Doku verlinken, die solltest du aber auf Nachfrage sicher irgendwo bei der Telekom finden oder bekommen.

Grüße

ramup

@JeGr : Ok, dank dir. Da haben wir wohl etwas aneinander vorbeigesprochen. Dir geht es um die "Firewall Rules" für das betroffene, lokale Interface an dem die TA hängt, damit diese entsprechenden (ausreichenden) Zugriff auf das WAN hat.
Mir geht es mehr um die Frage ob im Sinne des NAT aufgrund der Systematik des SIP-Trunk etwas beachtet werden muss, bei der Interaktion zwischen Interface und WAN.
Die TA hat bei uns vollen Internetzugriff (alle Ports und alle Protokolle) unter Ausschluss des Zugriffs auf andere lokale Netzwerke. Die TA hängt mittlerweile als einzelne IP in einem eigenen Subnetz an einem eigenen physischen Port der pfSense.

Deiner Aussage entnehme ich inzident jedoch, dass bei euch am NAT nichts geändert werden musste. Mal sehen wie es bei der Telekom ist. Laut @slu scheinbar ebenfalls ohne "besonderes" NAT und vielleicht kann @tpf ja auch nach der Umstellung noch etwas beitragen.

@slu Mich würde noch interessieren ob du noch etwas bezüglich QoS / Traffic Shaping an den Anschlüssen gemacht hast um VoIP zu priorisieren? Nach dem Telekomdokument liest sich das so, dass die Telekom "für die Leitung" automatisch eine Priorisierung des VoIP Verkehrs vornimmt und demnach in der pfSense kein Traffic Shaping erforderlich wäre?

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

@JeGr : Ok, dank dir. Da haben wir wohl etwas aneinander vorbeigesprochen. Dir geht es um die "Firewall Rules" für das betroffene, lokale Interface an dem die TA hängt, damit diese entsprechenden (ausreichenden) Zugriff auf das WAN hat.

Nein mir geht es um EIN- wie ausgehende Verbindungen. Man muss SIP auch zur Anlage reinlassen, sonst hat man wieder ganz andere Probleme.

Mir geht es mehr um die Frage ob im Sinne des NAT aufgrund der Systematik des SIP-Trunk etwas beachtet werden muss, bei der Interaktion zwischen Interface und WAN.

Ja wurde auch mehrfach gesagt. 5060/udp muss rein wie raus können und dazu nicht randomisiert werden, also abgehend 5060 muss 5060 bleiben, daher "static port".

Die TA hängt mittlerweile als einzelne IP in einem eigenen Subnetz an einem eigenen physischen Port der pfSense.

Dann muss die abgehende NAT Regel für die Anlage entsprechend angepasst sein.

tpf

Ich habe das mit den UDP-Timeouts auf 35 Sekunden gesetzt, da z.B. die AGFEO ES516 zu selten einen KeepAlive gesendet hat. Bei einer Fritte geht das ja alle 30 Sek.

Ansonsten betone ich noch einmal: ausgehend frei, eingehend nichts geändert. Einzig static port für die TK-Anlage definiert und gut. Funzt, bis auf die AGFEO, und die hatte wohl Firmwareprobleme, überall einwandfrei. Ich werde selbige Konfig auch für den Trunk verwenden.

ramup

@tpf
Meiner vorläufigen Einschätzung nach wird das mit dem Static Port bei SIP-Trunk nicht funktionieren bzw. wird zumindest nicht empfohlen.
Bei SIP-Trunk gibt es den "registered mode" und den "static mode", wobei ersterer seitens der Telekom gewählt werden sollte. Hierzu verweise ich auf Ziffer 2 Zeile 11, Ziffer 4.5 und insbesondere Ziffer 11.3 der technischen Unterlage der Telekom zum SIP-Trunk: PDF
Ein "listening Port" für SIP ist nur im "static mode" erforderlich.

Die Aussage von @slu scheint das ja zu bestätigen. Ich lasse mich aber gerne eines besseren belehren und würde es begrüßen, wenn du nach der Umstellung ein kurzes Feedback geben könntest. Ich weiß insoweit nicht ob pfSense hier eine "Besonderheit" macht mit den "randomized ports" beim NAT.

@JeGr Ich kenne die Vorgehensweise bei den von dir konfigurierten Anbietern nicht, aber bei der Telekom muss man keine Öffnung von außen (WAN) vornehmen. So wie ich es verstehe nutzt die Telekom eine ausgehende Verbindung (state) von der Anlage kommend quasi als Rückverbindung für die Erreichbarkeit der Anlage und das ist ja grundsätzlich automatisch der Fall (Stateful Packet Inspection), da sonst schon keine ausgehende Verbindung möglich wäre. Daher ist auch das NAT keep-alive erforderlich bzw. erhöhte UPD Timeouts (je nach Dauer des keep-alive der Anlage, wenn dies "zu lange" ist).
Vorausgesetzt ist aber sicherlich, dass die TK-Anlage (bzw pfSense) die ausgehende Verbindung zur Telekom auf den notwendigen Ports, etc. vornehmen kann, also entsprechende Verbindungen auf dem Interface gestattet sind (Zugriff vom Interface der Telefonanlage eingehend bei pfSense auf das WAN).

tpf

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

@tpf
Meiner vorläufigen Einschätzung nach wird das mit dem Static Port bei SIP-Trunk nicht funktionieren bzw. wird zumindest nicht empfohlen.
Bei SIP-Trunk gibt es den "registered mode" und den "static mode", wobei ersterer seitens der Telekom gewählt werden sollte. Hierzu verweise ich auf Ziffer 2 Zeile 11, Ziffer 4.5 und insbesondere Ziffer 11.3 der technischen Unterlage der Telekom zum SIP-Trunk: PDF
Ein "listening Port" für SIP ist nur im "static mode" erforderlich.

Die Aussage von @slu scheint das ja zu bestätigen. Ich lasse mich aber gerne eines besseren belehren und würde es begrüßen, wenn du nach der Umstellung ein kurzes Feedback geben könntest. Ich weiß insoweit nicht ob pfSense hier eine "Besonderheit" macht mit den "randomized ports" beim NAT.

Ich lese das PDF so: es ist keine eingehende NAT-/Firewallkonfig vorzunehmen, um Verkehr auf bestimmte Ports zu beschränken, sondern diese durch Verbindungsaufbau intern -> extern zu bestimmen.

Das ist Konsens und wird heute bei allen Anschlüssen von mir so gemacht. Die von mir genannte "static port"-Option im Outbound-NAT sorgt aber dafür, dass die verwendeten Ports nach innen und außen dieselben sind und nicht überschrieben werden.

Liege ich da falsch?

Übrigens mach die Telekom hier echt TCP5060 btw. 5061 und kein UDP mehr.

slu

@slu Mich würde noch interessieren ob du noch etwas bezüglich QoS / Traffic Shaping an den Anschlüssen gemacht hast um VoIP zu priorisieren? Nach dem Telekomdokument liest sich das so, dass die Telekom "für die Leitung" automatisch eine Priorisierung des VoIP Verkehrs vornimmt und demnach in der pfSense kein Traffic Shaping erforderlich wäre?

Ja wir haben den Traffic Shaper in der pfSense aktiviert und geben der PBX damit immer die notwendige Bandbreite. Abgehakt oder Unterbrechungen gibt es damit bei uns nicht.
Auch wenn die Telekom das in deren Netz priorisiert muss man dafür sorgen das die pfSense die richtigen (RTP) Pakete als erstes los wird...

Nochmal zusammen gefasst:

wir haben eingehend kein Portforwarding
LAN -> WAN darf die PBX natürlich
auf allen SIP Leitungen qualify=yes gesetzt
Traffic Shaper auf pfSense aktivieren

Das haben wir mit vielen SIP Anbieter erfolgreich in Betrieb.

Ausnahme Telekom Data/Voice, da ist tatsächlich ein Static Portmapping (5060) ausgehend notwendig.

slu

@tpf said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Liege ich da falsch?

Ich mache das nicht mehr, IMHO war das nur für den Data/Voice notwendig.

Übrigens mach die Telekom hier echt TCP5060 btw. 5061 und kein UDP mehr.

Genau, das ist TCP 5061 / transport tls und SRTP beim Telekom SIP Trunk.

tpf

@slu said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Ich mache das nicht mehr, IMHO war das nur für den Data/Voice notwendig.

Reden wir von der Option im Outbound-NAT? Bei mir führt das Fehlen der Option zu Monologen beim Telefonieren. Entweder höre ich den Anrufer nicht oder er mich nicht.

Ebenso führt das Fehlen der hochgesetzten UDP-Timeouts nach etwa 30 Minuten zum Verlust des Tons im Gespräch.

slu

@tpf said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Reden wir von der Option im Outbound-NAT? Bei mir führt das Fehlen der Option zu Monologen beim Telefonieren. Entweder höre ich den Anrufer nicht oder er mich nicht.

Ja genau Outbound NAT.

Ebenso führt das Fehlen der hochgesetzten UDP-Timeouts nach etwa 30 Minuten zum Verlust des Tons im Gespräch.

Das ist aber dann kein SIP Trunk sondern der Data/Voice? Da kann ich nicht mitsprechen, das Produkt war für uns einfach ungeeignet.

tpf

Deutschland LAN-IP oder so nennt sich das. Der Wald und Wiesen-Anschluss auf VOIP halt, den jeder normalsterbliche Kunde bei der Telekom, Vodafone oder sonstigen Anbietern bekommt.