VOIP SIP Server meldet FORBIDDEN (Asterisk, DNS)

Gelöst

Hallo Community,

 

ich habe gerade wieder eine seltsame Entdeckung beim konfigurieren meiner Asterisk-Anlage gemacht.

 

Der VOIP SIP-Server  217.0.27.104 (do-epp-105.isp.t-ipnet.de) meldet bei ausgehenden Telefonaten immer "FORBIDDEN", trotz erfolgreichem REGISTRY und Invite-Proxy-Auth.

 

Wenn ich den DNS Eintrag auf 217.0.23.100 umbiege, funktionieren ausgehende Gesprche.

 

Ich vermute einen BUG. Es betrifft mehrere VOIP-Kunden.

Vieleicht kann sich das mal ein Fachkundiger anschauen. LOGs kann ich liefern falls nötig.

 

Gruß, Christian

1 AKZEPTIERTE LÖSUNG

So, kurz zur Rückmeldung. Wir haben das Problem gefunden.

 

Es handelt sich um ein DNS Problem in kombination der Telekom DNS Server und unserem DNSMASQ (auf OpenWRT).

Um es kurz zu machen, die Telekom DNS Server lösen den SIP Server anders auf als die öffentlichen SIP Server. Auch verschiedene Telekom DNS Server lösen die Adressen (tel.t-online.de) verschieden auf.

Scheint was mit dem Loadbalancing zu tun zu haben, ich kann schlecht nachvollziehen ob es sich um einen Bug oder ein Feature handelt.

 

Schlussendlich habe ich auf den Asterisk Servern einen bind-server installiert. Alternativ kann man auch einen externen DNS anstelle dem Router-DNS eintragen.

 

Läuft erstmal. Bei Interesse schick ich gern weitere Infos.

Danke für die Mühe.

 

MFG Christian

 

Lösung in ursprünglichem Beitrag anzeigen  

Gelöschter Nutzer

Registrierst Du nicht an tel.t-online.de ?

Schon, aber scheinbar löst der nicht überall gleich auf . DNS Loadbalancing?

 

# ping tel.t-online.de
PING hh-epp-001.isp.t-ipnet.de (217.0.23.132) 56(84) bytes of data.

Natürlich löst der nicht überall gleich auf. 

Forbidden ist eigentlich ein Indiz für schlechte Auth oder falscher Rufnummer zum Anschluss....

kannst du einen SIP Log anonymisiert posten? 

Hier der log ... ich kann aber keinen Unterschied zu einer funktionierenden Verbindung feststellen (z.B. wenn tel.t-online.de auf 217.0.23.100 auflöst)

Nutze mal für die Anmeldung die E-Mail-Adresse und das zugehörige Passwort (wie Login kundencenter) und schau ob sich das Verhalten ändert.

 

Hatte ich schon probiert, keine Änderung. Im Kunden-Telefoniecenter ist "Telekom Login" auch deaktiviert, also existieren keine Zugangsdaten. Ich hatte gehofft, das eine Umstellung ggf. den "bug" behebt weil evtl. irgenwelche Configs neu geschrieben werden. Leider ohne Erfolg.

Es sind die Zugangsdaten für das Kundencenter. Separate Zugangsdaten existieren nicht bei Privatkundentarifen.  Meinst Du mit Telekom Login das Easylogin ? 

Na du musst bei einem Neu-Anschluss wie diesem dich erstmalig mit deinen DSL-Logindaten einloggen, dann ins Telefoniecenter wechseln. Dort kannst du bei den Rufnummern "Telekom-Login" aktivieren. Danach muss man erstmal eine E-Mail Addresse anlegen und ein Passwort vergeben. Dann lässt sich Telefonie per "Telekom-Login" aktivieren.

 

Danach klappt die Auth per anonymous... nicht mehr, mit den Login-Daten (der neu vergebenen E-Mail u. Passwort) hat das REGISTER dann geklappt. Trotzdem kommt FORBIDDEN beim absetzen eines calls.

 

Wie gesagt, ich denke nicht das es ein AUTH problem ist. Immerhin klappt das absetzen des Calls auf anderen Telekom-SIP Servern. Das wird was internes sein. Evtl. eine andere Software als z.B. auf der 217.0.23.100 (dorthin lösen alle anderen Anschlüsse die ich betreibe auf.)

 

Es wäre super wenn ich die Telekom mal die Sache annimmt.

 

Gruß, Christian

Nein, Du kannst am Anschluss für die Telefonie mit dem Hauptnutzer immer anonymous verwenden.

Das gilt natürlich nur bei erfolgreicher Access-Authentifizierung, also bei korrekter Einwahl am eigenen Anschluss...

 

