PBX-Plugin

[mimugmail]

Also UI und templating von der config mache ich, das wird kein Problem. Wenn da aber so wrapper wie Passwörter müssen in NTLM gesaved werden kommen brauch ich jmd. mit PHP/Pyhton skills, ansonsten wird das schon .. die Asterisk config hier sah jetzt nicht sooo schlimm aus .. aber das war bisher immer so, je einfacher das Plugin aussieht desto umfangreicher wirds dann. :)

[NicholasRush]

Genau, ich möchte aber dafür sorgen das sowohl das Plugin, als auch die Programmierung nachher "einfach" vonstatten gehen, ging bei Siproxd ja auch relativ einfach. Aber viel vorarbeit wird es allemal.

Du könntest mal herausfinden wie, SSH und Webzugriff bei Fehlversuchen geblockt werden. Da ist ja so ein ähnliches Script wie Fail2Ban hinter, sowas möchte ich gerne auch noch einbauen. Habe schon im Source Code gewühlt aber nichts gefunden. Einfach Fail2Ban nehmen wird da nämlich nicht gehen denke ich.

Achso PHP oder Python nur für AGI Skripte, weil damit mehr möglich ist als mit dem Asterisk Dialplan.

[mimugmail]

Fail2Ban wird schwierig, es hatte sich für mich so angehört als hätte Kamailio das schon mit integriert?
Ich frag mal Franco ob er ne Idee hat (oder du liest grad mit?)  ;D

[Alphakilo]

Full disclosure: Mein Arbeitgeber stellt eine kommerzielle VoIP/ISDN-Lösung auf Asterisk-Basis her. Das ist aber nicht der Hintergrund warum ich dich bitte dein Vorhaben zu überdenken. Ich bin hier in privater Funktion. FOSS ist mein kink ;D

Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.    :)

Ich habe es so Verstanden das du einen Kamalio vor einen Asterisk setzt um eine vollständige PBX (ohne DAHDI ;)) zu implementieren. Inklusive Provisioning von Endgeräten. Und Providertemplates. Im Kontext einer Firewall.

Ich warte auf dein Konzept, aber mein Bauchgefühl sagt mir das die Ziele sehr hoch gesteckt sind, unabhängig von deiner oder mimugmails Expertise (die ich nicht anzweifle). Es geht mir um die reinen Mannstunden. Und den Sicherheitsaspekt. Jail hin oder her, die Attacksurface vervielfacht sich. Müssen ja auch nicht direkt RCEs sein.

Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]

Das hat nur leider niemand den Providern erzählt  :P

So was wie RFC3261 und 3550 / 4566 wird (meist) eingehalten. Da gebe ich dir Recht. Mir geht es eher um die Vermittlung (pots / inter-provider) und Signalisierung.

Ein Beispiel das ich gerne nehme sind Nummernformate. Welches Format soll die Zielrufnummer haben? Wie unterscheidet es sich lokal, national, international (das Unterscheidet sich auch nochmal per Provider und Zielregion)? Der Brüller: Nationale Sonderrufnummern.

In welchem Header wird die CLIP erwartet? PAI? PPI? Oder doch lieber FROM?
Wie signalisiere ich CLIR? Redirection / reflection?

¯\_(ツ)_/¯

Und dann die Fehlermeldungen... Was kommt bei Besetzt / Rejected zurück? Ungültige Rufnummer? Gesperrtem Account?
Am tollsten sind die Provider die Munter im Fehlerfall mit 200 OK antworten und eine Sprachnachricht über RTP drücken.

Ich kenne keine zwei Provider welche identische Spezifikationen befolgen. Es ist nicht mal garantiert das die Spezifikation innerhalb des selben Providernetzes konsistent sind.
SIP INVITES kommen mit führender +49... von dem einen SBC, 49... von dem nächsten und drei Tage später mit 0..., dann komplett ohne Präfix vom dritten SBC.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Tun sie nicht! Warum? "Die PBX ist schuld!" Es ist immer, grundsätzlich die PBX.
"Oh. Keine Fritz- / Digitalisierungsbox? Kein Support. Ach du willst nur die Specs? Die kann ich dir nicht geben. Kauf dir lieber die supportete™ PBX©".

