[Siproxd & VOIP Support] Problem- und Lösungsthread

[Schubbie]

Leider waren das nicht alle Anhänge. Nun sitze ich kurz am Rechner.
Anbei 4 Screenshots. Kann man daran etwas sehen? Kann ich mit mehr Infos dienen?

Gibt es denn eine Option, die den SIP-Header o.ä. verändert oder eine Veränderung verhindern kann?

[robgnu]

Hallo Andreas,

versuch doch bitte mal folgende Punkte:

- Stell mal bei der Outbound-NAT Regel die Option "Source port" von Any (*) auf SIP (5060) um.
- Funktioniert der Verbindungsaufbau, wenn du die anderen SIP-Registrierungen (Sipgate etc.) deaktivierst?

Gruß
Robert.

[Schubbie]

Moin Robert,
werde ich heute Abend testen. Jedoch sehe ich die Chance als verschwindend gering an, da die Starface PBX die Rückmeldung bekommt, dass der Login falsch ist. Würde die den Provider nicht erreichen, dann würde ein Timeout oder so Kommen. Man müsste gucken können, was bei 1&1 ankommt, was die einem aber nicht sagen.

Mit freundlichem Gruß
Andreas

[mimugmail]

Mach mal ein Paket Capture auf Interface LAN mit IP der TK Anlage und versuch paar Calls, dann bitte uploaden.
Das gleiche dann noch mal an Interface WAN, aber ohne IPs und nur Zielport 5060.

Du machst jetzt nur NAT für Signaling, aber kein RTP .. hast du keine bekannten IP Ranges die du komplett natten kannst?

[Schubbie]

Starface nutzt für RTP Port 1.000 - ca. 65.xxx. Da wäre für andere Anwendungen dann nichts mehr über, aber bisher brauchte ich die nicht freigeben und bisher kann ich eh nicht telefonieren,  wenn die OPNsense angeklemmt ist, da sich die Leitungen gar nicht erst registrieren können. Erstmal muss die Registrierung über UDP 5060 klappen und dann kann man weitersehen, jedoch denke ich, dass es dann gehen wird.
Sipgate scheint nicht ganz so kleinlich wie 1&1 zu sein und da klappt alles. Ich mache die Captures heute Abend. Die macht OPNsense direkt?
Mit freundlichem Gruß
Andreas

[mimugmail]

Interfaces : Diagnostics : Packet Capture

[Schubbie]

Da bin ich endlich wieder 

@Robert
Auf Port 5060 geändert - keine Veränderung
SipGate deaktiviert - keine Veränderung

@mimugmail
Outbound-NAT siehe Anhang, ob ich das so korrekt gemacht habe - keine Veränderung
Von 1und1 brauche ich nur die zwei IPs 212.227.124.129 + .130 sprich .129/30
In dem Capture sieht man die Meldung, die Zoiper mir bringt, also verfälscht anscheinend die Starface die Meldung von 1&1.

Zoiper und Capture (wobei Zoiper gelegentlich funktioniert):
403 Nicht unterstuetzte IP im Contact-Header

Starface Log:
WARNING[24234] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '495***909' to 'sip.1und1.de'

Die externe IP in den Captures stimmt mit der momentanen externen IP überein. Ich habe auch nur einen Internetzugang (außer 4G für Fallback, der aber noch nicht konfiguriert ist), ich kann also nicht über eine andere IP als die von 1&1 zugewiesene ins Internet.

Anbei die Dateien.

Vielen Dank für Eure Unterstützung und Eure Mühen!

Mit freundlichem Gruß
Andreas

[Schubbie]

Moin,
ich kann die Leitungen jetzt registrieren. Warum auch immer, muss ich in der Starface eine Einstellung ändern, die ich bei der Ubiquiti-Gateway nicht vornehmen durfte. Ich hatte auch mit NAT ja/nein in der Starface probiert, jedoch musste ich in den SIP-Einstellungen meine externe IP eintragen. Da ich alle 24 Stunden eine neue nehme, habe ich meine Strato Subdomain eingetragen, die immer auf meine externe IP verweist. Leitungen registrieren sofort und Anrufe kommen rein und gehen raus, allerdings noch ohne Sprache. Da gucke ich nun, ob eine Regel zu viel eingrenzt oder ich die RTP-Ports auch freigeben muss, was ich aufgrund der Range bei der Starface (1025 - 65535) nicht hoffe.

Vielen Dank für Eure Unterstützung. Ich melde mich, wenn ich es mit den RTP-Ports nicht hinbekommen sollte oder noch auf andere Probleme bei der Einrichtung stoße ;-)

Mit freundlichem Gruß
Andreas

[robgnu]

Hallo Andreas,
um die externe IP-Adresse zu ermitteln benutzt man eigentlich einen STUN-Server. Ich sehe auf deinem Screenshot leider keine Option dafür, aber schau doch nochmal bei deiner SIP-Config nach.

https://de.m.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT

Zum RTP: Eine Portweiterleitung sollte nicht unbedingt nötig sein, jedoch würde ich unbedingt nochmal Google nutzen oder in der Anleitung wühlen.
Der Portbereich muss ja irgendwo dokumentiert sein. Bei Fritz Boxen ist es z.B. 7078:7109 und bei  Auerswald hatte ich mal 49152:49407 recherchiert.

Wichtig ist auch hier wieder Outbound-NAT mit Static-Port. Wenn du den Portbereich eingrenzen könntest, wäre das hilfreich.