Sind die Rufnummern sind einem Inklusivnutzer zugeordnet, dann müssen zwingend die Daten des Nutzers verwendet werden. 

 

https://www.telekom.de/hilfe/festnetz-internet-tv/telefonieren-einstellungen/telefoniecenter/inklusi...

Soweit ist das klar. DSL Daten sind eindeutig, Einwahl und Verbindung funktionieren ja auch. Auch das REGISTRY funktioniert. Wären die Daten falsch, würde sich die VOIP Anlage ja nicht registrieren können. Das Problem tritt auch mit anderen Nummern an anderen Anschlüssen auf. Problem sind mmn. der Telekom-SIP Server in kombination mit der Asterisk. Ich habe beim selben Kunden noch ein IP-Gigaset stehen, dort funktioniert die Telefonie. Ich werde mir dort mal das Log anschauen sofern möglich.

Hallo Telekom, könnte sich mal bitte einer dem Problem annehmen?

Wenn das Gigaset läuft, die Asterisk aber nicht ist doch aber naheliegend, dass die Konfiguration der Asterisk nicht ganz sauber ist... 

 

Der Asterisk läuft mit der gleichen Konfiguration bei ca. 10 Kunden (auch größere) seit mehreren jahren.

Außerdem läuft er mit dem .100er SIP Server auch fehlerfrei. Die Forbidden Meldung ist auch nicht aussagekräftig da kein Grund genannt wird.

Das Protokoll sieht auch sauber aus. Warum sich die anderen Server verschlucken kann aber nur die Telekom in ihren LOGs nachlesen.

Asterisk ist meiner Meinung nach auch ein marktrelevantes Produkt und läuft mit beinahe allen anderen Anbietern und Geräten fehlerfrei. Nur bei der Telekom kommt es immer wieder zu Problemen. Das sind nicht die ersten bugs auf die ich hinweise, siehe meinen Beitrag zur Thema Primacom.

 

Nun kann man sich aber den schwarzen Peter immer hin und her schieben, das bringt uns aber auch nicht weiter. Zielführender wäre es, wenn sich ein Telekom-Techniker mal das LOG anschaut.

Ich hab das Problem eingrenzen können.

 

Das Ursprüngliche INVITE wird an die .104 gesendet, zurück kommt die AUTH anforderung. Daraufhin Parst Asterisk die destination neu und löst tel.t-online.de neu auf. Der DNS Record zeigt auf die .132

 

Die .132 weiß allerdings noch nix von der Session.

Das kann auch ein DNS Problem sein. Ich schau mir mal die SIP-Specs dazu an.

So, kurz zur Rückmeldung. Wir haben das Problem gefunden.

 

Es handelt sich um ein DNS Problem in kombination der Telekom DNS Server und unserem DNSMASQ (auf OpenWRT).

Um es kurz zu machen, die Telekom DNS Server lösen den SIP Server anders auf als die öffentlichen SIP Server. Auch verschiedene Telekom DNS Server lösen die Adressen (tel.t-online.de) verschieden auf.

Scheint was mit dem Loadbalancing zu tun zu haben, ich kann schlecht nachvollziehen ob es sich um einen Bug oder ein Feature handelt.

 

Schlussendlich habe ich auf den Asterisk Servern einen bind-server installiert. Alternativ kann man auch einen externen DNS anstelle dem Router-DNS eintragen.

 

Läuft erstmal. Bei Interesse schick ich gern weitere Infos.

Danke für die Mühe.

 

MFG Christian

 

Ok, genausowas hatte ich vermutet. Danke für die Rückmeldung .

Hallo Christian,

danke für dein bereits umfangreiches Troubleshooting. Ich habe mit ziemlicher Sicherheit das gleiche Problem mit meiner auf Linux basierenden 3cx Appliance. Es läuft stundenlang und irgendwann bekomme ich einen 403 (forbidden) zurück. Manchmal erholt sich der Trunk alleine, manchmal nicht. Sieht für mich auch nach DNS und deinem beschriebenen Phänomen aus. Ich nehme an, ihr habt auf dem besagten BIND die IP statisch dem Namen tel.t-online.de zugeornet. Wenn ja, würde mich interessieren, welche IP ihr nehmt und ob ihr noch weitere Änderungen vorgenommen habt. Ich würde sonst die IP einfach in der hosts eintragen.

Danke Matthias

Hallo Matthias,

 

ich versuchs mal zusammen zu bekommen, ist ja schon eine Weile her. Leider nervt das Loadbalancing der Telekom extrem.

 

tel.t-online.de löst bei mir über die externen Rootserver auf 217.0.23.100 auf.

Wir haben auf jeder Anlage einen eigenen BIND in Standardkonfiguration laufen.

 