Selbst wenn man einen PCAP mit RFC violations (INVITE nach 407 ohne Hash wiederholt, 407 Response ohne NONCE, unilateraler Codecwechsel ohne SDP, COMEDIA ignoriert, ...) vorweisen kann wird es im besten Fall still und heimlich gefixt und ohne Ankündigung ausgerollt. Schuld bleibt *drumroll* die PBX. Es wird gelogen, getrickst und intrigiert. Bis jemand weint.
Zugegeben, es gibt Provider die sehr transparent Arbeiten. Mit denen es Spaß macht solche Fehler auszuräumen. Der staatlich geförderte Monopolist ist keiner davon.

So. Ich gehe jetzt erst mal einen Kaffee trinken um von meinem Nerdrage wieder runter zu kommen. Hoffe ich konnte meine Punkte rüber bringen. Ich will euch nichts böses.

[NicholasRush]

Full disclosure: Mein Arbeitgeber stellt eine kommerzielle VoIP/ISDN-Lösung auf Asterisk-Basis her. Das ist aber nicht der Hintergrund warum ich dich bitte dein Vorhaben zu überdenken. Ich bin hier in privater Funktion. FOSS ist mein kink ;D

Ich finde es gut, das du dich für dieses Projekt interessierst und du bereits aus diesem Bereich kommst. Und das im wahrsten sinne des Wortes dein "täglich Brot" ist. Denn dadurch kannst/darfst/sollst du dich, wenn du möchtest an diesem Plugin beteiligen.

Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.    :)

Ich habe es so Verstanden das du einen Kamalio vor einen Asterisk setzt um eine vollständige PBX (ohne DAHDI ;)) zu implementieren. Inklusive Provisioning von Endgeräten. Und Providertemplates. Im Kontext einer Firewall.

Ich warte auf dein Konzept, aber mein Bauchgefühl sagt mir das die Ziele sehr hoch gesteckt sind, unabhängig von deiner oder mimugmails Expertise (die ich nicht anzweifle). Es geht mir um die reinen Mannstunden. Und den Sicherheitsaspekt. Jail hin oder her, die Attacksurface vervielfacht sich. Müssen ja auch nicht direkt RCEs sein.

Das erläutere ich zusammenhängend weiter unten. Allerdings noch ohne Präsentation.

Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]

Das hat nur leider niemand den Providern erzählt  :P

So was wie RFC3261 und 3550 / 4566 wird (meist) eingehalten. Da gebe ich dir Recht. Mir geht es eher um die Vermittlung (pots / inter-provider) und Signalisierung.

Ein Beispiel das ich gerne nehme sind Nummernformate. Welches Format soll die Zielrufnummer haben? Wie unterscheidet es sich lokal, national, international (das Unterscheidet sich auch nochmal per Provider und Zielregion)? Der Brüller: Nationale Sonderrufnummern.

In welchem Header wird die CLIP erwartet? PAI? PPI? Oder doch lieber FROM?
Wie signalisiere ich CLIR? Redirection / reflection?

¯\_(ツ)_/¯

Und dann die Fehlermeldungen... Was kommt bei Besetzt / Rejected zurück? Ungültige Rufnummer? Gesperrtem Account?
Am tollsten sind die Provider die Munter im Fehlerfall mit 200 OK antworten und eine Sprachnachricht über RTP drücken.

Ich kenne keine zwei Provider welche identische Spezifikationen befolgen. Es ist nicht mal garantiert das die Spezifikation innerhalb des selben Providernetzes konsistent sind.
SIP INVITES kommen mit führender +49... von dem einen SBC, 49... von dem nächsten und drei Tage später mit 0..., dann komplett ohne Präfix vom dritten SBC.

Das kenne ich selber, aber klar da du aus der Branche direkt kommst hast du immer damit zu tun und das es einen irgendwann in den Wahnsinn treibt, verstehe ich. Auch das du uns vor einem Projekt bewahren möchtest, welches evtl. niemals Released wird, aufgrund dauernd auftretender Probleme.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Tun sie nicht! Warum? "Die PBX ist schuld!" Es ist immer, grundsätzlich die PBX.
"Oh. Keine Fritz- / Digitalisierungsbox? Kein Support. Ach du willst nur die Specs? Die kann ich dir nicht geben. Kauf dir lieber die supportete™ PBX©".

