OPNsense HA Cluster einrichten

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

Die kostenlose Open Source Firewall OPNsense kann als redundante Firewall mit automatischem Fail-over konfiguriert werden. Dieser Artikel zeigt, wie ein derartiger Firewall HA-Cluster mit zwei Firewall-Rechnern (in diesem Fall zwei OPNsense Desktop Appliance S) eingerichtet wird. Diese Anleitung wurde mit der im Juli 2026 erschienenen Version OPNsense 26.7 umfassend aktualisiert.

Anforderungen

In diesem Beispiel kommen zwei OPNsense Desktop Appliance S (je vier Netzwerk-Ports an der Rückseite) für den OPNsense HA-Cluster zum Einsatz.

Für eine redundante OPNsense Firewall sind erforderlich:

  • Zwei Firewall-Rechner mit jeweils mindestens drei Netzwerk-Ports.
  • WAN: Uplink mit mindestens drei verfügbaren IP Adressen (je eine fixe IP-Adresse für Firewall 1 und Firewall 2, sowie eine zusätzliche virtuelle IP-Adresse für den Firewall Master).
  • LAN: drei freie IP-Adressen im LAN (je eine fixe IP-Adresse für Firewall 1 und Firewall 2, sowie eine zusätzliche virtuelle IP-Adresse für den Firewall Master).

Falls die beiden OPNsense Cluster Nodes in virtuellen Maschinen betrieben werden, muss den virtuellen Maschinen das Verändern der MAC Adressen erlaubt werden. Dies ist für die Verwendung des Common Address Redundancy Protocol (CARP) erforderlich. Die entsprechenden Einstellungen sind:

  • VMware ESXi: Allow forged transmits und Allow MAC changes aktivieren. Ggf. muss auch der Promiscous Mode aktiviert werden.[1][2] Zusätzlich kann das os-vmware Plugin installiert werden.[3]
    VMware ESXi: Allow forged transmits und Allow MAC changes aktivieren. Ggf. muss auch der Promiscous Mode aktiviert werden.[1][2] Zusätzlich kann das os-vmware Plugin installiert werden.[3]
  • Hyper-V: Enable MAC address spoofing aktivieren.
    Hyper-V: Enable MAC address spoofing aktivieren.

Grundlagen

Bei einer redundanten OPNsense Firewall kommen die folgenden Technologien zum Einsatz:

  • Common Address Redundancy Protocol (CARP):[4] Protokoll zum Bereitstellen von hochverfügbaren IP Adressen
    • Verwendet wie VRRP das IP Protokoll 112.
    • Nützt Multicast-Pakete, um aktuelle Zustands-Informationen an weitere teilnehmende Rechner am Cluster-Verbund mitzuteilen.
  • pfsync:[5] Protokoll zur Replizierung der Zustandsinformationen der einzelnen Netzwerkverbindungen (State Table Synchronisation).
    • Hinweis: Damit die Zustandsinformationen auf beiden Firewalls korrekt angewendet werden können, müssen beide Firewalls die identischen Interface-Bezeichnungen für die konfigurierten Netze verwenden. Ist beispielsweise das interne Netz (LAN) auf Firewall 1 über das Interface igb0 verbunden, muss igb0 auch auf der Firewall 2 dem LAN zugeordnet sein. Wenn es sich um zwei unterschiedliche Firewalls mit unterschiedlichen Netzwerkkarten (und damit Interface-Namen) handelt, kann als Workaround LAGG konfiguriert werden.
    • Für pfSync ist empfohlen, ein dediziertes Interface auf beiden Firewalls zu verwenden. Dies erhöht die Sicherheit (State Injection) und die Performance.
  • XMLRPC sync: Synchronisation der Firewall-Konfiguration.

Konfiguration

Netzwerk-Aufbau für den OPNsense HA-Cluster.

Empfehlung: Konfigurieren Sie beim Einrichten einer neuen Firewall zuerst den Clusterverbund. Beginnen Sie nach dem Einrichten des HA-Clusters damit, weitere Firewall-Konfigurationen (Firewall-Regeln, Dienste, ...) zu konfigurieren. Dieses Vorgehen reduziert mögliche Fehlerquellen.

