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 Edge 4L) eingerichtet wird. Diese Anleitung wurde bereits vor einiger Zeit mit OPNsense 19.7 erstellt, jedoch wurde sie kürzlich mit dem im Juli 2023 veröffentlichten OPNsense 23.7 geprüft und aktualisiert.

Anforderungen

In diesem Beispiel kommen zwei Edge 4L (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.0.251/24 (Firewall 1); 192.168.0.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. Deaktivieren des DHCP-Servers auf beiden Firewalls (unter Services ‣ DHCPv4 ‣ [LAN]).
  4. 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.
  5. Konfiguration der virtuellen IP Adressen für WAN und LAN unter Firewall ‣ 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.0.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
      • Advertising Frequency: Base 1 / Skew 0
      • Description: Virtual WAN IP
    • Auf Firewall 1 (Master) durch Klicken auf + Add eine neue virtuelle LAN IP mit folgenden Parametern erstellen:
      • 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]
      • Advertising Frequency: Base 1 / Skew 0
      • Description: Virtual LAN IP
  6. Konfiguration der ausgehenden Network Address Translation (NAT).
    Ausgehendes NAT konfigurieren. Unter Firewall ‣ NAT ‣ Outbound die Option Manual outbound NAT rule generation wählen und durch Klicken auf + Add eine neue Regel erstellen:
    • Interface: WAN
    • Source address: LAN net
    • Translation / target: 192.168.0.253 (Virtual WAN IP)
  7. Optional DHCP Server konfigurieren. Auf beiden Firewalls unter Services ‣ DHCPv4 ‣ [LAN] folgende Parameter wählen:
    • DNS servers: 192.168.1.1 (entspricht der Virtual LAN IP)
    • Gateway: 192.168.1.1 (entspricht der Virtual LAN IP)
    • Failover peer IP: 192.168.1.252 (IP der anderen Firewall), auf Firewall 2 hier 192.168.1.251 (IP der ersten Firewall) anführen
  8. 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 States: ✔
    • Synchronize Interface: PFSYNC
    • Synchronize Peer IP: 10.0.0.2 (hier die IP Adresse des PFSYNC Interfaces von Firewall 2 anführen)
    • Synchronize Config to IP: 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:
      • Dashboard: ✔
      • Firewall Rules: ✔
      • Aliases: ✔
      • NAT: ✔
      • DHCPD: ✔
      • Virtual IPs: ✔
  9. Status Information der HA-Synchronisation (aufgerufen auf Firewall 1).
    pfSync auf Firewall 2 konfigurieren. Unter System ‣ High Availability ‣ Settings folgende Einstellungen wählen:
    • Synchronize States: ✔
    • 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]
    • Synchronize Interface: PFSYNC
    • 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.
  10. Auf Firewall 1 im Dashboard das CARP-Widget durch Klicken auf + Widget, Auswahl von CARP und anschließendem Klicken auf Save Settings hinzufügen.
  11. 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 dc:58:bc:e0:06:d0 REACHABLE
192.168.1.1 dev enp0s25 lladdr 00:00:5e:00:01:01 REACHABLE
192.168.1.252 dev enp0s25 lladdr c4:00:ad:b8:69:a1 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 2023-11-14T15:40:17+00:00 OPNsense.localdomain kernel - - [meta sequenceId="1"] <6>carp: 3@igb1: MASTER -> INIT (hardware interface down)
<13>1 2023-11-14T15:40:17+00:00 OPNsense.localdomain kernel - - [meta sequenceId="2"] <6>carp: demoted by 240 to 240 (interface down)
<13>1 2023-11-14T15:40:17+00:00 OPNsense.localdomain kernel - - [meta sequenceId="3"] <6>igb1: link state changed to DOWN
<13>1 2023-11-14T15:40:17+00:00 OPNsense.localdomain kernel - - [meta sequenceId="4"] <6>carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 37378 - [meta sequenceId="5"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual WAN IP (192.168.0.253) (3@igb1)" has resumed the state "INIT" for vhid 3
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 37378 - [meta sequenceId="6"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual WAN IP (192.168.0.253).
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 37860 - [meta sequenceId="7"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 37860 - [meta sequenceId="8"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2023-11-14T15:40:19+00:00 OPNsense.localdomain opnsense 40421 - [meta sequenceId="9"] /usr/local/etc/rc.linkup: DEVD: Ethernet detached event for wan(igb1)
<27>1 2023-11-14T15:40:19+00:00 OPNsense.localdomain dhclient 92256 - [meta sequenceId="10"] connection closed
<26>1 2023-11-14T15:40:19+00:00 OPNsense.localdomain dhclient 92256 - [meta sequenceId="11"] exiting.
<13>1 2023-11-14T15:40:19+00:00 OPNsense.localdomain opnsense 41507 - [meta sequenceId="12"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual LAN IP (192.168.1.1) (1@igb0)" has resumed the state "BACKUP" for vhid 1
<13>1 2023-11-14T15:40:19+00:00 OPNsense.localdomain opnsense 41507 - [meta sequenceId="13"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual LAN IP (192.168.1.1).
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 41654 - [meta sequenceId="14"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 41654 - [meta sequenceId="15"] /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: 240
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 2023-11-14T15:40:18+00:00 OPNsense.localdomain kernel - - [meta sequenceId="1"] <6>carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 23155 - [meta sequenceId="2"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual LAN IP (192.168.1.1) (1@igb0)" has resumed the state "MASTER" for vhid 1
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 23155 - [meta sequenceId="3"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual LAN IP (192.168.1.1).
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 25035 - [meta sequenceId="4"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2023-11-14T15:40:18+00:00 OPNsense.localdomain opnsense 25035 - [meta sequenceId="5"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain kernel - - [meta sequenceId="6"] <6>carp: 3@igb1: BACKUP -> MASTER (master timed out)
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 54707 - [meta sequenceId="7"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual WAN IP (192.168.0.253) (3@igb1)" has resumed the state "MASTER" for vhid 3
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 54707 - [meta sequenceId="8"] /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual WAN IP (192.168.0.253).
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 58044 - [meta sequenceId="9"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2023-11-14T15:40:20+00:00 OPNsense.localdomain opnsense 58044 - [meta sequenceId="10"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))

root@fw2:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 240
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

Im Web Interface der Firewall 1 sind folgende Informationen ersichtlich (Firewall 2 ist für LAN und WAN nun MASTER):

  • 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 Firewall ‣ Virtual IPs ‣ Status sind weitere Hinweise zum Umschalten auf den Backup-Betrieb zu finden.

    Unter Firewall ‣ 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


Foto Werner Fischer.jpg

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.


Foto Thomas Niedermeier.jpg

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.

Icon-Twitter.png 

Das könnte Sie auch interessieren

OPNsense Interface hinzufügen
Zum Artikel
OPNsense Sprache einstellen
Zum Artikel
SSL routines tls process server certificate certificate verify failed - Authentication error
Zum Artikel