Selbst wenn man einen PCAP mit RFC violations (INVITE nach 407 ohne Hash wiederholt, 407 Response ohne NONCE, unilateraler Codecwechsel ohne SDP, COMEDIA ignoriert, ...) vorweisen kann wird es im besten Fall still und heimlich gefixt und ohne Ankündigung ausgerollt. Schuld bleibt *drumroll* die PBX. Es wird gelogen, getrickst und intrigiert. Bis jemand weint.
Zugegeben, es gibt Provider die sehr transparent Arbeiten. Mit denen es Spaß macht solche Fehler auszuräumen. Der staatlich geförderte Monopolist ist keiner davon.

So. Ich gehe jetzt erst mal einen Kaffee trinken um von meinem Nerdrage wieder runter zu kommen. Hoffe ich konnte meine Punkte rüber bringen. Ich will euch nichts böses.

Und das wird auch nie ein Provider zugeben, bestes Bsp. hier: https://forum.opnsense.org/index.php?topic=7483.15. Hätte der Provider jetzt zugegeben, dass er bis dato nur die Fritz Box als VOIP Endgerät anhand des Useragents am System anmelden lässt. Hätte er sich vom Zeitraum an, ab dem per Gesetz die Routerfreiheit garantiert worden wäre sich strafbar gemacht und die Bundesnetzagentur hätte dagegen vorgehen können. Klar gab es früher kein Gesetz, aber immerhin hätte der Kunde aufgrund von Diskriminierung ein Sonderkündigungsrecht. Und das möchte kein Provider. Also bleibt es gegenüber dem Kunden so, das alles funktioniert (auch wenn das nicht der Fall ist) und am Ende wenn es dann mal funktioniert niemand was an einem System geändert hat.  ;)

Nun zu meiner Erklärung von oben, dazu zitiere ich mich ersteinmal selbst:

Naja, das es keine gute Idee ist, auf einer Firewall eine Vollwertige PBX laufen zu lassen, mal den Sicherheitsaspekt beiseite gelassen ist der, dass eine Vollwertige PBX zuallererst auch andere Dienste bereitstellt.
z.B. vollwertiges Endgerätemanagement, das heißt, Boot und Konfigurationsserver (DHCP, DNS, TFTP) sowie einen Datenbankserver für die Konfiguration sowie LDAP für ein Zentrales Telefonbuch.

Mal angenommen es gäbe für OPNsense Asterisk als Plugin, was alleine schon an Integrationsarbeit in die Weboberfläche und ins Konfig Management, eine Arbeit von mehreren Monaten wäre. Würde es nicht lange dauern und es gäbe Featurerequests in diese Richtung, diese oben genannten Features nachzureichen.

Indem Falle wäre sogar einfacher gleich direkt eine eigenständige PBX Distribution aus dem Boden zu Stampfen. Die eben nur eine Telefonanlage bereitstellt und einfach zu konfigurieren wäre.

Leider gibt es großartige keine OpenSource PBX Distributionen mehr, da die meisten alle Kommerzialisiert sind.
Dazu gehört meiner Meinung nach auch FreePBX. Sie wird zwar von vielen genutzt aber nur weil es keine alternativen gibt. Und FusionPBX ist zwar ohne Vorbehalte Frei verfügbar, aber ebenso schwer zu konfigurieren, selbst wenn man eine Anleitung hat. Das Freeswitch Wiki ist leider auch nicht wirklich gut Dokumentiert.

Wer Asterisk und Freeswitch über die Konfigurationsdateien konfigurieren kann, der braucht natürlich keine GUI, aber für alle die ihre FritzBox los werden wollen ist das wiederum keine Lösung. Eben sowenig eine Mobydick von Pascom.