Zur Einrichtung einer redundanten OPNsense Firewall sind folgende Schritte auszuführen:[6]

  1. Installation von OPNsense auf beiden Firewall Rechnern.
  2. Konfiguration der statischen IP-Adressen auf Firewall 1 und Firewall 2. Falls ausschließlich IPv4 zum Einsatz kommt, empfehlen wir IPv6 auf beiden Firewalls zu deaktivieren. In diesem Beispiel verwenden wir die folgenden IP Adressen:
    • igb0 (LAN): 192.168.1.251/24 (Firewall 1); 192.168.1.252/24 (Firewall 2)
    • igb1 (WAN): 192.168.12.251/24 (Firewall 1); 192.168.12.252/24 (Firewall 2)
    • igb2 (pfSync): 10.0.0.1/24 (Firewall 1); 10.0.0.2/24 (Firewall 2). Details zur Konfiguration dieser zusätzlichen Netzwerkschnittstelle sind im Artikel OPNsense Interface hinzufügen dokumentiert.
  3. Virtual IPs (nur auf Firewall 1 konfigurieren)
    • LAN: 192.168.1.1/24, VHID Group 1
    • WAN: 192.168.12.253, VHID Group 3
  4. Deaktivieren des DHCP-Servers auf beiden Firewalls (Haken bei Enable unter Services ‣ Dnsmasq DNS & DHCP ‣ General entfernen, standardmäßig ist aktuell der Dnsmasq aktiv).
  5. Firewall-Regeln auf beiden Firewalls erstellen. Unter Firewall ‣ Rules sind folgende Regeln für die drei Interfaces erforderlich:
    • LAN: Erlauben von CARP Paketen (Auswahl Protocol: CARP)
    • WAN: Erlauben von CARP Paketen (Auswahl Protocol: CARP)
    • PFSYNC: da es sich um eine direkte Kabelverbindung handelt, Erlauben von jedem Netzwerkverkehr.
  6. Konfiguration der virtuellen IP Adressen für WAN und LAN unter Interfaces ‣ Virtual IPs ‣ Settings.
    Virtuelle IPs einrichten:
    • Auf Firewall 1 (Master) unter Interfaces ‣ Virtual IPs ‣ Settings durch Klicken auf + Add eine neue virtuelle WAN IP mit folgenden Parametern erstellen:
      • Mode: CARP
      • Interface: WAN
      • Address: 192.168.12.253/24
      • Virtual password: Verwenden Sie ein zufälliges Passwort mit 30 Zeichen. Dieses können Sie beispielsweise uf einem Linux oder FreeBSD Rechner mit folgendem Kommando auf der Kommandozeile erstellen:[7]
        cat /dev/random | hexdump -n 30| cut -d \  -f 2-| head -n 1 | tr -d " "
      • VHID Group: 3
      • Advbase: 1
      • Description: Virtual WAN IP
    • Auf Firewall 1 (Master) durch Klicken auf + Add eine neue virtuelle LAN IP mit folgenden Parametern erstellen (advanced mode einschalten):
      • Mode: CARP
      • Interface: LAN
      • Address: 192.168.1.1/24
      • Virtual password: Verwenden Sie ein zufälliges Passwort mit 30 Zeichen.
      • VHID Group: 1 (diese Nummer wird als letztes Oktett der MAC-Adresse für die virtuelle IP Adresse verwendet, in diesem Beispiel lautet die MAC Adresse dann 00:00:5e:00:01:03)[8]
      • Advbase: 1
      • Advskew: 0
      • Description: Virtual LAN IP
  7. Konfiguration von Source Network Address Translation (NAT).
    Source NAT konfigurieren. Unter Firewall ‣ NAT ‣ Source NAT die Option Manual source NAT rule generation wählen und durch Klicken auf + eine neue Regel erstellen:
    • Interface: WAN
    • Source address: LAN network
    • Translate Source IP: 192.168.12.253 (Virtual WAN IP)
  8. Konfiguration von Kea DHCP
    Optional DHCP Server konfigurieren. Auf beiden Firewalls unter Services ‣ Kea DHCP ‣ Kea DHCPv4 folgende Parameter wählen (Dnsmasq unterstützt kein HA, darum wird Kea verwendet):
    • Reiter Settings
      • Sektion High Availability ausklappen
      • Enabled Checkbox setzen
    • Kea DHCP Reiter Subnets
      Reiter Subnets
      • Das LAN Subnet anlegen
      • 192.168.1.0/24
      • Sektion DHCP option data ausklappen
        • Auto collect option data Haken entfernen
        • Routers (gateway): 192.168.1.1
        • DNS servers: 192.168.1.1
        • NTP servers: 192.168.1.1
    • Kea DHCP Reiter HA Peers
      Reiter HA Peers
      • Beide Firewalls als HA Peers eintragen
      • URL sind die IPs der pfSync Interfaces der beiden Nodes: 10.0.01 bzw. 10.0.0.2 mit Port 8111
  9. Konfiguration der HA-Synchronisation auf Firewall 1.
    pfSync und HA-Synchronisation (xmlrpc) auf Firewall 1 konfigurieren. Unter System ‣ High Availability ‣ Settings folgende Einstellungen wählen:
    • Synchronize all states via: pfSync
    • Sync compatibility: OPNsense 26.7 or above
    • Synchronize Peer IP: 10.0.0.2 (hier die IP Adresse des pfSync Interfaces von Firewall 2 anführen)
    • Synchronize Config: 10.0.0.2
    • Remote System Username: root
    • Remote System Password: (Passwort von Firewall 2 anführen)
    • Dienste, welche synchronisiert werden sollen, auswählen. In diesem Beispiel:
      • Aliases: ✔
      • Firewall (Categories, Groups, ...): ✔
      • Unbound DNS: ✔
      • Virtual IPs: ✔
      • NAT: ✔
  10. Status Information der HA-Synchronisation (aufgerufen auf Firewall 1).
    pfSync auf Firewall 2 konfigurieren. Unter System ‣ High Availability ‣ Settings folgende Einstellungen wählen (advanced mode aktivieren):
    • Synchronize all states via: pfSync
    • Disable preempt: diese Option deaktiviert belassen (damit bleibt preemt weiterhin aktiv). Dadurch ist sichergestellt, dass bei einem Ausfall einer einzelnen Netzwerkverbindung (z.B. WAN-Anbindung von Firewall 1) alle IP Adressen (WAN und LAN in diesem Beispiel) auf die zweite Firewall umgezogen werden.[9]
    • Sync compatibility: OPNsense 26.7 or above
    • Synchronize Peer IP: 10.0.0.1 (hier die IP Adresse des pfSync Interfaces von Firewall 1 anführen)
    • Hinweis: Auf Firewall 2 keine HA-Synchronisation (xmlrpc) konfigurieren. Die spätere Konfiguration (z.B. von Firewall-Regeln, etc.) wird ausschließlich auf Firewall 1 durchgeführt und damit auf Firewall 2 synchronisiert.
  11. Auf Firewall 1 im Dashboard das CARP-Widget durch Klicken auf + Widget, Auswahl von CARP und anschließendem Klicken auf Save Settings hinzufügen.
  12. Abschließend einen Reboot beider Systeme durchführen.

