Lesedauer: 14 Minuten

Selfmade OPNsense Appliance  – In diesem Artikel möchte ich einen Einblick und eine kleine Bauanleitung liefern, wie ich mir auf Basis von OPNsense und entsprechender Hardware eine eigene Firewall-Appliance gebaut habe. Vielleicht als Anregung selbst ein solches Projekt umzusetzen? Es lohnt sich!

Ausgangspunkt – Wieso eine OPNsense Appliance?

Wieso eigentlich eine OPNsense Firewall Appliance, wenn eine Fritz!Box eh alles erledigen kann? Für die Antwort muss ich etwas ausholen:

Alles begann mit dem Hausbau 2014/2015. Beim Anschluss des Grundstücks bzw. des Hauses mit einer Erdgasleitung wurde mir angeboten ein Leerrohr für Glasfaser mit zu installieren. Diesbezüglich hatte ich mich schon im Vorfeld informiert, denn mir war schon eher zu Ohren gekommen, dass die örtlichen Stadtwerke den Breitbandausbau übernommen und (nicht nur) für diesen Zweck eine eigene Firma gegründet hat: Telepark Passau (TPP) GmbH.

Natürlich habe ich sofort zugestimmt und die entsprechenden Verträge unterzeichnet, dass die Glasfaser auf meinem Grund verlegt werden darf. Zuvor hatte ich in der Mietwohnung nur unweit vom Baugrund nur eine poplige 6000er DSL-Leitung. Da kam mir das Angebot durchaus wie ein Internet-Segen vor 🙂

Ich habe also eine 50.000er FTTH Leitung genommen und war mehr als glücklich. Der einzige Wermutstropfen: Man musste die mitgelieferte Fritz!Box 7360 benutzen, damit das VoIP funktionierte. Die Zugangsdaten wurden nicht mitgeteilt, die Routerfreiheit kam per Gesetz erst 2016.

Nachdem ich schon bei der Hausplanung eine großzügige Ethernetverkabelung und professionelle Accesspoints vorgehesen hatte, benötigte ich die Fritz!Box weder für’s WLAN, noch als Switch.

In Summe habe ich etwa 450m CAT.7 Kabel verlegt, die in einem kleinen 19 Zoll Schrank in ein Patchfeld enden. Ich kann nur jedem empfehlen beim Hausbau an eine ordentliche Netzwerk-Infrastruktur zu denken, das erspart einem danach viel Ärger (WLAN-Abdeckung, LAN-Dosen etc.).

Genau in diesem 19 Zoll Schrank steckt also mein kleiner Supermicro Server, ein 24Port PoE Switch und sämtliche Geräte, wie Glasfaser ONT, Fritz!Box, Überspannungsschutz etc.

Einziges Ärgernis war für mich immer die Fritz!Box mit ihren ganzen mehr oder weniger schnell gefixten Sicherheitslücken. Dann auch noch der dubiose Fernzugriff, den man zwar deaktivieren kann, aber trotzdem aus meiner Sicht in einer „Firewall“ nichts zu suchen hat.

Am 01.08.2016 kam dann endlich per Gesetz die Routerfreiheit, die es Providern untersagte, die Kunden zu einer mitgelieferten Box (Modem/Routerkombi) zu zwingen. Kurze Mail an den Support und etwas „Aufklärungsarbeit“ von meiner Seite und schon erhielt ich zwei Tage später meine Zugangsdaten in Händen.

Mangels Zeit konnte ich mein Vorhaben aber erst kürzlich mit der Umstellung meines Anschlusses auf 100MBit/s umsetzen: Austausch der Fritz!Box gegen eine OPNSense Firewall Appliance. OPNsense ist ein Fork von der bekannten und erfolgreichen pfsense. OPNsense bietet jedoch mehr Funktionen und eine wesentlich bessere und verständlichere Weboberfläche.

Neben der professionellen Firewall bietet OPNsense noch weitere Features, die man in der Fritz!Box nur vergeblich sucht: OpenVPN z.B., oder das Realisieren einer echten DMZ. Und ganz wichtig für mich: Leistungsfähigkeit abhängig von der eingesetzten Hardware und damit auch der Einsatz an einer 250MBit/s-Leitung (oder zukünftig noch mehr) möglich.

