Asterisk pjsip.conf für tel.t-online.de hinter NAT

[#1]

Weil ich nirgends eine funktionierende Konfiguration gefunden habe, nach Stunden probieren und recherchieren jetzt hier ein Memorium.

Der Asterisk läuft auf der IP 10.0.0.2 hinter einer Fritz!Box an einem AllIP Magenta-Anschluss.

Auf der Fritz!Box folgende Portfreigaben anlegen:

5061/udp -> 10.0.0.2:5061

30000-30099/udp -> 10.0.0.2:30000

5061 wird ersatzweise verwendet, weil auf 5060 unumgänglich auf Home-Routern schon ein eigener Sipproxy lauscht.

Diesen wollen wir nicht haben, können den Schrott aber leider auch nicht abschalten.

Die pjsip.conf für Asterisk mit der Telekom incl. outbound_proxy:

[global]
type = global
language = de
endpoint_identifier_order = ip,username

[transport-udp]
type = transport
protocol = udp
bind = 10.0.0.2:5061
local_net = 10.0.0.0/16
domain = my.dyndns.org
external_media_address = $ExterneIP
external_signaling_address = $ExterneIP
external_signaling_port = 5061

[telekom_9931234567_reg]
type = registration
transport = transport-udp
outbound_auth = telekom_9931234567_auth
outbound_proxy = sip:+499931234567@tel.t-online.de:5060\;lr
server_uri = sip:tel.t-online.de:5060
client_uri = sip:+499931234567@tel.t-online.de:5060
contact_user = 09931234567
retry_interval = 60
forbidden_retry_interval = 60
expiration = 480
auth_rejection_permanent = false

[telekom_9931234567_auth]
type = auth
auth_type = userpass
password = $Password:$TOnlineNummer-0001@tel.t-online.de
username = 09931234567
realm = tel.t-online.de

[telekom_9931234567]
type = endpoint
transport = transport-udp
context = incoming
disallow = all
allow = alaw,g722
outbound_auth = telekom_9931234567_auth
outbound_proxy = sip:+499931234567@tel.t-online.de:5060\;lr
aors = telekom_9931234567_aor
callerid = 09931234567
from_user = 09931234567
from_domain = tel.t-online.de
timers = no
rtp_symmetric = yes
force_rport = yes
ice_support = yes
rewrite_contact = yes
direct_media = no

[telekom_9931234567_aor]
type = aor
contact = sip:+499931234567@tel.t-online.de

[telekom_9931234567_identify]
type = identify
endpoint = telekom_9931234567
match = 217.0.0.0/13

Die fiktive Telefonnummer 9931234567 durch die eigene ersetzen. Dabei darauf achten, wo die Nummer mit 0 oder +49 beginnt. (Wichtig)

Darüber hinaus noch die Variablen

- $TOnlineNummer

- $Password

- $ExterneIP

sinngemäß anpassen.

Außer [global] und [transport-udp] muss alles für jede Telefonnummer wiederholt werden.

outbound_proxy= <vollständige-sip-url>\;lr

\;lr am Schluss ist wichtig. Steht für loose-routing. Gibt man das nicht mit an, ruft man sich beim abgehenden Anruf immer selbst an.

Das hat mich Stunden gekostet, denn es ist in dem Zusammenhang nirgends vernünftig dokumentiert.

Dann noch die rtp.conf anpassen:

rtpstart = 30000
rtpend = 30099

Damit eingehende RTP-Daten auch auf die richtigen am Router forwardeten Ports der external_media_address bestellt werden.

Warum die $ExterneIP in die pjsip.conf schreiben?

Das aktuelle res_pjsip.so Modul, welches in den meisten Distros verteilt wird macht keinen automatischen Lookup, wenn man einen DNS-Namen als external_media_address verwendet. Asterisk sendet dann im INVITE den DNS-Namen statt der IP. Prinziepiell sollte das gehen, jedoch machen die SIP-Gateways bei fast allen Providern entgegen der Spezifikation kein DNS-Lookup für uns.

Ich habe das unschön gelöst, indem ich ein kleines python-Script per Cron regelmäßig die IP von meiner DynDNS-Domain abfragen lasse.

Bei Bedarf ersetzt das Script dann die IP in der pjsip.conf und reloaded per AMI pjsip.

extensions.conf

[incoming]
exten => 09931234567,1,Verbose(${CALLERID(num)} ruft an)

[out]
exten => _X.,1,Dial(PJSIP/${EXTEN}@telekom_9931234567)

[#2 · Accepted solution]

---

@JanJonas schrieb:

Auf der Fritz!Box folgende Portfreigaben anlegen:

5061/udp -> 10.0.0.2:5061

30000-30099/udp -> 10.0.0.2:30000

5061 wird ersatzweise verwendet, weil auf 5060 unumgänglich auf Home-Routern schon ein eigener Sipproxy lauscht.

Diesen wollen wir nicht haben, können den Schrott aber leider auch nicht abschalten.

---

Definitiv ist für Asterisk KEINE eingehende Portweiterleitung - weder von 5060 noch 5061- notwendig noch in irgend einer Weise sinnvoll.

Daher macht der Router auch keinen Schrott.

Es muss lediglich sicher gestellt werden, dass der Keep-Alive Retry der SIP-Registrierung kleiner ist, als der Timeout für UDP Verbindungen auf dem Router, damit der keinen aktiven State einer SIP-Registrierung aus der Sessiontabelle wirft.

Offen SIP-Server Ports aus dem Internet sind eine ernstzunehmende Sicherheitslücke - die viele Menschen schon Tausende € gekostet haben.

Es besteht die Gefahr, dass ein Gerät aus dem Internet sich auf einem durch schwachem/keinem Passwort gesicherten Endpunkt auf der Asterisk anmeldet und somit kostenpflichtige Telefonate führen kann. Es bedarf zwar noch weiterer Konfigurationsfehler um dies zu ermöglichen, aber wer den Port im Router freischaltet, macht auch diese.

Alle SIP-Verbindungen am VOIP Anschluss werden ausschliesslich vom LAN ins WAN augebaut

[#3 · Accepted solution]

---

@JanJonas schrieb:

Auf der Fritz!Box folgende Portfreigaben anlegen:

5061/udp -> 10.0.0.2:5061

30000-30099/udp -> 10.0.0.2:30000

5061 wird ersatzweise verwendet, weil auf 5060 unumgänglich auf Home-Routern schon ein eigener Sipproxy lauscht.

Diesen wollen wir nicht haben, können den Schrott aber leider auch nicht abschalten.

---

Definitiv ist für Asterisk KEINE eingehende Portweiterleitung - weder von 5060 noch 5061- notwendig noch in irgend einer Weise sinnvoll.

Daher macht der Router auch keinen Schrott.

Es muss lediglich sicher gestellt werden, dass der Keep-Alive Retry der SIP-Registrierung kleiner ist, als der Timeout für UDP Verbindungen auf dem Router, damit der keinen aktiven State einer SIP-Registrierung aus der Sessiontabelle wirft.

Offen SIP-Server Ports aus dem Internet sind eine ernstzunehmende Sicherheitslücke - die viele Menschen schon Tausende € gekostet haben.

Es besteht die Gefahr, dass ein Gerät aus dem Internet sich auf einem durch schwachem/keinem Passwort gesicherten Endpunkt auf der Asterisk anmeldet und somit kostenpflichtige Telefonate führen kann. Es bedarf zwar noch weiterer Konfigurationsfehler um dies zu ermöglichen, aber wer den Port im Router freischaltet, macht auch diese.

Alle SIP-Verbindungen am VOIP Anschluss werden ausschliesslich vom LAN ins WAN augebaut

[#4]

Besten Dank @Stefan, die beschriebene Portweiterleitung 5061 ist offensichtlich tatsächlich nicht notwendig.

Durch die Nutzung von outbound_proxy wird das unnötig.

Lediglich die RTP-Ports sind zwangsläufig statisch zu forwarden.

Andererseits sind an allen nicht genatteten Systemen alle Ports zwangsläufig direkt dem Internet ausgeliefert.

Der Einsatz einer Firewall ist unabhängig davon zum unterbinden unberechtigten Kontakts sowieso geboten.

Weitere Sicherheitsmerkmale müssten noch hinzugefügt werden. Notiert habe ich hier lediglich eine funktionierende Basiskonfiguration.

---

@Stefan schrieb:

Daher macht der Router auch keinen Schrott.

---

Da muss ich widersprechen.

Jeder unnötige Dienst, den man nicht abschalten kann und jede wichtige Einstellung die man nicht beeinflussen kann ist Schrott.

Ganz weit vorne in der Disziplin rangieren da z.B. die kastrierten Speedports, die jemanden der schonmal was von Subnetz gehört hat schnell an den Rand der Verzweifelung bringen können. Vielleicht sind sie in solch einem Fall aber auch einfach das falsche Gerät.

Es gibt doch genug Fälle, wo es notwendig ist über 192.168.2.0/24 hinaus von weiteren Adressen aus dem Raum des RFC1819 gebrauch zu machen. Ohne Firmware hacken (Aufwand) nIcht möglich mit dem Speedport. - Immerhin, auch das geht.

[#5]

---

@JanJonas schrieb:

Andererseits sind an allen nicht genatteten Systemen alle Ports zwangsläufig direkt dem Internet ausgeliefert.

Der Einsatz einer Firewall ist unabhängig davon zum unterbinden unberechtigten Kontakts sowieso geboten.

Natürlich benötigt jedes System eine Firewall, dass beim einen zusätzlich NAT zum Einsatz kommt, ist ein völlig unabhängiges Thema 

Provider Router  sind mehr IADs als Router. Sie disqualifizieren sich per se für alle die keine Dienste nutzen wollen die IADs bereitstellen.

es ist keinem Kunden zuzumuten einen Router zu konfigurieren der es kaum schafft ein Kabel in die TAE zu stecken.

Können wir uns auf RFC1918 anstelle RFC1819 einigen

ich wüsste jetzt keinen Fall auf dem ein zweiter RFC1918 Adressraum Sinn macht und der relevanten Zielgruppe nützlich wäre.

Welches NETZ aus RFC1918 der Speedport primär nutzt ist aber ja einzustellen - also wenn du lieber 192.168.55.0/24 nutzt, dann kannst du dies ohne hacken der Firmware.

[#6]

Danke für die gute Beschreibung. Hat bei mir nach einigem Probieren nun auch funktioniert.

Drei Anmerkungen meinerseits:

1. Wie auch an anderen Stellen schon erwähnt wurde, sind die Authentisierungsdaten völlig egal. Die Telekom gestattet die SIP-Registrierung ausschließlich von der IP-Adresse, die dem Anschluss zugeordnet ist, und ignoriert dabei die Anmeldedaten. (Hatte mich gewundert, warum ich bei meinen ersten Tests mit dem Gigaset und ohne Asterisk nie nach Anmeldedaten gefragt worden bin.) An anderer Stelle wurde schon drauf hingewiesen, dass dies natürlich ein potenzielles Sicherheitsrisiko ist, da dann irgendwelche Malware im Netz ebenfalls automatisch das Recht bekommt, den Telefonanschluss zu benutzen. Als Asterisk-Nutzer sind wir diesbezüglich ganz gut dran: man kann dem Firewall ja sagen, dass nur Asterisk selbst telefonieren darf und alle anderen nicht.
2. Das Überschreiben der Caller-ID im endpoint-Eintrag ist nicht sinnvoll. Dadurch wird die Caller-ID des eigentlichen Anrufers verworfen. Im Beispiel kam dann – egal, wer anruft – nur noch "9931234567 ruft an" heraus.
3. Das Einrichten des "transport" mit den üblichen NAT-Vorkehrungen führte bei mir dazu, dass die geNATete RTP-Verbindung nicht funktionierte: der Firewall hat den ausgehenden UDP-Port durch das NAT ja auf eine andere Portnummer umgesetzt, aber die Telekom-Server schickten ihre Antwortpakete an die zuvor in der SIP-Verbindung genannte Portnummer zurück, mit der der Firewall natürlich nichts anfangen konnte. Beim Vergleich mit dem (funktionierenden) Gigaset habe ich festgestellt, dass dort einfach die interne RFC1918-Adresse in allen Kontaktdaten im SIP angegeben worden war. Daraufhin habe ich den PJSIP-Transport auf die simpelsten Einstellungen zurückgedreht (nur type, protocol, bind), und sieh' an, die Telekomserver ignorieren die in der SIP-Verbindung angegebene Portnummer und antworten stattdessen auf die Portnummer, die sie tatsächlich zu sehen bekommen haben.

Jörg