Hinweis: Wenn weitere Dienste (z.B. OpenVPN) konfiguriert werden, muss zuvor die Synchronisation der Konfiguration unter System ‣ High Availability ‣ Settings aktiviert werden. Bei der Konfiguration des Dienstes muss jeweils die Virtual WAN IP als Interface für den Dienst gewählt werden.

Ausfalls-Test

Ein im Test-LAN angeschlosser Linux-Client zeigt bei Abfrage des ARP-Caches via "ip n" die virtuelle MAC-Adresse 00:00:5e:00:01:03 für das Default Gateway 192.168.1.1: 

tniedermeier@tpt:~$ ip n
192.168.1.251 dev enp0s25 lladdr c4:00:ad:b8:58:f0 REACHABLE
192.168.1.252 dev enp0s25 lladdr c4:00:ad:b8:69:a1 STALE
192.168.1.1 dev enp0s25 lladdr 00:00:5e:00:01:01 STALE

Nun wird zum Testen auf Firewall 1 (bisheriger Master) das Netzwerkkabel am WAN Port (igb1) abgesteckt. Verbindungen vom Linux-Client ins Internet (z.B. eine SSH-Verbindung oder eine virtuelle Desktop-Verbindung) bleiben erhalten.

Die folgende Ausgabe zeigt die Log-Einträge in /var/log/system.log sowie die sysctl Werte von net.inet.carp auf Firewall 1. Das Interface igb1 wechselt in den Status "interface down", daraufhin wird der "Demotion Counter" auf 240 gesetzt: 