Als das Problem bestand, hatten wir einen Router mit einem DNSMASQ am laufen. Dieser hat die DNS Anfragen an die Telekom-DNS Server geFORWARDed.

 

Im Asterisk lief das dann folgendermaßen:

REGISTER/INVITE an den Server welcher unter "_sip._udp.tel.t-online.de" aufgelöst wurde

Asterisk löst danach neu auf, auf "tel.t-online.de"

"_sip._udp.tel.t-online.de" entsprach nicht "tel.t-online.de"

Das Gespräch kommt nicht zu stande, da dieser Server nichts von dem REGISTER weiß, daher meldet dieser FORBIDDEN.

 

bei der Auflösung über BIND/Rootserver löste "_sip._udp.tel.t-online.de" auf die selbe Adresse auf wie "tel.t-online.de".

Daher reichte die Installation vom BIND und das umlegen der resolv.conf auf 127.0.0.1

 

Man konnte das sehr schön im SIPLOG vom Asterisk sehen (sip set debug on).

 

Ich hoffe ich konnte helfen.

 

MFG Christian

 

Anbei noch die sip-conf für den telekom peer (verhindert auch andere BUGs):

[Telekom]
type=peer
insecure=invite
username=anonymous@t-online.de
secret=nopass
host=tel.t-online.de                                                                                                                 
fromdomain=tel.t-online.de                                                                                                           
canreinvite=no                                                                                                                       
realm=tel.t-online.de                                                                                                                
canreinvite=no                                                                                                                       
directmedia=no
nat=no                                                                                                                               
qualify=yes
context=default                                                                                                                      
insecure=port,invite
session-timers=refuse
dtmfmode=inband
videosupport=no
ignoresdpversion=yes

 

Hallo Christian,

danke für deine schnelle Antwort. Ich denke, ich habe es jetzt hinbekommen. Der Trunk steht jetzt seit seit mehr als 48h stabil ohne Abbrüche.

Am Ende hast du mich auf den richtigen Weg gebracht. Das Problem ist, dass wenn die 3cx den Service Locator Record "_sip._udp.tel.t-online.de" anfragt, gibt es 2 Namen zurück. Der erste wird zwar präfertiert aber es kommt dennoch ab und zu vor, dass der 2. Server gefragt wird. Dieser weiß dann offensichtlich nichts von der Sitzung und gibt "403 forbidden" zurück.

 

nslookup

 

> set type=srv

 

> _sip._udp.tel.t-online.de

Server: 172.19.xxx.xxx (mein Nameserver)

Address: 172.19.xxx.xxx#53

 

Abfrage des SRV Records ergibt 2 Hosts

 

Non-authoritative answer:

_sip._udp.tel.t-online.de service = 0 5 5060 ims001.voip.t-ipnet.de.

_sip._udp.tel.t-online.de service = 1 5 5060 ims002.voip.t-ipnet.de.

 

Kurz die IP checken

 

Non-authoritative answer:

ims001.voip.t-ipnet.de canonical name = b-epp-001.isp.t-ipnet.de.

Name: b-epp-001.isp.t-ipnet.de

Address: 217.0.23.100

> ims002.voip.t-ipnet.de

Server: 172.19.xxx.xxx

Address: 172.19.xxx.xxx#53

 

Non-authoritative answer:

ims002.voip.t-ipnet.de canonical name = h2-epp-801.isp.t-ipnet.de.

Name: h2-epp-801.isp.t-ipnet.de

Address: 217.0.128.132

> ims002.voip.t-ipnet.de

Server: 172.19.xxx.xxx

Address: 172.19.xxx.xxx#53

 

Ich habe mir jetzt so geholfen, dass ich 

ims001.voip.t-ipnet.de.

ims002.voip.t-ipnet.de.

in meine /etc/hosts (unter Windows einfach im "windows/system32/drivers/etc/hosts") die beiden Server eingetragen habe und auf die selbe IP verweise (217.0.23.100).

 

Man kann natürlich auch auf seinem DNS Server eine Zone voip.t-ipnet.de anlegen und dort die beiden A-records pflegen.

 

Ich hoffe, die T-kom ändert nicht demnächst die IP Adressen Zwinkernd

 

Viele Grüße

Matthias

 

 

 

 

 

 

 

Hallo,
bei mir trat das Problem fast genau 1 Jahr später auf als hier erstmals gepostet und ich habe das äußerst fragliche Telekom Konstrukt heute über eine DNS RPZ policy in meiner DNS Infrastruktur gelöst. Alternativ könnte srvlookup=no (sip.conf ) für den ein oder anderen eine einfachere Lösung sein.

*._udp.tel.t-online.de CNAME .
_sip._udp.tel.t-online.de CNAME .

/Martin