Nun zu den Sicherheitsaspekten, würde Asterisk auf OPNsense als Plugin vorhanden sein, gäbe es irgendwann hier im Forum lauter Beschwerden, gehackt worden zu sein etc. Da Chan_SIP und PJ_SIP leider noch nicht ausgreift sind in Public Netzwerken zu lauschen. Und für Chan-SIP existieren Mittlerweile Scripte um Automatisiert Buffer Overflows zu erzeugen und dessen Sicherheitslücken sind ja nun weit bekannt. PJSIP soll ja in Zukunft CHAN_SIP ersetzen, ist aber leider noch nicht so ausgereift das es wirklich funktioniert.

Bei FreeSwitch gibt es diese Problematik nicht, aber dafür ist diese Software auch nicht so weit verbreitet. Es wurden dort zwar Dinge völlig neu bei der Programmierung durchdacht und dabei raus gekommen ist ansich eine gute Software, die aber leider etwas schlecht Dokumentiert ist und von Hand auch nur schlecht konfiguriert werden kann. Und leider Frisst FreeSwitch auch ziemlich viel CPU und RAM wenn man darüber viele Calls abwickeln möchte.

In FusionPBX ist Fail2Ban allerdings fest integriert. siehe hier

Man muss natürlich nicht mit dem von mir hier geschriebenen Meinungskonform gehen. Viele mögen auch eine andere Sichtweise auf die Dinge haben. Aber du kannst relativ gefahrlos Asterisk oder FreeSwitch hinter OPNsense mit dem Siproxd Plugin betreiben. Und das sollte ohnehin die einzige Aufgabe sein die eine Firewall wie OPNsense mit VOIP hat. Nämlich das Relayen von SIP und RTP. So findet zwar keine Direkte Komunikation mit den Provider Servern statt.

Aber auch eingehende Anfragen auf deine IP werden gar nicht an deine PBX weitergeleitet, sofern in Siproxd keine Information hinterlegt ist, das dies erwünscht ist. Angriffe enden also am Proxy ohne an die PBX weitergeleitet zu werden. Das heißt Ausländische Häcker könnten auch bei einem Konfigurationsfehler von Asterisk nicht teure Anrufe über deine Accounts leiten. Da Siproxd dich ja nicht bei deinem Provider registriert.

Villeicht wäre https://www.astlinux-project.org/ was für dich?

Bei Fragen bitte einfach wieder schreiben.

Und dieser Meinung bin ich auch weiterhin, auf einer Firewall oder UTM, hat keine Vollwertige PBX etwas zu suchen.
Aber was man machen kann, anstelle der Bereitstellung eines nur SIP und RTP Proxys, ein Modulares Bündel aus beidem bereitzustellen was sich durch sinnvolle Funktionen ergänzt. Soviel wie möglich, soviel wie nötig.

Daher ist Asterisk hier ideal aufgrund seiner Modulbauweise. Bei Asterisk wie auch Kamailio werden nachher alle Module entfernt die nicht gebraucht werden. Oder eher gar nicht erst kompiliert. Zudem ist PJ_SIP ein SIP Stack der nicht nur von einer Firma betreut wird, das heißt Fehler und Bugs werden hier evtl. viel schneller gefixt. Zudem ist der SIP Stack mit neueren Geräten eher kompatibel als chan_SIP. Das ist meine Subjektive Wahrnehmung.

Asterisk wird nur die Dinge bereitstellen die absolut nötig sind um sich bei einem Provider zu Registrieren, um ein Telefon an Asterisk zu Registrieren. Und einen einfachen Wählplan, mit wenigen Funktionen dafür aber sinnvollen.

Asterisk wird dabei die Externe Kommunikation nicht selbst übernehmen, sondern diesen Komplett über Kamailio abwickeln. Asterisk wird nur auf localhost horchen.

Kamailio soll hier den SIP Datenverkehr überwachen, und Asterisk Telefonen die Registrierung an Asterisk ermöglichen und Asterisk in Form eines Outbound Proxys die Anmeldung bei SIP Providern ermöglichen.