Gruß
Robert.

PS. Wenn du ein paar Paketmitschnitte von Telefonaten aufzeichnest, kannst du die ausgehandelten RTP Ports mit Wireshark in den SIP-Paketen nachlesen.

[Schubbie]

Moin Robert,
STUN-Server und die Funktion ist bekannt, leider gibt es bei Starface keine Möglichkeit diesen im Providerprovil einzutragen. Im Forum wird nur darauf verwiesen, dass die Ports freizugeben sind.

Ich habe jetzt endlich Ton und Verbindung. Allerdings kommt nicht jeder Ruf am Telefon an. Die Starface weist Rufe ab, da sie die interne Nummer lt. Log nicht findet, allerdings scheint diese Meldung auch wieder nicht korrekt zu sein, da die korrekte Nummer im Log steht.

[Jul 12 08:45:20] NOTICE[20205][C-0000001a] chan_sip.c: Call from '' (212.227.124.129:5060) to extension '495***913' rejected because extension not found in context 'default'.

Dieses Problem hatte ich früher schon, nachdem ich eine neue IP nach Zwangstrennung bekommen habe. Per Script lasse ich die Dienste neu starten, wenn es eine neue IP gibt. Allerdings tritt es jetzt nach ca. 3x anrufen auf und eventuell 2x hintereinander oder der Ruf kommt wieder durch (kommt auf jeden Fall bei der Starface an), also eher zufällig, dass es funktioniert.

Die RTP-Ports werden von dem Geräte, in diesem Falle von der Starface vorgegeben und die sind leider tatsächlich von Port 1025 - 65535, wobei ich noch eben ein- und ausgehend trennen kann, was ja aber keine Besserung ergeben dürfte, da ausgehend trotzdem bei der Range bleibt.
https://knowledge.starface.de/pages/viewpage.action?pageId=6128345

Wenn ich nun sicherstellen könnte, dass jeder Ruf durch die Starface geht, so wie er es mit dem Ubiquiti-Gateway tut, dann habe ich es vermutlich. Jemand hat mal das UDP-Delay hochgestellt auf 300 Sekunden, allerdings vergehen bei mir nur 10 Sekunden, bis der Ruf eventuell nicht mehr durch geht und das auch kurz nach einen Neustart. Habe ich in der OPNsense eine Option, um dieses zu verlängern? Ich habe die Firewall-Optimierungen bereits auf "konservativ" gestellt.

Ich stelle nochmals Screenshots ein. Vielleicht kann man ja noch etwas verbessern?
Die Regeln für Port 5060 habe ich bewusst nochmals zusätzlich angelegt, vielleicht nützt es ja etwas, obwohl es ja eigentlich nicht sein dürfte, wenn der Port in der Range der RTP-Ports ist? (Hat nichts gebessert. Können sich die Regeln behindern?)

Mit freundlichem Gruß
Andreas


Kurz für die Statistik: ich habe knapp 240 Testanruf von Mitternacht bis heute morgen gemacht...

[Schubbie]

Moin,
ich habe noch ein paar Testanrufe gemacht. Laut Paketmitschnitt scheint es mir so, als wenn der Ruf von 1&1 212.227.124.130:5060 kommt, nicht von der Starface an das Endgerät durchgestellt wird und kurz darauf kommt die Ansage von 1&1, dass der Teilnehmer nicht erreichbar ist. Kommt der Ruf über die 212.227.124.129:5060 rein, dann klingelt das Telefon.
Aber warum dieses Verhalten nur bei der OPNsense und nicht bei einem anderen Router.
Kann der "static Port" ein Problem sein, wenn die ankommende Adresse wechselt?

in der Firewall habe ich 212.227.124.129/30 freigegeben, also genau diese beiden IPs von 1&1. Wenn ich alle freigebe, dann lässt die Starface auch nicht alle Rufe durch.

Mit freundlichem Gruß
Andreas

[mimugmail]

Zeig noch mal port forward und outbound nat zu den IPs bitte ...

[robgnu]

Hi,
kleiner Schuss ins Blaue: Verwende doch mal anstatt eines Subnetzes /30 einen Firewall-Alias, der die beiden IP-Adressen enthält. Bei den Regeln wählst du dann einfach den Alias aus.

Bei IPv4 ist ja jedes Subnetz prinzipiell mit einer Netzadresse und einer Broadcast-Adresse versehen. (/24 = x.x.x.0 bis x.x.x.255 wobei 0 das Netz ist und 255 die Broadcast-Adresse). Je kleiner die Bereiche werden, desto mehr Adressen werden ja bekanntlich verschwendet.

Robert.

[Schubbie]

Moin,
anscheinend gab es eine Wunderheilung. Ich habe gestern alles nochmals neu gestartet und seit dem keine Probleme bei 25 Testanrufen auf beiden IPs.

Anbei die Screenshoots (die Größe der möglichen Anhänge finde ich nicht mehr zeitgemäß. Ich muss die Qualität immer weit runterschrauben, damit ich mit der Größe der Dateien hier hinkomme). Der letzte kommt im Folgepost.

Das mit den Aliasen sollte ich wohl mal in Angriff nehmen. Nicht nur, um Ranges eingeben zu können, sondern werden damit zentral an einer Stelle auch für alle Regeln die Ranges geändert, ohne dass man in jede Regel rein muss. Behalte ich als ToDo im Hinterkopf.

Mit freundlichem Gruß
Andreas

[Schubbie]

Der letzte Screenshot.