Inhaltsverzeichnis
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) 500MBit/s-Leitung möglich. (Seit Dezember 2020 habe ich einen Anschluss mit 500MBit/s down und 100MBit/s up und keinerlei Probleme mit meiner OPNsense Konfiguration)
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
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 1GbE 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.
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. Heute (2019) würde ich eher zu einer SanDisk SSD PLUS 120GB raten. Mehr Leistung/Speicher zum fast selben Preis.
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.
13.07.2020 – Achtung:
Nach mehr als zwei Jahren Dauerbetrieb hatte ich letztens Probleme mit der Verbindung zwischen LAN und WAN. Schlagartig konnte keine Kommunikation aus dem LAN über WAN ins Internet mehr stattfinden. Umgekehrt allerdings schon: Von WAN zu LAN blieb die Kommunikation bestehen. Erst durch ein Deaktivieren und Aktivieren der WAN-Schnittstelle konnte die Kommunikation wiederhergestellt werden.
Beim Durchsuchen der Logfiles findet man nichts zielführendes, keine Fehler oder Warnungen. Mir ist nur aufgefallen, dass kurz vor dem Fehler der Promiscuous Mode der Netzwerkschnittstelle deaktiviert und aktiviert wurde. Das kommt im Normalbetrieb zwar auch manchmal vor, aber beim Auftreten des Fehlers gehäuft.
Bei mir ist WAN genau die Schnittstelle, die auch das oben erwähnte Problem mit dem Überlasten hat und eigentlich am HW Revision 1.02 erledigt ist. Ich war schon soweit das Board zu tauschen, bis das Wetter abkühlte und die Ausfälle verschwunden sind. Fazit: Die Netzwerkschnittstelle ist überhitzt. Nach einer besseren Belüftung des Serverschranks ist das Problem nicht mehr aufgetreten.
Achja: Leider gab es auch zu Hitzeproblemen keinen Log-Eintrag. CPU und sonstige überwachte Komponenten waren alle im Toleranzbereich.
Zusammenfassung:
- Board: Supermicro X11SBA-LN4F
- Gehäuse: SuperChassis SC505-203B
- RAM: Kingston KVR16LS11/4
- SSD: SanDisk SSD PLUS 120GB
- Barebone-Alternative: SuperServer E200-9B
OPNsense Systemanforderungen
Übrigens ist die Leistung der oben angeführten Hardware selbst für größere Netzwerke ausreichend. Wer große Netzwerke und viele Aufgaben bearbeiten will, der sollte lediglich die SSD gegen eine größere tauschen, z.B. gegen die oben erwähnte SanDisk SSD PLUS 120GB. OPNsense empfiehlt selbst folgende Konfigurationen (Stand 2019 – Hardware Requirements OPNsense):
Minimum
- Prozessor: 500MHz single core CPU
- RAM: 512MB
- SD/CF Speicher: 4GB
Bei folgenden Leistungsdaten:
- Netzwerkdurchsatz: 11-150 Mbps
- Benutzer/Netzwerke: 10-30
Sinnvoll
- Prozessor: 1GHz dual core CPU
- RAM: 1GB
- SSD Speicher: 40GB (1GB für die Installation)
Bei folgenden Leistungsdaten:
- Netzwerkdurchsatz: 151-300 Mbps
- Benutzer/Netzwerke: 30-50
Empfohlen
- 1.5GHz multi core CPU
- RAM: 4GB
- SSD Speicher: 120GB
Bei folgenden Leistungsdaten:
- Netzwerkdurchsatz: 350-750+ Mbps
- Benutzer/Netzwerke: 50-150
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.
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.
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.
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.
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.
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ü.
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:
- Links oben auf „Add a new system“ klicken.
- Die erforderlichen Angaben, v.a. die IP-Adresse der IPMI Schnittstelle, eingeben.
- Das neue System wir links eingetragen, nun doppelt anklicken und man erhält recht die Login-Maske.
- Nach dem Login wählt man in den Registern unten ganz rechts den Eintrag KVM Console und klickt dann auf Launch KVM Console.
- 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.
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.
Update Mai 2019
Von Wolfgang habe ich den Hinweis bekommen, dass mit der Version 19.1.4 der Installer nicht sauber startet und nach dem laden einiger Kernelmodule abstürzt. Resultat ist ein blauer Screen mit der Ausgabe Boot.
Dieses Problem lässt sich lösen, indem man beim Starten das Boot-Menü durch Drücken der Leertaste unterbricht. Danach geht man mit Option 3 in die Boot-Console und gibt dort folgendes Kommando ein:
set kern.vty=sc boot -v
Danach startet OPNsense normal hoch.
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.
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.
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.
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.
- Alias: Name=Gigaset, Wert=IP-Adresse des Telefons im LAN
- Alias: Name=SIP, Wert=5060 (SIP Port)
- Alias: Name=RTP, Wert=7078:7097 (RTP Ports, die in der FB eingestellt waren)
- Alias: Name=Registrar, Wert=IP-Adresse des SIP-Servers
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.
- Firewall -> Regeln -> VLAN40 – Der Datenverkehr zum Gigaset SIP- und RTP-Port.
- Firewall -> NAT -> Ausgehend
- Firewall -> NAT -> Portweiterleitung – Zum Schluss leiten wir noch die SIP und RTP-Ports eingehend an das Gigaset-Telefon weiter
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“
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.
Der Artikel enthält Affiliate-Links zu Amazon die mit einem * gekennzeichnet sind. Kaufst du ein von mir verlinktes Produkt bei Amazon, bekomme ich eine kleine Provision und du unterstützt mich und meine Arbeit. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Dir entstehen keine Nachteile oder Mehrkosten.
48 Kommentare
Hört sich gut an, sind sie mit der Hardware noch zufrieden ?
Kann man das ganze auch ohne Linux also von einem OSX Gerät
Installieren und konfigurieren ?
Hardware ist immer noch top. Läuft stabil seit Monaten.
OPNsense ist ein komplett eigenes Betriebssystem, basierend auf FreeBSD (Unix Derivat, kein Linux). Gesteuert wird es sowieso fast ausschließlich über die Weboberfläche.
Die Installation von OPNsense erfolgt in meiner Anleitung direkt über die IPMI Schnittstelle bzw. übers Netzwerk. Das kann man natürlich auch unter Windows oder OSX machen. Ist ja nur ein Java-Programm, die IPMI Konsole. Und Java ist ja relativ plattformunabhängig ;-)
Oder man klemmt einen Monitor+Tastatur+Maus direkt an die Appliance und startet die Installation von einem Boot-USB.
Wieso ist der oben verlinkte Speicher ein 1,5 V Speicher ,
Sind beim Gehäuse alle Kabel dabei ?
Wenn ich den Link aufrufen, komme ich zum richtigen RAM mit 1,35V.
Kabel sind beim Gehäuse dabei – außer natürlich das SATA Kabel für die SSD https://amzn.to/2NrEnoY
Gibt es einen Grund, dass sie nur 4 gb Speicher haben, man könnte ja 2x 4 gb machen, meine Erfahrung ist, je mehr Speicher um so besser , bin auch am überlegen eine größere hdd einzubauen
OPNsense braucht einfach nicht mehr Ressourcen. V.a. SSD wäre rausgeworfenes Geld. Man darf das nicht mit einem herkömmlichen Server oder PC vergleichen.
Haben Sie schon den Stromverbrauch gemessen und können Angaben zum (Durchschnitts)Verbrauch des kompletten Systems machen?
Hallo Christian, den Stromverbrauch habe ich noch nicht gemessen. Gehe aber anhand der verbauten Komponenten von ca. 10W aus – wenn überhaupt.
Grüße
Andreas
Hallo, sehr schöner Artikel!
Eine Frage: kann man sich einen Router hinter dem OPNsense-Rechner einsparen, indem man einfach mehrere LAN-Karten verbaut?
Hallo Jan,
OPNsense ist auch ein Router, du kannst dir also ein zusätzliches Gerät sparen. Anstatt mehrere Netzwerkkarten zu verbauen nimmt man einfach einen Switch ;-)
Grüße
Andreas
Moin Andreas,
kannst du das nachholen :-)
Grüße
Hallo Tom, was soll ich nachholen? LG
Wenn du das alles noch mit PatchSee und Farbclips verkabelt hättest dann wäre es genau so schön wie das was wir tun ;D
Ich weiß ja, wo meine paar Kabel hinlaufen ;-)
Hi,
toller Artikel.
Was mich brennend interessiert wie der Datendurchsatz ist. Du hast ja FTTH. Schafft das die CPU? Wie ist die Auslastung bei Webfilter, Proxy, hast du noch die volle Bandbreite?
Ich hab nämlich noch die APU am laufen, nur die schafft keine 200mbit mit Filter/Proxy.
Hallo Jürgen,
ich habe zwar FTTH, aber „nur“ 100MBit/s (mehr brauche ich momentan nicht).
Ich habe auch keinen Proxy und Filter laufen. Aber mit dem was ich laufen habe langweilt sich die Hardware. Ich erreiche immer den vollen Durchsatz.
Grüße
Andreas
Hallo Andreas,
guter Artikel, ich habe es nachgebaut mit der Hardware. Leider gibt es bei mir Fehler bei der KVM Konsole: Java Messagebox „Authentication failed“.
Allerdings funktioniert in Chrome auch gut RemoteControll/iKVMHTML5.
Nur das Einbinden einer iso über einen share klappt nicht, so dass ich OPNSense vom USB Stick installierte.
Wichtig:
’set kern.vty=sc‘ muss gespeichert werden, da es sonst nach jedem Reboot eingegeben werden muss, z.B. mit:
echo ‚kern.vty=“sc“‚ > /boot/loader.conf.local
und damit es mit einer deutschen Tastatur klappt in der Console kann man gleich noch anlegen:
echo ‚keymap=“german.cp850″‚ > /etc/rc.conf.local
Viele Grüße,
Peter
die einfachen Hochkomma wurden ersetzt. Korrekter Syntax siehe:
https://forum.opnsense.org/index.php?PHPSESSID=g3l3pph09jks73lqj6nqecv48h&topic=11869.msg67881#msg67881
Hallo Andreas,
vielen Dank für diesen tollen Artikel.
Ich stehe derzeit vor der gleichen Entscheidung und da seit Deinem Projekt bereits etwas Zeit vergangen ist, habe ich mich erneut umgeschaut.
Was hältst Du denn von einem SuperMicro A2SDi-4C-HLN4F (Intel Atom C3558, 4 Cores + 4x GBit-LAN, Intel C3000 SoC) als Weiterentwicklung/Performanceverbesserung Deines Servers? Als Gehäuse plane ich das gleiche Modell wie Du.
Meine aktuellen Anforderungen sind:
– aktueller Internetanschluss 100/40 MBit/s, aber mit Auslegung auf zukünftiges GBit FTTH
– ich möchte mir die Möglichkeit für Snort/Suricata offenhalten
– es soll ein DNS-Filter laufen
– es soll HAproxy laufen
– max. ca. 6-8 gleichzeitige VPN-Verbindungen mit IPsec/OpenVPN
– Das System sollte genug Leistung haben, dass es für mindestens die nächsten 10 Jahre im Einsatz bleiben kann.
Weißt Du, ob es Systeme mit Celeron / i5 / Xeon gibt, welche von der Leistungsaufnahme im gleichen Bereich liegen (bei meinem genannten System 16W TDP) aber dennoch leistungsfähiger sind?
Vielen Dank,
Thomas
Hallo Thomas,
ich glaube ehrlich gesagt nicht, dass der Atom wirklich eine bessere OPNsense (!) Performance liefern wird, als der Pentium N. Dann auch noch mit deutlich höherem Stromverbrauch.
Mit deinen Anforderungen sollte auch meine Konfig klar kommen, die ist ja auch über den „empfohlenen Leistungsanforderungen“ von OPNsense. Bei mir langweilt sich die Hardware meistens – obwohl ich schon einiges laufen habe und auch ordentlich Traffic drüber läuft.
Einen deutlichen Haken sehe ich an deinen Anforderungen an anderer Stelle: Soll mindestens die nächsten 10 Jahre halten. Wie soll das denn funktionieren? Keiner weiß, was es in 10 Jahren an Anforderungen geben wird. Geschweige denn an Ersatzteilen. Glaube nicht, dass das System bei Dauerbetrieb 10 Jahre durchhalten wird und gleichzeitig kompatibel mit der Software bleibt.
Würde ich heute wieder eine solche Firewall Appliance bauen müssen, dann würde ich die gleiche Hardware wählen: Leistungsfähig und extrem sparsam. Nur eine größere SSD würde ich nehmen, wie im Artikel beschrieben.
Würde ich mehr Power benötigen (Firmeneinsatz – und selbst hier würde meine Konfig in den meisten Fällen reichen) würde ich wohl zu einem Epyc Board greifen, weil ich AMD einfach lieber mag ;-) Allerdings sind die teuer und haben mindestens 30W TDP. Dafür gibt’s die auch mit 8 Kernen.
Alles was nicht SoC ist, also eine CPU + Mainboard mit Sockel (Xeon, Celeron, i5), wird standardmäßig mehr TDP haben als 16W – und nicht zwingend leistungsfähiger sein.
Und nochmal: Was/Wer sagt dir, dass der Pentium N3700 nicht leistungsfähig ist? Das ist eine mobile CPU, die tendenziell stark optimiert ist, um geringe Leistungsaufnahmen zu erreichen bei gleicher Leistungsfähigkeit zu anderen CPUs.
Ich denke, dass OPNsense bei sehr hohen Ansprüchen mehr von richtigen Server-CPUs und von mehr Kernen (z.B. 8 Stk.) profitiert. Und dann sind wir eben deutlich jenseits der 16W TDP.
Und mit hohen Ansprüchen meine ich nicht ein paar zusätzliche Dienste, sondern das Handling von hohen Bandbreiten bei vielen Usern (jenseits 1GBit/s und jenseits 100 gleichzeitiger User).
Das ist aber nur meine Meinung, belegen kann ich es nicht, da ich keine Umgebungen mit solchen Anforderungen in meinem Umfeld kenne und weiß, was meine Konfig leistet.
Schöne Grüße
Andreas
Ich kann dir so viel verraten: Ab Mitte Dezember bist du nicht mehr der einzige, der bei TPP eine OPNsense direkt am ONT betreibt. Ich hatte das tatsächlich unabhängig von deinem Artikel vor, bin aber beim vorab Informieren über die mögliche VOIP-Konfiguration auf deinen Artikel über das OPNsense-Forum gestoßen. Vielen Dank für deine Pionierarbeit, ich hoffe, ich kann das bei mir dann auch so ohne weiteres umsetzen :)
Servus Michael!
Sehr gut!
Ich kann dir nur sagen, dass die Konfiguration seit mehr als zwei Jahren zuverlässig läuft und ich an der Konfiguration auch nichts geändert habe.
Mit welcher Anschlussgeschwindigkeit wirst du die OPNsense nutzen?
Grüße
Andreas
Servus!
Ich hab bei einer 500/200 Mbit/s Leitung zugeschlagen (also die 500 Mbit-Leitung mit doppeltem Upload) und virtualisiere das ganze auch auf einem Server im Mini-ITX-Gehäuse über XCP-ng. Da steckt also auch etwas andere Hardware drin (z. B. ein i3-9100F als Vierkern-CPU). Bin mal gespannt, wie das darüber läuft. Aber laufen wird es so sicherlich auch, bin nicht der erste, der OPNsense virtualisiert.
Grüße
Michael
Hallo Michael,
ah OK, danke für die Info. Fette Leitung :-)
Virtualisieren ist kein Problem, hatte es anfangs mal mit KVM getestet.
Allerdings wollte ich die Firewall am Ende doch lieber auf dedizierter Hardware.
Und weil ich den Virtualisierungsserver hin und wieder ausschalten/neustarten muss und dann ist die Internetleitung tot.
Deshalb dieses Projekt hier mit der Appliance.
Viel Spass beim Umsetzen!
Grüße
Andreas
Hallo Andreas,
vielen Dank für diesen wunderbaren Blog-Eintrag über den ich soeben gestoßen bin.
Ich nutze bisher ein APU-4d4 für OpnSense und einen T2600G-28TS Switch. Beider FW und Switch sind verbunden via 2xGbit Ports im LACP Mode. Da ich großen Wert auf eine sichere Trennung meiner einzelnen Netzbereiche lege, habe ich ca. 15 VLANs im Einsatz die alle auf der OpnSense angelegt sind und über den Switch (Access Ports) ausgeliefert werden. Alle Vlans laufen per Trunk über die 2xGbit Verbindung zwischen Switch und FW.
Leider bin ich nun vermutlich an die grenzen des APU Boards gestoßen. Beim Transfer größerer Daten von VLAN A (Client) nach VLAN B (NAS) erreiche ich leider maximal ~40MB/s. Auch ein iperf ergibt im besten Fall nur etwa 500Mbit/s :(
Scheinbar liegt dies am inter-vlan routing was ja an der Firewall stattfindet und extrem Performance schluckt. Kannst du eine Aussage treffen, ob dies mit dem X11SBA-LN4F performanter läuft, oder ob ich hierzu besser gleich auf eine größere CPU wie bspw. eine i5-6200U (wie im IPU662 von NRG Systems) ausweichen sollte/muss um zumindest 100MB/s also Gbit/s zwischen den VLANs zu schaffen?
Hallo Stephan,
ich denke ehrlich gesagt nicht, dass die Performance des N3700 soviel höher ist, als des AMD des APU 4d4.
Nachdem ich solche VLAN-Szenarios nicht habe, kann ich keine genau Aussage treffen. Allerdings liefert cpubenchmark.net ein gutes Bild:
AMD GX-412HD -> 966 Punkte
Intel N3700 -> 1302 Punkte
Ich würde es wohl mit einem Epyc embedded versuchen:
Epyc 3201 -> 12677 Punkte
Supermicro M11SDV-8CT-LN4F
Grüße
Andreas
Sehr schöne Anleitung mit einigen Tipps & Tricks.
Die ist auf jeden Fall mal als Lesezeichen im Browser hinterlegt.
Bin gerade auch dabei mir eine Firewall zusammen zu stellen, aber bin mir hier noch sehr unsicher, was meinen Vorstellungen gerecht wird.
Hab aktuell eine 400/160Mbits FTTH-Leitung, die ich dann ganz gerne direkt an die FW anbinden will.
Solche netten Dinge wie IPS würde ich ganz gerne aktiv haben, um zu sehen wer da rein will und diese auch effektiv abwehren zu können.
In einer VM nutzt ein Bastelsetup schon 70% der 8 zugewiesenen vCPUs.
Ich würde ganz gerne ein Stück Hardware haben, was nicht viel Strom verbraucht, aber dennoch für LAN und WAN ein 10Gbit/s Interface hat, um für die Zukunft etwas gerüstet zu sein.
Im Heimnetz werkelt auch immerhin schon ein 10GBit/s-Switch.
Wenn alles gut läuft, steht in naher Zukunft ein Upgrade auf 1Gbit/s an.
Dinge wie VPN und ein Gäste-Netz sollten am Ende auch konfiguriert werden.
Optional und nett wäre auch ClamAV zu nutzen, nur wenn das zu viel zieht, bleibts aus.
Kennst du – oder jemand der das hier liest – vielleicht passende Hardware?
Hallo Hoerli,
im Endeffekt kannst du dir die HW zusammenbauen, wie du möchtest (FreeBSD-Treiber vorausgesetzt), um deinen Anforderungen gerecht zu werden.
Wieso man allerdings am Übergangspunkt zum Internet im privaten Umfeld eine 10GbE-Schnittstelle braucht, sei jetzt mal dahingestellt. Kann mir jedenfalls keinen Anwendungsfall vorstellen. Im Netzwerk ok, aber selbst da gibt es heute noch nicht viele Anwendungen, die das ausnutzen (Videoschnitt über Netzwerk z.B.). Ich habe hier eine FTTH-Leitung mit 500Mbit/s down, selbst das wird nur in den seltensten Fällen genutzt, weil die Gegenstelle oft gar nicht so schnell ist.
Wie auch immer: vCPUs kannst du nie 1:1 mit realer HW vergleichen, da hier immer der Hypervisor dazwischen hängt und die Zugriffe koordiniert. Auslastungsanzeigen sind nicht repräsentativ, wie bei realer HW.
Thomas Krenn bietet verschiedenste OPNsense Konfigurationen an, damit du mal einen Überblick bekommst:
https://www.thomas-krenn.com/de/produkte/einsatzzweck/opnsense-firewalls.html
OpenVPN, Gästenetz etc. läuft bei mir auch, damit kommt die hier vorgestellte HW sehr gut zurecht.
Wie OPNsense selbst schreibt, haben viele Features kaum einen Einfluss auf die Auslastung, dafür gibt es ein paar, die sehr viel Last erzeugen können:
https://docs.opnsense.org/manual/hardware.html
Würde ich sowas umsetzen wollen, würde ich es wohl mit einem Epyc-Embedded (stromsparend, z.B. https://amzn.to/3pscVKR + Dual-10GbE PCIe Karte) versuchen oder gleich mit Server-Hardware (nicht stromsparend).
Auf Reddit gibt es noch eine Frage in diese Richtung: https://www.reddit.com/r/homelab/comments/geotki/hardware_requirements_for_opnsense_with_idsips/
Mit 1GBE Anschluss lastet IDS/IPS die CPU max. 25% aus und das ist nur ein i3-9100.
Ich hoffe, ich konnte dir wenigstens ein wenig Input geben.
Grüße
Andreas
Kleiner Nachtrag: Ich habe jetzt mal versucht IDS/IPS laufen zu lassen. Läuft insofern ganz gut, allerdings schaffe ich an meinem 500MBit/s Anschluss „nur“ noch ca. 400MBit/s.
Wobei hier v.a. die Alerts laufen und nur wenige Regeln aktiviert waren. Damit Suricata also auch an schnellen FTTH-Anschlüssel performant läuft, muss man auf leistungsfähigere Hardware setzen.
Könnte mir vorstellen, dass der genannte Epyc-Embedded die nötige Leistung mitbringt.
Hallo Andreas,
der Support von TPP hat mich auf Deine Seite hingewiesen :-). Ich versuche gerade auch eine VoIP-Anlage ohne die Fritzbox bei TPP einzubuchen (ähnliche Konfiguration, aber ein Mikrotik als Router/FW. Was hast Du denn als Registrar in der FW-Konfiguration angegeben (in den Screenshots ausgegraut), die 10er IP des SIP-Servers im VLAN? Habe ich mir auch überlegt, klappt halt nicht mehr, wenn sich die IP mal ändert.
Grüße, Joachim.
Hallo Joachim,
meine Konfiguration am FTTH-Anschluss der Telepark ist den Kollegen dort wohl in Erinnerung geblieben ;-)
Ich habe als Registrar die IP-Adresse der SIP-Server, also von ngn.telepark-passau.de eingegeben. Problem war nämlich bei mir (soweit ich mich erinnere), dass ich über VLAN40 den Namen nicht aufgelöst bekommen habe. Deshalb habe ich kurzerhand die dazugehörige IP eingetragen, die ich mit einer manuellen DNS-Abfrage erhalten hatte: 91.106.121.3
(Die 10er Adresse ist das Gateway des VLAN40)
Die IP hat sich seit 2018, also seit 3 Jahren nicht geändert und funktioniert tadellos.
Wie oben geschrieben, hatte ich damals mit dem SIP Server zu kämpfen. Das Problem hatte sich schlagartig selbst gelöst. Ich gehe immer noch davon aus, dass damals die Agent-ID auf „Fritzbox“ abgefragt wurde.
Die Telepark kauft den SIP Dienst anscheinend von der R-KOM in Regensburg zu und kann deshalb mutmaßlich nur bedingt Support leisten.
Sag Bescheid, ob es geklappt hat. Würde mich interessieren!
Grüße
Andreas
Hallo Andreas,
Danke für die schnelle Antwort. Ich Verstehe: Du routest per NAT mit der Zieladresse ngn.telepark-passau.de (91.106.121.3) in das 10er VLAN rein. Der Nachteil ist halt, dass sich die IP-Adresse des SIP-Servers nicht ändern darf. Ich probiere es bei Gelegenheit mal.
Lieber wäre es mir, zwei 10er IPs für das VLAN zu bekommen, eine auf im Router und eine an der Telefonanlage: Dann könnte man ngn.telepark-passau.de per DNS auflösen, im Router nur SIP traffic für das VLAN zulassen und käme immer noch aus dem LAN auf die Web-Oberfläche der Telefonanlage (per NAT auf die IP der Tel.-Anlage). M.e. die einzig wirklich saubere Lösung, aber leider ist die Telepark aber geizig und vergibt nur eine IP :-(.
Noch ein Nachtrag: Auf einem Mikrotik-Router lässt sich bei der Route für die IP des SIP-Servers ein DNS-Lookup relativ leicht per Script/Scheduler „nachrüsten“: S. Code unten – der entsprechende Routing-Eintrag hat einen Kommentar um ihn per Script leicht identifizieren zu können. Das Script läuft dann einmal pro Stunde oder so.
Vielleicht geht sowas ja auch bei Deinem Setup?
Grüße, Joachim.
# Modify route entry with comment „VoIP-Server“ if IP changes
:local voipip [:resolve „ngn.telepark-passau.de“];
:local voipcur [ /ip route get [/ip route find where comment=“VoIP-Server“] dst-address;];
:if ($voippip != $voipcur) do={
/ip route set [/ip route find where comment=“VoIP-Server“] dst-address=“$voipip“;
}
:log info („Set VoIP Server Routing“)
Danke für den Input mit dem Skript. Das müsste ich mir mal in einer ruhigen Minute ansehen.
OPNsense läuft auf FreeBSD-Basis, müsste also auf CLI Ebene über einen Cronjob machbar sein.
Funktioniert das VoIP der Telepark über den Mikrotik Router mit diesen Einstellungen jetzt?
Hallo Joachim,
richtig, ich route per NAT in das VLAN40.
Allerdings wirken die im Artikel beschriebenen Regeln ausschließlich auf den VoIP-Datenverkehr.
Das hat zur Folge, dass ich immer noch per LAN auf das Webmenü des Gigasets komme und auch das Gigaset für Non-VoIP-Datenverkehr ins Internet kommt (es zeigt bei Standby z.B. das aktuelle Wetter der nächsten Tage an).
Grüße
Hallo Andreas,
so langsam nimmt das Thema Firewall für mich, auch dank Deines Artikel, Gestalt an.
Bevor ich mir jedoch neue Hardware anschaffe möchte ich erstmal etwas Testen. Ich selbst habe eine FRITZ!Box 6590 Cable und müsste die FB wohl in einen nur Modemmodus versetzen bevor ich einen PC mit Firewall / DNS usw anbinden könnte. Wie bzw. wo hast Du die FRITZ!Box zum nur Modemmodus degradiert?
Kann Opensense das DHCP übernehmen oder kann es auch über ein PI-Hole laufen?
Mir fehlen da wohl ein paar grundlegende Dinge/ Wissen und erst wenn ich die verstanden habe macht es Sinn damit zu starten, hoffe Du kannst da noch ein wenig Licht ins Dunkle bringen.
Gruß
Hallo Franz,
ich selbst nutze keine Fritz!Box mehr, da mir kein Internetanbieter direkt eine IP-Adresse aus seinem Netz zuweist.
Für diesen Glasfaseranschluss wird keinerlei Modem benötigt. Meine OPNsense bekommt also auf WAN direkt eine IP-Adresse für das Internet und eine weitere in einem VLAN für die Telefonie.
Den Rest erledigt komplett die OPNsense.
Musst du eine FB dazwischen nutzen, dann muss diese in den Modemmodus oder in den sogenannten „Exposed Host“ gehen. Funktionen wie DHCP etc. muss du deaktivieren.
Das DHCP kann dann die OPNsense erledigen, aber auch ein PI-Hole, das kannst du konfigurieren, wie du lustig bist.
Du musst dir genau überlegen, welche Funktion welches Gerät erledigen soll und an welcher Stelle es im Netzwerk verbaut ist.
So kannst du dann verhindern, dass sich zwei Geräte in de Quere kommen und z.B. beide versuchen IP-Adressen zu verteilen.
Grüße
Andreas
Hallo Andreas,
danke für die rasche Antwort.
Einen Glasfaseranschluss habe ich bisher noch nicht, lediglich eine 250 MBit Leitung. DHCP kann gut der PI erledigen, dürfte ja nicht soviel Aktivität sein,)
Der Exposed Hosed ist dann der Rechner auf dem OpenSense läuft?
Beim Thema Telefonie bin ich leider noch vollkommen unbelesen, kann die Telefonie im ersten Schritt nicht einfach auf der FB verbleiben?
Hallo Franz,
Glasfaseranschlüsse haben nur die Eigenschaft, dass man kein Modem benötigt, deshalb kann man die FB getrost entsorgen.
Ansonsten kannst du natürlich die FB für die Einwahl und VoIP nutzen und den Rest per OPNsense regeln. PiHole macht ja mehr wie DHCP, ist ja eher primär für DNS Anfragen, um Werbung auszufiltern.
Am Ende ist es eben wichtig zuerst zu definieren welches Gerät welche Aufgabe übernehmen soll und dann auf dieser Basis das das Netzwerk aufzubauen.
Grüße
Andreas
Hallo Andreas
Ich finde dein Projekt super. Bin so begeistert das ich mir diese Firewall auch bauen möchte. Finde aber nur den download für amd64. Intel ist nichts zu finden. Wird nur noch amd64 unterstützt? Wenn ja, könntest Du mir ein vergleichbares MB empfehlen?
Danke und Grüße aus Osnabrück
Hallo Jörg,
amd64 ist historisch bedingt: AMD waren die ersten, die 64bit CPUs auf den Markt brachten. Seitdem sind bei Linux und FreeBSD die 64Bit-Versionen immer als amd64 bezeichnet. Die funktionieren aber auch mit Intel 64Bit CPUs. Hauptsache 64bit.
Das im Artikel vorgestellte Board ist auch mit einer Intel CPU.
Grüße
Andreas
Hallo Andreas, Super Projekt welches ich in meiner Firma auch umsetzten möchte und super Anleitung.
Ich habe das selbe Board + Gehäuse und + Ram wie du verwendest genommen.
Ich hab nur ein Problem , nachdem ich die ISO im IPMI Viewer eingebunden habe und das System neustarte , bootet er nicht von der ISO , auch nicht vom USB Stick mit den ich es Parallel getest habe und ich komme auch nicht mit den üblichen Tasten ins BIOS oder einem Boot Menü.
Leertaste beim Booten funktioniert auch nicht weder am Device Selber ( ich glaub da funktioniert die Tastatur erst garnicht) noch über die KVM Console im IPMI Viewer.
Er zeigt immer dieses Bild an, nach dem Einschalten https://ibb.co/q14zD8F
Ich jab auch schon porbiert im IPMI Viewer unter IPMI DEVICE -> „Next Boot Option “ auf andere Boot Optionen umzustellen, hilft leider auch nicht.
Hast du vll noch eine Idee, was ich probieren kann?
PS . ich benutze Windows 10 und IPMI Viewer natürlich als Admin ausgeführt.
Hallo Sebastian,
normalerweise hängt man das ISO einfach ein (virtual storage -> „plug in“).
Ist es eingehängt, dann sollte davon gebootet werden, wenn nicht, im BIOS die Bootreihenfolge so ändern, dass er das ISO findet.
Ins BIOS kommt man beim Booten mit „ENTF“, laut Anleitung kann es aber auf F1 oder F2 sein. Ich selbst hab es gerade nicht im Kopf, welche Taste es war, denke aber es sollte ENTF sein.
Eine andere Idee, wieso er nicht booten will, habe ich leider auch nicht. Es wäre also sehr wichtig, wenn du im ersten Schritt ins BIOS kommst.
Grüße
Andreas
Hallo Andreas,
ich bin heute auf dein Projekt gestoßen, danke für die tolle Anleitung.
Ich plane auf OPNsense umzustellen. Ist die Hardware noch aktuell, oder würdest du etwas verändern?
Danke schön
Gruß Dirk
Hallo Dirk,
bei mir läuft die Firewall unverändert und ohne Probleme. Ich habe auch keinerlei Performanceprobleme mit dem, was ich damit mache.
Habe gerade nachgesehen, gibt eigentlich momentan keine bessere Alternative hinsichtlich Ausstattung und Energieeffizienz.
Für den privaten Gebrauch, ohne massiven Einsatz von Suricata (IDS/IPS), reicht die Hardware locker. Will man mehr machen – viele Anwender, IDS/IPS, viele parallele VPN Verbindungen, dann sollte man sowieso zu einem richtigen Serversystem greifen.
Grüße
Andreas
Hallo Andreas,
top, danke für die schnelle Antwort.
Gruß Dirk
Hallo Andreas,
sehr cooles Projekt. Für unsere kleine Firma bekommen wir in 14 Tagen einen 500Mbit Glasfaseranschluss der Telekom. Ich habe die Hardware geliefert bekommen und werde mit einem SFP GPON Modul (bei Telekom erworben) direkt auf den GF-TA gehen. Ich bin mega gespannt, wie das laufen wird. Mit OPNSense hatte ich noch keine Berührungspunkte, hab mich aber schon durch zahlreiche kniffelige Konfigs gewühlt… wird schon schief gehen :-)
Holger
Hallo Holger,
viel Erfolg bei der Umsetzung, es lohnt sich! :-)
Andreas