Parallel zur OPNsense sollte die VoIP-Funktion direkt von einem Gigaset C430A Go übernommen werden, das man so einstellen kann, dass es sich direkt beim SIP-Server anmeldet.

Anfangs dachte ich noch daran OPNsense in einer VM laufen zu lassen, wovon ich aber schnell Abstand nahm. Zum einen wegen Sicherheitsbedenken und zum anderen wegen keinerlei Redundanzen (alles auf einem Server).

Soweit also der Plan.

Umsetzung – Supermicro X11SBA-LN4F als Basis

Supermicro X11SBA-LN4F

Supermicro X11SBA-LN4F

Nach etwas Sucherei bin ich auf das für mich ideale OPNsense Mainboard gestoßen, das Supermicro X11SBA-LN4F (Herstellerseite). Mit über 200€ nicht gerade billig, aber die Ausstattung kann sich sehen lassen:

  • Intel Pentium N3700 SoC mit 4 Kernen à 1,6GHz und nur 6W(!) TDP. Die Leistung sollte auch für mehr Bandbreite und VPN-Server ausreichen.
  • 4 Stk. Intel Netzwerkkarten onboard. Ausreichend Netzwerk-Schnittstellen für LAN, WAN, DMZ etc.
  • IPMI-Schnittstelle für die Fernwartung über den Browser. Wer es einmal hatte, will es nicht mehr missen.

Passend für dieses Board empfiehlt Supermicro das Gehäuse SuperChassis SC504-203B (Anschlüsse hinten) oder das SC505-203B (Anschlüsse vorne). Das Gehäuse enthält bereits ein 80W Netzteil, weshalb am Ende nur noch RAM und eine Speichermedium für das Betriebssystem fehlen. Ich selbst habe mich für die Gehäusevariante mit den Anschlüssen vorne (SC505-203B) entschieden, da ich so direkt aufpatchen kann und das Handling wesentlich einfacher wird.

SuperChassis SC505-203B

SuperChassis SC505-203B

Als RAM habe ich mich für den Kingston KVR16LS11/4 entschieden. 4GB RAM sind mehr als ausreichend für meine Konfiguration. Wichtig ist aber, dass das Board einen Arbeitsspeicher mit 1,35V benötigt und keinen mit 1,5V!

Festplatten sind out und sind auch viel zu groß für OPNsense, weshalb ich eine kleine (Speicher und Dimensionen) SSD eingesetzt habe: TRANSCEND HSD370 mit 16GB.

In Summe kommt der Spass also auf etwa 360€. Nicht billig, aber dafür performant und (hoffentlich) zukunftssicher.

Eine interessante Alternative für alle, die keinen 19 Zoll Schrank haben ist die fertige Supermicro Konfiguration als SuperServer E200-9B. Das gleiche Board in einem kompakten Gehäuse als Barebone.

Übrigens gab es mit dem Board anfangs Probleme, wovon man sich nicht abschrecken lassen sollte, da mit der aktuellen HW-Revision 1.02 das Thema schon lange erledigt ist.

Zusammenfassung:

Montage der Hardwarekomponenten

Die Montage der Hardwarekomponenten ist denkbar einfach. Nachdem das Board bereits mit einer CPU inkl. dem Kühlkörper bestückt ist, muss man sich um die Montage des Prozessors nicht mehr kümmern.

SuperChassis SC505-203B

SuperChassis SC505-203B

Hat man den Gehäusedeckeln entfernt sieht man auf der linken Seite die Markierungen für das Board und die dazugehörigen Bohrungen für die Verschraubung. Hier müssen lediglich noch die mitgelieferten Schrauben/Muttern an den passenden Löchern montiert werden. Für die richtige Schraubenposition hält man einfach das Board an die Montagestelle und merkt sich die Löcher.

SuperChassis SC505-203B

SuperChassis SC505-203B

Vor der Montage des Mainboards muss man noch das Frontblech ausbrechen, damit alle Anschlüsse zugänglich sind. Ein Monitoranschluss wird zwar verdeckt, was für mich aber irrelevant ist, da ich sowieso keinen Monitor anschließen werde. Selbst wenn, der VGA-Anschluss ist auf alle Fälle zugänglich.