Überwachen heißt z.B. die Erkennung von DDoS Attacken und BruteForce Angriffe etc. Um Angriffe dann wirkungsvoll zu sperren soll Kamailio dann am besten von Fail2Ban unterstützt werden. Was aber nicht gehen wird, da Fail2Ban mit OPNsense so nicht kompatibel sein wird, da die Gefahr besteht das dann evtl. die Firewallregeln über den Haufen geworfen werden. Hier muss dann ein ähnliches Tool her was mit OPNsense kompatibel ist.

Kamailio selbst soll möglichst von Asterisk => Internet Stateful laufen. Während vom Privaten LAN hier ausnahmen existieren sollen, damit die Register Request von Lokalen Subnetzen auch an Asterisk weitergeleitet werden.

Asterisk wird hier also nicht im Realtime Mode mit Kamailio zusammen betrieben.

Sinnvolle Funktionen für Asterisk sind:
B2B = Asterisk registriert sich beim Provider und stellt über den Lokalen SIP Registrar diese Leitung zur Verfügung. Zudem Normalisierung durch Provider Templates.
Provider Templates = Einfache Registrierung bei Providern ohne Try and Error. Zur Ausarbeitung von Providertemplates muss herausgefunden werden, was Provider verändern können um inkompatibel zu einer Standard Konfig zu sein, SIP Header, Auth Header, user-agent, Rufnummern etc. Durch eingrenzen der Möglichkeiten ein Formular entwickeln die das Anpassen vereinfacht, darauf basieren dann die Templates. => Vorausgefülltes Formular. + AGI Skript im Hintergrund, welches sich um die Verarbeitung die den Wählplan betreffen kümmert.
Wahlregeln = Rufsperren, Umleitungen, einfaches Routing
Anrufliste
Interne Anrufe = Festlegen eigener Interner Rufnummern im Bereich XX.
Sicherheit = Schutz vor Missbrauch durch die oben genannten Vorkehrungen.
Konfigurierbar ohne Asterisk und Kamailio Kenntnisse = Durch die hohe Integrationsdichte aller Komponenten. Daher, ein in sich geschlossenes Plugin welches Asterisk und Kamailio in vorkompilierter Form unabhängig von einem Frei Konfigurierbaren Asterisk oder Kamailio Paket mitbringt. Das heißt, eigene Ordnerstruktur und Asterisk oder Kamailio sind nicht separat unabhängig voneinander nutzbar, eben auch wegen der Funktionseinschränkungen.

Soll also Asterisk oder Kamailio auf dem System für etwas anderes benutzt werden, muss das Kamailio oder Asterisk Paket installiert werden.

Was dieses Plugin nie können wird:
Anrufbeantworter, Faxsserver, Provisioning von Endgeräten und alle anderen hier nicht genannten Funktionen. z.B. Capi, Dahdi, etc.

Das Plugin stellt letztlich eine Basis dar, welche es ermöglichen soll, nachgelagerte SIP Clients im LAN sicher zu betreiben und Basisfunktionen dafür bereitzustellen. Alle Funktionen die dieses Plugin nicht kann, können daher einfach von einer Vollwertigen PBX im LAN übernommen werden. Ohne Sicherheitsbedenken für den Betreiber.

Zu den Providertemplates möchte ich noch hinzufügen, das ich dort nach Möglichkeit die Fritze auslesen werde als Arbeitserleichterung.

[mimugmail]

Konferenzräume wären noch geil :)

[NicholasRush]

Konferenzräume wären noch geil :)

Gut die habe ich auf die schnelle vergessen, aber in großem und ganzen soll das Plugin an einigen stellen mehr können als die Fritze an anderen eben weniger. Aber dafür dann richtig und vor allem sicher.

In den meisten Firmen ist es z.B. so, jemand der OpenSource einsetzt ist dann selber für die Sicherheit und im Fehlerfall Verantwortlich. Daher wollen die meistens IT-Chefs gerne nur Software einsetzen wo ihnen die Verantwortung abgenommen wird und der Hersteller dafür in die Bresche springt. Also im Endeffekt jemanden der im Schadensfall zahlt.