root@fw1:~ # opnsense-log
[...]
<13>1 2026-09-30T13:23:54+00:00 fw1.test.thomas-krenn.com kernel - - [meta sequenceId="1"] <6>[24405] carp: 3@igb1: MASTER -> INIT (hardware interface down)
<13>1 2026-09-30T13:23:54+00:00 fw1.test.thomas-krenn.com kernel - - [meta sequenceId="2"] <6>[24405] carp: demoted by 240 to 240 (interface down)
<13>1 2026-09-30T13:23:54+00:00 fw1.test.thomas-krenn.com kernel - - [meta sequenceId="3"] <6>[24405] igb1: link state changed to DOWN
<13>1 2026-09-30T13:23:54+00:00 fw1.test.thomas-krenn.com kernel - - [meta sequenceId="4"] <6>[24405] carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
<13>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com opnsense 62477 - [meta sequenceId="5"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com opnsense 62477 - [meta sequenceId="6"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
<13>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com opnsense 63735 - [meta sequenceId="7"] /usr/local/etc/rc.linkup: DEVD: Ethernet detached event for wan(igb1)
<27>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com dhclient 14807 - [meta sequenceId="8"] connection closed
<26>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com dhclient 14807 - [meta sequenceId="9"] exiting.
<13>1 2026-09-30T13:23:55+00:00 fw1.test.thomas-krenn.com opnsense 62477 - [meta sequenceId="10"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2026-09-30T13:23:56+00:00 fw1.test.thomas-krenn.com opnsense 68761 - [meta sequenceId="11"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2026-09-30T13:23:56+00:00 fw1.test.thomas-krenn.com opnsense 68761 - [meta sequenceId="12"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
<13>1 2026-09-30T13:23:56+00:00 fw1.test.thomas-krenn.com opnsense 68761 - [meta sequenceId="13"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))

root@fw1:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 0
net.inet.carp.demotion: 240
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.dscp: 56
net.inet.carp.allow: 1

Die folgende Ausgabe zeigt die Log-Einträge in /var/log/system.log sowie die sysctl Werte von net.inet.carp auf Firewall 2: 

root@fw2:~ # opnsense-log
[...]
<13>1 2026-09-30T13:23:54+00:00 fw2.test.thomas-krenn.com kernel - - [meta sequenceId="1"] <6>[24414] carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
<13>1 2026-09-30T13:23:55+00:00 fw2.test.thomas-krenn.com opnsense 11624 - [meta sequenceId="2"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2026-09-30T13:23:55+00:00 fw2.test.thomas-krenn.com opnsense 11624 - [meta sequenceId="3"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
<13>1 2026-09-30T13:23:55+00:00 fw2.test.thomas-krenn.com opnsense 11624 - [meta sequenceId="4"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2026-09-30T13:23:57+00:00 fw2.test.thomas-krenn.com kernel - - [meta sequenceId="5"] <6>[24417] carp: 3@igb1: BACKUP -> MASTER (master timed out)
<13>1 2026-09-30T13:23:57+00:00 fw2.test.thomas-krenn.com opnsense 17427 - [meta sequenceId="6"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2026-09-30T13:23:57+00:00 fw2.test.thomas-krenn.com opnsense 17427 - [meta sequenceId="7"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
<13>1 2026-09-30T13:23:58+00:00 fw2.test.thomas-krenn.com opnsense 17427 - [meta sequenceId="8"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2026-09-30T13:26:44+00:00 fw2.test.thomas-krenn.com configctl 82983 - [meta sequenceId="1"] event @ 1790774804.03 msg: Sep 30 13:26:44 fw2.test.thomas-krenn.com config[87642]: config-event: new_config /conf/backup/config-1790774804.0178.xml 
<13>1 2026-09-30T13:26:46+00:00 fw2.test.thomas-krenn.com opnsense 16298 - [meta sequenceId="2"] /usr/local/sbin/pluginctl: plugins_configure dns_reload (1)
<13>1 2026-09-30T13:26:46+00:00 fw2.test.thomas-krenn.com opnsense 16298 - [meta sequenceId="3"] /usr/local/sbin/pluginctl: plugins_configure dns_reload (execute task : system_resolver_configure(1))
<13>1 2026-09-30T13:26:47+00:00 fw2.test.thomas-krenn.com opnsense 29157 - [meta sequenceId="4"] /usr/local/sbin/pluginctl: plugins_configure dns (1)
<13>1 2026-09-30T13:26:47+00:00 fw2.test.thomas-krenn.com opnsense 29157 - [meta sequenceId="5"] /usr/local/sbin/pluginctl: plugins_configure dns (execute task : dnsmasq_configure_do(1))
<13>1 2026-09-30T13:26:47+00:00 fw2.test.thomas-krenn.com opnsense 29157 - [meta sequenceId="6"] /usr/local/sbin/pluginctl: plugins_configure dns (execute task : unbound_configure_do(1))
<13>1 2026-09-30T13:26:49+00:00 fw2.test.thomas-krenn.com opnsense 54525 - [meta sequenceId="7"] /usr/local/sbin/pluginctl: plugins_configure dhcp (1)
<13>1 2026-09-30T13:26:49+00:00 fw2.test.thomas-krenn.com opnsense 54525 - [meta sequenceId="8"] /usr/local/sbin/pluginctl: plugins_configure dhcp (execute task : radvd_configure_dhcp(1))

root@fw2:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 0
net.inet.carp.demotion: 0
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.dscp: 56
net.inet.carp.allow: 1

Weitere Informationen zeigt das CARP-Widget oder die Statusanzeige unter Interfaces ‣ Virtual IPs ‣ Status:

  • Das CARP-Widget zeigt im Dashboard von Firewall 1 den Backup-Zustand.
    Das CARP-Widget zeigt im Dashboard von Firewall 1 den Backup-Zustand.
  • Unter Interfaces ‣ Virtual IPs ‣ Status sind weitere Hinweise zum Umschalten auf den Backup-Betrieb zu finden.
    Unter Interfaces ‣ Virtual IPs ‣ Status sind weitere Hinweise zum Umschalten auf den Backup-Betrieb zu finden.

Firewall Update

Mit einem redundanten Aktiv/Passiv Firewall HA-Cluster kann die Downtime der Firewall bei einem Firewall-Update drastisch minimiert werden:

  1. Aktualisieren Sie die Backup-Firewall (Firewall 2) und warten Sie, bis diese wieder online ist.
  2. Wählen auf der primären Firewall unter Firewall ‣ Virtual IPs ‣ Status den Punkt Enter Persistent CARP Maintenance Mode.
  3. Sobald Firewall 2 zum MASTER wurde, überprüfen Sie ob alle Dienste wie DHCP, VPN, NAT nach dem Update weiterhin korrekt funktionieren. Für den unwahrscheinlichen Fall, dass das Firewall-Update zu Problemen bei bestimmten Diensten führte, können Sie wieder auf die ursprüngliche Firewall schalten bevor Sie dort das Update eingespielt haben.
  4. Wenn alle Dienste wie gewünscht nach dem Update funktionieren, aktualisieren Sie Firewall 1 und wählen Sie danach Leave Persistent CARP Maintenance Mode.
    • Hinweis für OPNsense 19.7.3: Falls während des Updates ein automatischer Neustart von Firewall 1 erfolgt ist, muss nach dem Klicken auf Leave Persistent CARP Maintenance Mode noch ein Reboot von Firewall 1 durchgeführt werden, damit die Werte von advskew auf Firewall 1 wieder auf 0 gesetzt sind.[10] Dieser Bug wurde mit OPNsense Version 19.7.4 behoben.[11][12]

FAQs und Fehleranalyse

  • Frage: Beim Ausfall einer einzelnen Netzwerkverbindung von Firewall 1 (z.B. der WAN Verbindung) wird nur die WAN IP auf Firewall 2 umgezogen, nicht jedoch die LAN IP. Wie kann ich dieses Problem beheben?
    1. Überprüfen Sie ob auf beiden Firewalls unter System ‣ High Availability ‣ Settings die Option Disable preempt deaktiviert ist.
    2. Überprüfen Sie die Werte für advbase und advskew auf der Kommandozeile auf beiden Firewall mittels ifconfig | grep carp
      • advbase: soll den Wert "1" auf allen CARP Interfaces auf Firewall 1 und Firewall 2 haben
      • advskew: soll den Wert "0" auf allen CARP Interfaces auf Firewall 1 und den Wert "100" auf allen CARP Interfaces auf Firewall 2 haben.

Einzelnachweise

  1. ↑ Troubleshooting High Availability Clusters in Virtual Environments (docs.netgate.com)
  2. ↑ Duplicate response for Internet Control Message Protocol (ICMP) request - CARP controller nodes running on a same ESXi host (2144849) (kb.vmware.com)
  3. ↑ Virtual & Cloud based Installation - VMware ESXi
  4. ↑ Common Address Redundancy Protocol (de.wikipedia.org)
  5. ↑ pfsync Manpage (www.freebsd.org)
  6. ↑ Configure CARP (docs.opnsense.org)
  7. ↑ CARP on FreeBSD 10 with Pf Firewall (calomel.org) We suggest a password of 30 characters which is the maximum length allowed. To assist in making random passwords for carp aliases we suggest the following line. It queries /dev/random and outputs a clean 30 character string which you can cut and paste in place for "pass".
  8. ↑ RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 - Virtual Router MAC Address (tools.ietf.org)
  9. ↑ OpenBSD PF - Firewall Redundancy (CARP and pfsync) (www.openbsd.org) net.inet.carp.preempt: Allow hosts within a redundancy group that have a better advbase and advskew to preempt the master. In addition, this option also enables failing over a group of interfaces together in the event that one interface goes down. If one physical CARP-enabled interface goes down, CARP will increase the demotion counter, carpdemote, by 1 on interface groups that the carp(4) interface is a member of, in effect causing all group members to fail-over together.
  10. ↑ Enter Persistent CARP Maintenance Mode - advskew 254 causes problems (forum.opnsense.org, 26.08.2019)
  11. ↑ CARP: leaving maintenance mode on unit1 after reboot doesn't change advskew #3671 (github.com/opnsense/core/issues)
  12. ↑ OPNsense 19.7.4 released (forum.opnsense.org) system: fix CARP maintenance mode bootup

Weitere Informationen

Autor: Werner Fischer

Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.

 

Autor: Thomas Niedermeier

Thomas Niedermeier arbeitet im Product Management Team von Thomas-Krenn. Er absolvierte an der Hochschule Deggendorf sein Studium zum Bachelor Wirtschaftsinformatik. Seit 2013 ist Thomas bei Thomas-Krenn beschäftigt und kümmert sich unter anderem um OPNsense Firewalls, das Thomas-Krenn-Wiki und Firmware Sicherheitsupdates.


Das könnte Sie auch interessieren

Netzwerkprobleme bei Aktivierung von IPS auf OPNsense
Zum Artikel
OPNsense Migration auf neue Hardware
Zum Artikel
Thomas-Krenn OPNsense Rack-Server Firewall Performance
Zum Artikel