Im Anschluss habe ich gleich den RAM-Riegel gesteckt, da dieser nach der Verkabelung nicht mehr vernünftig zugänglich ist. Achtung: SO-Dimms müssen schräg in den Slot gesteckt und dann nach unten in die Halterung gedrückt werden bis sie einrasten. Gleiches Prinzip wie bei einem Laptop.

X11SBA-LN4F - Verkabelung

X11SBA-LN4F – Verkabelung

Nun kann man das Board entsprechend verschrauben und die Verkabelung angehen. Der Stecker der Spannungsversorgung hat übrigens 20 Pins, der Anschluss auf dem Board 24 Pins. Daran nicht stören und einfach die rechten vier Pins frei lassen – das funktioniert tadellos.

SSD Transcend HSD 370

Jetzt noch die SSD per SATA-Kabel an das Board und an das Netzteil anschließen und wir sind so gut wie fertig. Abschließend habe ich noch etwas doppelseitiges Klebeband genommen und die SSD damit im Gehäuse festgeklebt. Der Formfaktor der SSD hat leider keine passenden Bohrungen, um das Ding zu verschrauben. Theoretisch müsste man sie aber nicht festkleben, funktioniert genauso, wenn man sie einfach ins Gehäuse legt.

Kaltgerätekabel ans Netzteil und in die Steckdose und wir sind bereit für einen ersten Start 🙂

IPMI Konfiguration und OPNsense Installation

Als nächsten wollen wir uns daran machen OPNsense zu installieren. Und hierzu kommt gleich mal die IPMI Schnittstelle zum Tragen. Der typische Systemadministrator mag es bequem, und genau deshalb brauchen wir für die Installation und Verwaltung unseren kleinen Servers lediglich IPMI und kein Installationsmedium oder gar Maus, Tastatur und Monitor direkt am Server.

IPMI-Schnittstelle an das Netzwerk angeschlossen

IPMI-Schnittstelle an das Netzwerk angeschlossen

Es gibt zwar extra IMPI-Konfigurationstools, aber man kann es auch einfacher machen, denn zu Beginn benötigt man v.a. eines: Eine IP-Adresse an der Schnittstelle. Ich verbinde dazu die IPMI-Schnittstelle einfach mit einem Netzwerkkabel mit meinem Netzwerk. Der DHCP-Server der Fritz!Box vergibt auch sofort eine IP-Adresse, man muss diese nur in der Liste der verbundenen Geräte ausfindig machen.

Kennt man die vergebene IP, gibt man diese einfach in die Adresszeile des Browsers ein und schon kann man sich einloggen. Übrigens muss dazu der Server nicht mal laufen, es reicht, wenn er Strom hat. IPMI ist nämlich immer aktiv, sobald das Board Spannung bekommt.

Der Standard-Login für den Benutzer und das Passwort ist jeweils ADMIN. Komplett groß geschrieben.

Danach über Configuration -> Network eine statische IP vergeben. Das war’s eigentlich auch schon im Webmenü.

IPMIView

IPMIView

Als nächstes besorgt man sich das kleine Java-Tool IPMIView, das es bei Supermicro in den IPMI Utilities enthalten ist und als Download bezogen werden kann.

Nach dem Download entpackt man die ZIP-Datei in einen beliebigen Ordner. IPMIView muss nicht installiert werden, man muss es nur starten. Dies erfolgt unter Linux mit folgendem Befehl:

java -jar ./IPMIView.jar

In dem nun geöffneten Fenster geht man wie folgt vor, um sich mit dem Server zu verbinden und dessen „Monitorausgabe“ zu sehen:

  1. Links oben auf „Add a new system“ klicken.
  2. Die erforderlichen Angaben, v.a. die IP-Adresse der IPMI Schnittstelle, eingeben.
  3. Das neue System wir links eingetragen, nun doppelt anklicken und man erhält recht die Login-Maske.
  4. Nach dem Login wählt man in den Registern unten ganz rechts den Eintrag KVM Console und klickt dann auf Launch KVM Console.
  5. Es öffnet sich ein Fenster, das genau das ausgibt, was ein an den Server angeschlossener Monitor zeigen würde.

Was uns jetzt noch fehlt ist natürlich das passende OPNsense Installationsmedium, uns reicht in diesem Fall das ISO. Auf der OPNsense Downloadseite wählt man Architecture = AMD64 und als Image Type = dvd.