Daher denke ich, das dieses Plugin in Zukunft wohl trotz des durchdachten Sicherheitskonzepts, wohl kaum in Firmen genutzt werden wird und es eher Privatleute sein werden, die ihre Fritze gerne entsorgen möchten, die das Plugin dann nutzen.

[JeGr]

Auch wenn das hier schon komplett anders abgebogen ist:

Nick hatte in einem Absatz was geschrieben wie "lieber eine eigene kleine Distro auf Basis" und auf der Sense nur ein Proxy o.ä.
Das wäre tatsächlich der Ansatz den ich auch eher vertreten würde. Warum? Klar ist das schön alles in einem Gerät zu haben aber kann sich noch jemand erinnern, warum genau man die Fritzbox bspw. loswerden wollte? Genau, kann alles aber nix so richtig. Irgendwo hat man Einschränkungen. Und nur wegen der "schönen UI" eben den Dienst zu nutzen... kann man schon machen, aber ist auch irgendwo Overkill. Dann lieber ne eigene Appliance dafür. Kennt (noch) jemand pfDNS? Das war die gleiche Idee vor X Jahren. Hey wir haben nen DNS Server, haben HA-Failover etc. alles auf der pfSense - was wäre wenn wir ne abgespeckte Version machen und die UI nur für DNS nutzen? Wäre cool gewesen - hat aber niemand mehr weiter verfolgt weils einfach zu weit auseinander lag. Da kommt dann eben ins Spiel wohin ein Produkt (OPNsense) gehen soll. Security Gateway/Firewall mit Zusatzfunktionen? Fein. Eierlegende Wollmilchsau? Eher nicht. Jedes Teil bringt wieder Unsicherheiten mit ins Spiel und die haben auf dem Border Gateway (zumindest IMHO) nichts zu suchen :) Darf natürlich jeder sehen wie er möchte, aber keine Firma wäre da jetzt mega erfreut ihren Mailserver und die Telefonanlage alles auf der gleichen Kiste wie die Firewall zu haben. Dann kann man sich irgendwann die ganze Basis sparen und nimmt ne VM / nen Server von der Stange und installiert einfach alles drauf. Datenbank noch dazu, hier noch ein Modul, da noch ne Library... allein die Security von allen Paketen halbwegs zu gewährleisten wird dann endlos.

Daher: Ich finde euer Vorhaben ambitioniert und toll, aber würde es auch eher als extra-Appliance sehen. Außer - wie Nick richtig sagt - ein paar Privatleuten wird das sonst niemand nutzen wollen. In Firmen würde das niemand so aufsetzen (wollen).

Grüße

[fabian]

In den meisten Firmen ist es z.B. so, jemand der OpenSource einsetzt ist dann selber für die Sicherheit und im Fehlerfall Verantwortlich. Daher wollen die meistens IT-Chefs gerne nur Software einsetzen wo ihnen die Verantwortung abgenommen wird und der Hersteller dafür in die Bresche springt. Also im Endeffekt jemanden der im Schadensfall zahlt.

Würde mal vermuten, dass die das dann auch nicht zahlen, aber ne Versicherung würde das bei einem Produkt X mit Zertifikat Y ggf. tun.

[NicholasRush]

@fabian

Genau darum geht es den meisten, ein Plugin oder ein OpenSource Produkt kann noch so sicher sein, trotzdem wollen viele das nicht und zahlen dann lieber 6000 - 8000 € Lizenzkosten einer Firma wo sie blind auf die Sicherheit vertrauen müssen.

@JeGR

Mir geht es nur darum, würde das Plugin nur den Kamailio Proxy liefern, müsste ich ggf. ne Anleitung schreiben wie man den Konfiguriert, da das allerdings so kompliziert ist, für Zweck X, Konfiguration Y zu erklären. Mit allem wenn und aber und wieso. Wäre es doch besser ein Plugin zu bauen, was den am meisten benötigten Bereich abdeckt. Statt hinzugehen und in den Anleitungen dann noch erklären zu müssen wie Asterisk, Freeswitch, Yate, etc. über Kamailio sich beim Provider anmelden können.

Wie ich oben schon schrieb:

Sinnvolle Funktionen für Asterisk sind:
B2B = Asterisk registriert sich beim Provider und stellt über den Lokalen SIP Registrar diese Leitung zur Verfügung. Zudem Normalisierung durch Provider Templates.
Provider Templates = Einfache Registrierung bei Providern ohne Try and Error. Zur Ausarbeitung von Providertemplates muss herausgefunden werden, was Provider verändern können um inkompatibel zu einer Standard Konfig zu sein, SIP Header, Auth Header, user-agent, Rufnummern etc. Durch eingrenzen der Möglichkeiten ein Formular entwickeln die das Anpassen vereinfacht, darauf basieren dann die Templates. => Vorausgefülltes Formular. + AGI Skript im Hintergrund, welches sich um die Verarbeitung die den Wählplan betreffen kümmert.
Wahlregeln = Rufsperren, Umleitungen, einfaches Routing
Anrufliste
Interne Anrufe = Festlegen eigener Interner Rufnummern im Bereich XX.
Sicherheit = Schutz vor Missbrauch durch die oben genannten Vorkehrungen.
Konfigurierbar ohne Asterisk und Kamailio Kenntnisse = Durch die hohe Integrationsdichte aller Komponenten. Daher, ein in sich geschlossenes Plugin welches Asterisk und Kamailio in vorkompilierter Form unabhängig von einem Frei Konfigurierbaren Asterisk oder Kamailio Paket mitbringt. Das heißt, eigene Ordnerstruktur und Asterisk oder Kamailio sind nicht separat unabhängig voneinander nutzbar, eben auch wegen der Funktionseinschränkungen.

Natürlich sollte eine Firewall Appilance wie OPNsense keine Telefoniefunktionen bieten und lediglich für den Netzwerkverkehr zuständig sein. Es gibt nur einige Features, die, sobald man die weglässt, es später anfragen gibt ob nicht doch eingefügt werden können. Ich wäre mit dem Plugin schon zufrieden, wenn das Sicherheitskonzept "[Kamailio + Asterisk] mit dem Feature B2B und den Provider Templates wäre.
B2B heißt, dass sich Asterisk beim Provider über Kamailio registriert, und eine Interne PBX im LAN sich nachher am Asterisk auf OPNsense registriert um den Provider Account zu nutzen. Und mehr Features nicht. Der rest würde nur eingebaut werden damit alle die die FritzBox Features wollen auch nicht zu kurz kommen. Nach mir bräuchte ich die ehrlich gesagt nicht. Es geht sich mir da mehr darum, das der "vergewaltigte" SIP Stack der Provider damit aufgelöst wird und an der OPNsense endet. Und das Hacker und Scriptkiddys das Hacken der Asterisk Instanz auf OPNsense so schwer wie möglich gemacht wird, eben durch die Sicherheitsvorkehrungen. Was jeder nachher in seinem LAN macht und ob die Nebenstellen da Passwörter mit "1234" bekommen. Ist dann vollkommen egal. Da jeder Hacker, Cracker und Scriptkiddy so nur bis zu Kamailio kommt. Und weiter nicht mehr. Und das so zu lösen geht nur indem Asterisk eben auch auf der Sense läuft. Aber mit minimalsten Modulen.

Allerdings wie @Alphakilo schrieb, ist das nicht einfach, da jeder Provider sein eigenes Ding macht etc. Das wird noch sehr schwierig werden. Aber so gibt es natürlich dann auch die Möglichkeit, Konfigrationstemplates für SIP-Provider an Zentraler Stelle zu sammeln. Und nach Möglichkeit jedem der eine PBX im LAN betreiben möchte, durch "Plug and Play" seine PBX beim Provider über das Plugin anzumelden.

[JeGr]

> Allerdings wie @Alphakilo schrieb, ist das nicht einfach, da jeder Provider sein eigenes Ding macht etc. Das wird noch sehr schwierig werden.