Hat man das OPNsense Image heruntergeladen ist es ein einfaches es über IMPI einzuhängen. Dazu klickt man in der noch offenen KVM Console auf Virtual Media und dann auf Virtual Storage.

IPMIView: Virtual Storage

Bei Logical Drive Type wählt man ISO File und sucht über den Button Open Im… das gerade heruntergeladene OPNsense ISO.  Danach klickt man auf Plug In und schon ist die Installations-ISO über die IPMI-Schnittstelle am Server eingehängt und man kann davon installieren.

Entweder man startet den Server neu (KVM Console -> Power Control  -> Power Reset) oder man schaltet ihn ein (Power On), danach sollte bereits OPNsense als Livesystem booten.

OPNsense Login

OPNsense Login

Hat OPNsense fertig geladen, meldet man sich mit dem Benutzer=installer und dem Passwort=opnsense an. Danach folgt man dem Installationsdialog. Eine detaillierte Beschreibung dazu findet man z.B. HIER.

Sobald der Installationsprozess beendet ist, entfernt man das ISO mit Plug Out wieder und schließt die KVM Console bzw. das IPMIView – ab jetzt erfolgt die weitere Konfiguration über das Webmenü von OPNsense.

OPNsense Konfiguration für Internet und VoIP

Grundkonfiguration WAN/LAN

Grundsätzlich braucht eine Firewall bzw. ein Router mindestens ein WAN Interface und ein LAN Interface. Das sogennante WAN (Wide Area Network) ist der Zugang zum Internet, während das LAN (Local Area Network) unser internes (Heim-)Netzwerk darstellt.

Die Festlegung welches physikalische Interface, sprich, welcher Netzwerkadapter für WAN und welcher für LAN zuständig ist, wurde bereits während der Installation von OPNsense festgelegt. Achtet dabei auf die Nummerierung: igb0 ist der LAN-Port links unten, igb1 der rechts unten usw. Am Ende wollen die Kabel ja richtig angeschlossen werden 😉

Bei Telepark Passau erfolgt der Anschluss der OPNsense Appliance mit dem WAN-Interface direkt an das „Glasfaser-Modem“, sprich den ONT (Optical Network Terminal). Es erfolgt keine Einwahl oder dergleichen, das angeschlossene Gerät bekommt per DHCP eine IP vom Provider zugewiesen, das war’s. PPPOE wäre auch möglich mit OPNsense, ist bei mir aber nicht nötig (OPNsense direkt am DSL-Modem z.B.).

Die LAN-Schnittstelle konfigurieren wir dagegen mit einer statischen IP-Adresse:

  • Schnittstellen -> LAN -> Allgemeine Konfiguration -> IPv4 Konfigurationstyp -> Statisches IPv4
  • Schnittstellen -> LAN -> Statische IPv4 Konfiguration -> IPv4-Adresse

Soweit so gut. Jetzt kann man grundsätzlich die OPNsense an den ONT hängen, das LAN-Interface auf den Switch aufpatchen und die Fritz!Box vorher kappen bzw. aus dem Netzwerk entfernen. Das Internet läuft jetzt bereits über die OPNsense.

Grundkonfiguration VoIP VLAN

Der Internetzugang funktioniert, was noch fehlt ist die Konfiguration für das VoIP VLAN. Moderne Internetanschlüsse sind sogenannte „All-IP-Anschlüsse“, d.h. die Telefonie läuft genauso über die Internetleitung, wie der normale Datenverkehr. Rein technisch ist es nicht nötig diese Telefonie-Datenpakete in ein eigenes Sub-LAN zu packen, es hat aber seine Vorteile:

  • Strikte Trennung von reinem Datenverkehr und Telefonie.
  • Aus dem Internet ist die Telefonie nicht direkt angreifbar.
  • Festlegung von Prioritäten für VoIP-Datenpakete: besser Gesprächs- und Verbindungsqualität, auch wenn die Internetleitung mit Down- und Upload von Daten belastet wird.

Durch den Einsatz eines VLANs wir also ein zweites, virtuelles LAN erzeugt, das vom regulären Netzwerk abgetrennt ist. Geräte, die sich in einem VLAN befinden können nur bedingt mit Geräten in anderen VLANs oder LANs kommunizieren (nur über Routing).

Das VoIP läuft bei TPP im VLAN40, d.h. Datenpakete müssen mit dem VLAN Tag 40 versehen werden, damit sie sich in diesem virtuellen Netzwerk bewegen können. Das Gigaset C430A Go könnte theoretisch selbst den Datenverkehr taggen, allerdings verliert man dann die Verbindung zum Gigaset, wenn man sich nicht ebenfalls in diesem VLAN aufhält. In meinem eigenen LAN ist das VLAN-Tagging irrelevant, da ich nur ein Netz habe und nicht extra für das eine Telefon ein VLAN über alle Geräte einrichten werde. Mein Netzwerk ist so performant, dass eine Priorisierung von Telefonie-Daten nicht nötig ist.

OPNSense: VLAN einrichten

OPNSense: VLAN einrichten

Das hat zur Folge, dass lediglich OPNsense eine Verbindung zum VLAN40 aufbauen muss. Darüber hinaus muss OPNsense wissen, wem die Daten aus dem VLAN40 im internen LAN gehören (dem Gigaset) und wer aus dem internen LAN welche Pakete (an bestimmte Ports) ins VLAN40 senden darf bzw. sogar muss (Gigaset). Mit einer richtigen Konfiguration erreicht man, dass die Telefondaten zwar richtig ins VLAN40 gelangen und aus dem VLAN40 auch das Gigaset erreichen, aber Nicht-VoIP-Kommunikation über das herkömmliche Internet läuft. So muss z.B. das Gigaset zur Namensauflösung den DNS-Server aus dem Internet nutzen (im VLAN gibt es bei TPP keinen DNS-Server). Aber auch Features wie Firmware-Updates etc. kann das Gigaset ledigleich über das Internet beziehen.

Dieses VLAN40 müssen wir jetzt also in der OPNsense konfigurieren und mit dem WAN-Port verbinden:

  • Schnittstellen -> Andere Typen -> VLAN -> Hinzufügen
  • Übergeordnete Schnittstelle = WAN
  • VLAN Tag = 40
  • VLAN-Priorität (PCP) = 5 (Stimme)
  • Beschreibung = VLAN40
  • Schnittstellen -> Zuweisungen -> Neue Schnittstelle -> VLAN 40 auf igb0 -> + anklicken
  • Schnittstellen -> [OPTX] -> Schnittstelle aktivieren -> Beschreibung = VLAN40
  • Im gleichen Menü: IPv4 Konfigurationstyp -> DHCP
  • Das ganze mit SPEICHERN bestätigen

Jetzt sollte man im Dashboard unter Schnittstellen und Gateways erkennen, dass eine Verbindung sowohl zum normalen WAN, als auch zum VLAN40 besteht. Das VLAN40 hat dabei ein eigenes Gateway und die virtuelle Schnittstelle für VLAN40 auch eine eigene IP-Adresse zugewiesen bekommen. Eine Verbindung ins VLAN40 besteht also, jetzt muss man sich „nur noch“ um die richtigen Firewallregeln und die Gigaset-Konfiguration kümmern.

OPNsense Dashboard: Gateways und Schnittstellen

Firewallregeln für VoIP

Eine Verbindung zum Internet und eine parallele Verbindung zum VLAN40 konnten wir also hiermit aufbauen. Was jetzt noch fehlt, damit VoIP funktioniert, sind die entsprechenden Firewallregeln die den Datenverkehr in die richtige Richtung „leiten“:

  • Das Gigaset muss über VLAN40 eine Verbindung zum SIP-Server aufbauen.
  • Der Datenverkehr bzgl. Telefonie muss über VLAN40 ein- und ausgehend erfolgen.
  • Der restliche Datenverkehr, wie Namensauflösung oder sonstige Zusatzfunktionen des Gigaset (z.B. Wetteranzeige) darf und soll über das normale Internet laufen.

Um dies zu erreichen, richtet man sich als erstes am besten sogenannte Aliase ein, damit man nicht immer jeden Port und/oder IP eintragen muss.

  1. Alias: Name=Gigaset, Wert=IP-Adresse des Telefons im LAN
  2. Alias: Name=SIP, Wert=5060 (SIP Port)
  3. Alias: Name=RTP, Wert=7078:7097 (RTP Ports, die in der FB eingestellt waren)
  4. Alias: Name=Registrar, Wert=IP-Adresse des SIP-Servers
OPNsense Aliases

OPNsense Aliases