Das ist leider in der Praxis ein fieses Problem. Wir haben selbst mit einer Sense Installation (pfSense aber recht minimal konfiguriert) ewig mit einem Kunden über ein halbes Jahr Dumps, Traces und Debugging Logs gesammelt um zu belegen, dass der Netzwerk & Security Part NICHT schuld an den Telefonieproblemen ist, weil ein UDP SIP Paket einfach nicht in der Art funktioniert: Hmm dich lasse ich durch, dich nicht und bei dir warte ich 5s bis es Ton gibt... Irgendwann kam dann raus, dass Telefonanlage, Konfiguration und SIP Provider nicht 100% kompatibel waren, weil der Provider seine Specs nicht offen gelegt hatte und die Anlage andere Werte angenommen hatte. Was ein Drama...

[NicholasRush]

Was würdet Ihr denn von einem solchen Plugin erwarten. Oder anders, welche Funktionen sind für euch da wichtig.

Allerdings unter der Berücksichtung, das OPNsense eine Firewall Appilance ist, kein FritzBox Ersatz wird. Am Ende kein, kann viel und doch nichts richtig, bleibt.

@JeGr

Sowas wie pfDNS soll dieses Plugin nämlich nicht werden. Eine eierlegende Wollmilchsau ist ja auch nicht mein Ziel. Aber ein Plugin welches niemand nutzt möchte ich auch nicht anfangen zu entwickeln. Es bringt ja nichts an den Nutzern vorbei zu arbeiten.

[mk]

Auch wenn der Thread schon etwas älter ist und das nach meinem Verständnis eh schon als Feature angedacht ist:
ich würde v.a. eine Protokollumsetzung von IPv4<->IPv6 sinnvoll finden. Dafür besteht IMO echt Bedarf:
Bisher hab ich nur bei Grandstream bezahlbare SIP-ATAs mit IPv6-Unterstützung gesehen (und bei einem anderen chinesischen Hersteller, den man kaum herkriegt und dessen Namen ich konsequenterweise schon vergessen habe). Umgekehrt gibt es Provider (M-Net), die VoIP nur über IPv6 machen; andere (easybell) bieten es zwar nur zusätzlich zu VoIP über IPv4 an, dort würde ich es aber trotzdem vorziehen, weil man dann bei DS-Lite keine VoIP-Streams über den AFTR-Tunnel leiten muss.

[NicholasRush]

Auch wenn der Thread schon etwas älter ist und das nach meinem Verständnis eh schon als Feature angedacht ist:
ich würde v.a. eine Protokollumsetzung von IPv4<->IPv6 sinnvoll finden. Dafür besteht IMO echt Bedarf:
Bisher hab ich nur bei Grandstream bezahlbare SIP-ATAs mit IPv6-Unterstützung gesehen (und bei einem anderen chinesischen Hersteller, den man kaum herkriegt und dessen Namen ich konsequenterweise schon vergessen habe). Umgekehrt gibt es Provider (M-Net), die VoIP nur über IPv6 machen; andere (easybell) bieten es zwar nur zusätzlich zu VoIP über IPv4 an, dort würde ich es aber trotzdem vorziehen, weil man dann bei DS-Lite keine VoIP-Streams über den AFTR-Tunnel leiten muss.

Da hast du natürlich recht, als Feature ist es jetzt allerdings nicht (mehr) angedacht, weil OPNsense ansonsten zu einer Art FritzBox verkommen würde, und wenn du dir den ganzen Thread mal durchliest wirst du sehen, das es zwar schon Bedarf gibt, es aber unmöglich ist eine Vollwertige PBX oder besser Telefonanlage in OPNsense zu integrieren. Es ist natürlich ebenso ärgerlich, allen Fragenden wo das SIProxd Plugin nicht funktioniert, mitteilen zu müssen das sie für VOIP besser ihre FritzBox der OPNsense nachschalten sollen.

Bis auf weiteres habe ich zu diesem Plugin auch meine Überlegungen verworfen, denn wie @Alphakilo hier bereits schrieb ist eine Anpassung an jeden Provider extrem schwierig und Zeitaufwendig. Und das ist leider auch von 3 Leuten die dann an dem Plugin gearbeitet hätten leider so nicht möglich.

[mimugmail]

Ich würde das auch erst mal zurückstellen. Mir fehlt etwas die Zeit hier komplett was Neues anzufangen und paar andere Plugins haben noch Vorrang :)