Nach dem Anlegen der Aliase kann man sich jetzt an die Firwallregeln machen:

  • Firewall -> Regeln -> LAN – Der Datenverkehr vom Gigaset zum SIP-Port und den RTP-Ports muss über das VLAN40-Gatenway erfolge.
OPNsense: VoIP-Regeln für LAN

OPNsense: VoIP-Regeln für LAN

  • Firewall -> Regeln -> VLAN40 – Der Datenverkehr zum Gigaset SIP- und RTP-Port.

OPNsense: VoIP-Regeln für VLAN40

  • Firewall -> NAT -> Ausgehend 

OPNsense: VoIP NAT ausgehend

  • Firewall -> NAT -> Portweiterleitung – Zum Schluss leiten wir noch die SIP und RTP-Ports eingehend an das Gigaset-Telefon weiter
OPNsense: VoIP Portweiterleitungen

OPNsense: VoIP Portweiterleitungen

Mit diesen Einstellungen ist die Basis für den VoIP-Datenverkehr vom/zum Gigaset sichergestellt. Zumindest funktioniert dies bei mir wunderbar. Damit will ich nicht ausschließen, dass die ein oder andere Konfig überflüssig oder zu viel ist. Bis es bei mir endlich funktionierte, musste ich einige Zeit investieren und rumprobieren, weshalb ich nicht mehr gewillt war, das Funktionierende nochmal zu reduzieren und zu testen 😉 (zu der Rumprobiererei später mehr).

Gigaset C430A Go für VoIP bei TPP konfigurieren

Natürlich will zum Schluss auch noch das Telefon selbst konfiguriert werden. Das ganze erledigt man am Besten über das Webmenü der Basisstation.

Zu allererst verpasst man dem Gigaset eine statische IP-Adresse, die natürlich mit der in der OPNsense-Konfiguration übereinstimmen muss. Das ganze findet man unter Einstellungen -> Netzwerk -> IP-Konfiguration.

Unter Telefonie -> Verbindungen klickt man auf den „Bearbeiten“-Button bei einer freien/unkonfigurierten Verbindung und stellt bei TPP folgendes ein:

  • Anmeldename: Euer Username bzw. die Telefonnummer
  • Anmeldepasswort: Euer SIP-Passwort
  • Benutzername: Euer Username bzw. die Telefonnummer
  • Angezeigter Name: Euer Username bzw. die Telefonnummer
  • Domain: ngn.telepark-passau.de
  • Proxy-Serveradresse: ngn.telepark-passau.de
  • Proxy-Serverport: 5060
  • Registrations-Server: ngn.telepark-passau.de
  • Registrations-Serverport: 5060
  • Anmelde-Refreshzeit: 1800 Sek.
  • STUN benutzen: Nein
  • Outbound-Proxymodus: Nie
  • Netzwerkprotokoll: Entweder „Automatisch“ oder „UDP“
Gigaset: VoiP Konfiguration

Gigaset: VoiP Konfiguration

Weitere Einstellungen müssen im Gigaset eigentlich nicht getroffen werden. Das Telefon sollte sich am SIP-Server anmelden und Telefonate sollten ein- und ausgehend funktionieren, wie man es erwartet.

Meine anfänglichen Probleme mit der VoIP-Konfiguration

Eigentlich habe ich gar nicht mehr erwartet, dass ich das Gigaset direkt an der OPNsense betreiben kann. Egal was ich eingestellt hatte, das Gigaset konnte nie eine Verbindung zum SIP-Server aufbauen.

Damit ich nicht komplett ohne Telefon war, habe ich die noch vorhandene Fritz!Box hinter die OPNsense geklemmt und etwas umkonfiguriert. Im Endeffekt übernam die FB nur noch die VoIP-Einwahl. Übrigens funktionieren obige Firewall-Regeln etc. genauso, wenn man diese statt auf die IP vom Gigaset auf die IP von der FB konfiguriert.

Der ausführliche Leidensweg dazu findet sich im OPNsense-Forum.

Ende vom Lied war, dass ich über Paketanalyse (Wireshark) feststellte, dass die VoIP-Pakte nach Regensburg zur Regenburger Telekommunikations GmbH (R-KOM bzw. Glasfaser Ostbayern) gingen. Anscheinend wird die VoIP-Leistung dort eingekauft – was mir später auch bestätigt wurde.

Nach etwas Google-Hilfe fand ich zwei interessante Seiten (1 und 2), die von ähnlichen Problemen berichteten: VoIP mit Fritz!Box geht, ohne bzw. mit Gigaset nicht.

Daraufhin habe ich TPP angeschrieben, wo mir sofort und unkompliziert versucht wurde zu helfen – obwohl meine Konfiguration mit OPNsense alle andere als Standard ist. An dieser Stelle mal ein großes Lob, so einen Support würde man bei großen Telekommunikationskonzernen sicherlich nicht auf diese Weise erhalten. Es wurde mir jedenfalls versichert, dass auf Nachfrag bei der R-KOM keine Filterung nach Agent-ID oder dergleichen erfolgt.

Nachdem ich jedoch eine andere Erfahrung machen musste, wollte ich erneut die Pakete aufzeichnen und mit Wireshark auswerten. Diesmal aber direkt vom Gigaset zum SIP-Server. Dazu habe ich nur die Alias-IP in der Firewall auf das Gigaset konfiguriert, den Paketlogger angeschaltet und die Verbindung aufbauen lassen.

Und siehe da: Es funktionierte, als wäre nie was gewesen.

Nachdem ich also nichts an meiner Konfiguration geändert hatte , die zuvor selbst nach unzähligen Versuchen nicht funktionierte, liegt natürlich die Vermutung nahe, dass die R-KOM etwas an meinem Anschluss geändert hat. Z.B. die Prüfung auf Agent-Kennung deaktiviert. Dies wurde aber verneint.

Egal, jetzt funktioniert es und ich kann euch nur raten hartnäckig zu bleiben, wenn ihr ein ähnliches Problem habt. Am Ende zählt nämlich das eingangs erwähnte Gesetz zur Routerfreieheit – eine berechtigte Beschwerde bei der Bundesnetzagentur findet sicher kein Provider lustig.

Imrazor.de unterstützen (* = Amazon Partnerlinks)
Dir gefallen meine Beiträge und Du möchtest mich unterstützen?

Ich schalte keine Werbebanner, weil ich diese selbst nicht mag. Wenn Du aber über die mit * gekennzeichneten Produktlinks/Affiliate-Links bei Amazon bestellst, erhalte ich eine kleine Provision. Du selbst hast dadurch keinen Nachteil.

Die Produktlinks sind für Dich nicht interessant, aber Du möchtest mich trotzdem unterstützen? Dann kannst du ganz einfach deinen nächsten Amazon-Einkauf über diesen Amazon-Link tätigen.

Vielen Dank! 🙂

Gründer und Betreiber von Imrazor.de

Von Beruf Elektroingenieur, in der Freizeit reisebegeisterter Hobbyfotograf mit großer Linux-Affinität.

Auch interessant:

Netzwerk im Neubau – Tipps zur Planung und U... Das Netzwerk im Neubau - gerne wird dieses Thema bei der Planung und der (Elektro-) Installation übersehen oder vernachlässigt. Dabei ist es heute ein...
Softproof mit ICC-Profilen in Darktable Softproof mit ICC-Profilen in Darktable Wer seine (digitalen) Fotos nicht nur für das Internet bzw. social Media (Facebook, Instagram, etc.) schießt ...
Scribus: Bild/Foto als Hintergrund von Buchstaben Meine Fotobücher bzw. Fotoprojekte erstelle ich recht gerne mit dem Opensource-Programm Scribus. Für ein aktuelles Fotobuch des letzten Urlaubs, habe ...
Nexus 5 – Mikrofon-Reparatur Seit etwa einem Monat habe ich mit meinem LG Nexus 5 das Problem, dass das Mikrofon defekt ist. Nachdem meine Garantie noch nicht abgelaufen war, eröf...
Monitorkalibrierung mit Datacolor Spyder 5 unter L... Monitorkalibrierung mit Datacolor Spyder 5 - Welcher (Hobby-) Fotograf kennt das Problem nicht: Ein zuvor in RAW geschossenes Fotos sieht nach der Bea...
Raspberry Pi – Raumtemperatur überwachen Nachdem der Kleinstcomputer Raspberry Pi mittlerweile doch schon einige Zeit auf dem Markt ist, habe ich mich jetzt endlich mal dazu entschieden mir d...