Check Point R82 VRRP Hub-and-Spoke auf STACKIT

Terraform erstellt zwei STACKIT-Projekte und eine gemeinsame Network Area (SNA). Das Hub-Projekt enthält zwei Check Point Security Gateways für Active/Standby-HA und einen Windows-Jumpserver. Das Spoke-Projekt enthält eine Debian-Test-VM mit SSH-Schlüssel, eigener Public IP und einem über die Firewall gerouteten Netzwerk.

Terraform stellt die Cloud-Infrastruktur bereit. Gaia-Interfaces, VRRP, SIC, Security Policy und NAT werden anschließend eingerichtet. Die OS-Anleitung verwendet Gaia R82 und einen VRRP Cluster; die tatsächliche Version des lokalen QCOW2-Images muss vor der Installation geprüft werden.

Architektur

flowchart LR
  Admin[Administrations-PC] -->|RDP: freigegebene Quellen| JumpIP[Windows Public IP]
  Admin -->|SSH: freigegebene Quellen| SpokeIP[Debian Public IP]
  subgraph Hub[Hub-Projekt]
    JumpIP --> Jump[Windows / Management]
    Jump -->|HTTPS und SSH| CP1[Check Point 1 / AZ 1]
    Jump -->|HTTPS und SSH| CP2[Check Point 2 / AZ 2]
    CP1 <-->|dediziertes Sync-Netz| CP2
    VIP[LAN-VIP] --> Active[Aktives Cluster-Mitglied]
    Active -->|Hide NAT| WAN[WAN-VIP / Public IP]
  end
  subgraph Spoke[Spoke-Projekt]
    SpokeIP --> Debian[Debian-Test-VM]
  end
  Debian -->|lokaler Gateway| SNA[SNA / Spoke-Routingtabelle]
  SNA -->|Standardroute| VIP
  WAN --> Internet[Internet]

Verkehr	Pfad
Spoke → Internet	Debian → Spoke-Cloud-Gateway → SNA → LAN-VIP → aktive Firewall → WAN → Internet
Firewall → Spoke	Gaia-Route zum Spoke-Subnetz → LAN-Cloud-Gateway → SNA-Systemroute → Spoke
Öffentliche SSH-Administration	Erlaubte Quelle → Debian-Public-IP; Rückweg über explizite Internet-Ausnahmeroute
Windows-Administration	Erlaubte Quelle → Windows-Public-IP → RDP; Rückweg über Management-Routingtabelle
Gaia-Verwaltung	Windows → private Management-Adresse des jeweiligen Mitglieds
VRRP-Verwaltung	Windows → Gaia Portal der jeweiligen privaten Management-Adresse
Sync-Netz	Dediziertes, nicht geroutetes Netz; VRRP verwendet dieses Interface nicht

Verwaltete Ressourcen

Der Hub-and-Spoke-Routingaufbau entspricht dem Palo-Alto-Beispiel: WAN verwendet eine Internet-Default-Route ohne SNA-Systemrouten, LAN verwendet Systemrouten für den Spoke-Rückweg und die LAN-VIP als Default-Next-Hop, und Spoke verwendet die LAN-VIP ohne Systemrouten. In LAN und Spoke führen spezifische Ausnahmen zu den SSH-Admin-CIDRs direkt ins Internet. Für Datenpfad-Tests deshalb andere Zieladressen verwenden.

WAN- und LAN-Mitglieds-NICs erlauben jeweils 0.0.0.0/0 und die zugehörige VIP als Allowed Addresses. Der reservierte LAN-VIP-Port verwendet ebenfalls Port Security und die LAN-Security-Group. Debian erlaubt eingehende Echo Requests aus den WAN-, LAN-, Management- und Spoke-Netzen sowie den SSH-Admin-CIDRs. Ausgehende TCP-, UDP- und ICMP-Verbindungen sind freigegeben. Die WAN-Security-Group ist explizit stateful; zusätzliche öffentliche Dienste werden über checkpoint_wan_ingress_rules freigegeben. Die breiten öffentlichen TCP-/UDP-Ingress-Regeln des Palo-Alto-Beispiels werden für diese ausgehenden Tests nicht benötigt.

Diese Cloud-Konfiguration ersetzt nicht die Gaia-Routen, Security Policy und NAT auf den Gateways. Die bisher fehlgeschlagenen Internettests werden durch die ergänzten Admin-Ausnahmen und Ping-Freigaben allein nicht behoben; insbesondere bleibt ein Gateway nach fw unloadlocal ohne IP-Forwarding.

Bereich	Ressourcen
Organisation	Eine SNA, eine SNA-Region, vier Routingtabellen und deren Routen
Projekte	Hub und Spoke unter folder_id, jeweils mit networkArea-Label und project_owner_mail
Hub	Vier Netze, zwei Firewalls, zwei 150-GB-Boot-Volumes, acht Mitglieds-NICs, zwei VIP-Ports und öffentliche WAN-IP
Windows	Jumpserver im Hub-Managementnetz, mindestens 80-GB-Boot-Volume, eigene NIC/Public IP, RDP-Security-Group
Spoke	Ein Netz, Debian-VM, 60-GB-Boot-Volume, NIC, Public IP, SSH-Keypair und Security Group
LAN-Testclient	Zusätzliche Debian-VM im vorhandenen Firewall-LAN des Hub-Projekts, 60-GB-Boot-Volume, NIC, Public IP und eigene Security Group
Image	Optional ein im Hub hochgeladenes Check-Point-Image; Debian verwendet eine fest vorgegebene Image-ID

Der Windows-Jumpserver ist nur Administrationshost. Ein Check Point Security Management Server ist in dieser Testumgebung nicht enthalten. Damit testet diese Konfiguration den VRRP-Master/Backup-Wechsel und die VIP-Erreichbarkeit, nicht die zentrale Policy-Verteilung oder zustandsbehaftete Check-Point-Session-Synchronisation.

Dateien

Datei	Aufgabe
01-provider.tf	Provider, Authentifizierung und Routing-Experimente
02-config.tf	Eingabevariablen
03-projects.tf	Hub-/Spoke-Projekt und Projekt-Outputs
03-checkpoint-image.tf	Check-Point-Image-Upload oder vorhandenes Image
04-sna-routing.tf	SNA, Region und Routingtabellen
04-checkpoint-network.tf	Hub-Netze, VIPs und Firewall-Security-Groups
05-checkpoint-appliance1.tf, 06-checkpoint-appliance2.tf	Firewall-VMs, Volumes und NIC-Anbindung
07-outputs.tf	Gaia-Interface- und Routing-Daten
08-windows-jumpserver.tf	Windows, Public IP und RDP-Zugang
09-spoke-vm.tf	Debian-Spoke-VM, Public IP und SSH-Zugang
10-network-validation.tf	SNA-Pool-, Subnetz- und IP-Prüfungen
get-public-ip.sh	Lokaler curl-Aufruf für die automatische Admin-Quell-IP
00-variables.auto.tfvars.example	Konfigurationsvorlage ohne Zugangsdaten
tests/ha.tftest.hcl	Lokale Mock-Tests ohne Cloud-Ressourcen

Voraussetzungen

• Terraform ab 1.5, für Mock-Tests mindestens 1.7. Die Provider-Versionen sind im Lockfile festgehalten. STACKIT 0.76 verwendet für Routingtabellen die Experimente network und routing-tables; die Windows-Image-Suche verwendet die Beta-Datenquelle stackit_image_v2.
• STACKIT-Organisation und Zielordner. Der Service Account benötigt Berechtigungen zum Erstellen von Projekten/SNA sowie zum Verwalten der Ressourcen in beiden neuen Projekten. Ein ausschließlich auf das alte Einzelprojekt berechtigter Key genügt nicht.
• Eigentümer-E-Mail, bestehender SSH-Public-Key und öffentliche Quell-CIDRs für SSH/RDP.
• Geeignetes Check Point QCOW2-Image, Lizenzen und identischer Software-/Hotfix-Stand auf beiden Mitgliedern. Keine bereits individualisierte Gateway-Identität mit SIC-Zertifikaten klonen.
• Für diesen VRRP-Test ist kein Check Point Management Server und keine SmartConsole erforderlich. Ein separater Management Server ist optional und nur nötig, wenn später zentrale Policy-/Logging-Verwaltung gewünscht ist; seine Netze können dann in checkpoint_management_cidrs freigegeben werden.
• Verfügbare Kapazität und passende VM-Typen in zwei Zonen. m2i.2 für Check Point und g2i.2 für Windows sind Ausgangswerte, keine Zusicherung für jede Software-/Blade-Kombination.

Authentifizierung und Konfiguration

Der Provider verwendet seine Standard-Credentials, sofern service_account_key_path = null ist. Eine Token-Datei hat beispielsweise das Format:

{"STACKIT_SERVICE_ACCOUNT_TOKEN": "REPLACE_WITH_YOUR_TOKEN"}

Für den Key-Flow stattdessen in der lokalen Variablendatei:

service_account_key_path = "/path/to/sa-key_YOUR_ORGANIZATION.json"

Key-Datei und Token-Credentials haben unterschiedliche Formate. Der Pfad darf absolut oder relativ angegeben werden; die Auflösung von ~ übernimmt Terraform. Der Provider bezieht daraus das Zugriffstoken. Widersprüchliche STACKIT-Authentifizierungsvariablen in der Shell entfernen. Siehe STACKIT SDK: Authentifizierung.

Bei einer neuen Arbeitskopie:

cp 00-variables.auto.tfvars.example 00-variables.auto.tfvars

Eine bestehende lokale Datei bearbeiten. Mindestens folgende Werte prüfen:

• organization_id, folder_id, project_owner_mail, project_name1, project_name2
• service_account_key_path, public_key_path
• SNA_name, SNA_network_range, SNA_transfer_network
• Region, Availability Zones, Hub-/Spoke-Subnetze, Mitglieds-IP-Adressen und VIPs
• Optional jumpserver_rdp_cidrs, spoke_ssh_cidrs und additional_admin_source_cidrs; bei null wird die aktuelle öffentliche IPv4-Adresse automatisch über https://ifconfig.me/ip ermittelt.
• Check-Point-Image und VM-Größen

spoke_ssh_cidrs = null übernimmt dieselbe automatisch ermittelte Quelladresse wie RDP. Bei Plan/Apply führt Terraform lokal get-public-ip.sh aus; das Skript ruft curl -4fsS https://ifconfig.me/ip auf und verwendet die Antwort als /32 für RDP, SSH und die jeweiligen Rückrouten. Weitere bekannte NAT-Adressen werden über additional_admin_source_cidrs ergänzt und ebenfalls direkt als /32 in den Security Groups hinterlegt. Beispiel: additional_admin_source_cidrs = ["92.209.211.107/32"]. Wenn Terraform aus einem anderen Verwaltungsnetz läuft, können alternativ jumpserver_rdp_cidrs und spoke_ssh_cidrs explizit gesetzt werden. Eine leere Liste ist keine automatische Ermittlung und führt zum Abbruch; null aktiviert die lokale curl-Ermittlung.

Für Debian ist d6a58da1-1ad3-4837-bc87-a046f6428152 der Standard in debian_image_id und in der Beispieldatei. Es gibt keine automatische Debian-Image-Suche und keinen stillen Fallback auf ein anderes Image. Ist diese ID nicht mehr verfügbar, schlägt die Erstellung fehl; ein anderes Image wird nur durch explizites Überschreiben gewählt.

Standardmäßig wird ./jaguar_opt_main.qcow2 ins neue Hub-Projekt hochgeladen. Alternativ checkpoint_image_id auf ein bereits für dieses Projekt zugängliches Image setzen. Das Windows-Image wird über jumpserver_image_name gesucht oder über jumpserver_image_id festgelegt. Bei einer neuen Version des benannten Windows-Images kann Terraform einen VM-Austausch planen; diesen vor dem Apply prüfen. Siehe STACKIT-Image-Rotation.

Netzwerk und Routing

Die Tabelle verwendet die Beispieldatei. Die Defaults in 02-config.tf nutzen andere Hub-/Spoke-Subnetze; lokale Werte überschreiben sie.

Netz	Beispiel-CIDR	Mitglied 1	Mitglied 2	VIP / Test-VM
WAN	10.220.11.0/24	.11	.21	VIP .60
LAN	10.220.10.0/24	.12	.22	VIP .60
Management	10.220.12.0/24	.10	.20	Windows .30
Sync	10.220.13.0/24	.10	.20	keine VIP
Spoke	10.220.14.0/25	–	–	Debian .10
SNA-Pool	10.220.0.0/16	–	–	enthält alle fünf Netze
SNA-Transfer	172.31.255.0/24	–	–	separates Transfernetz

Terraform prüft Überschneidungen, Pool-Zugehörigkeit und die Adressbelegung. Der SNA-Transferbereich darf nicht mit den Pools überlappen. Die erste nutzbare Subnetzadresse bleibt für Cloud-Gateways/Reservierungen frei. Zusätzliche SNA-Pools müssen ebenfalls konfliktfrei gewählt werden.

Der SNA verwendet standardmäßig nur 8.8.8.8 als Default-DNS. STACKIT kann mehrere Resolver beim API-Read in wechselnder Reihenfolge zurückliefern; ein einzelner Resolver verhindert dadurch einen bekannten Terraform-Provider-Fehler bei der erneuten Anwendung.

Routingtabelle	Systemrouten	Standardroute	Zweck
WAN	aus	Internet	Externer Firewall-Verkehr
Management	an	Internet	RDP/Administration unabhängig vom Cluster
LAN	an	LAN-VIP	Systemrouten zum Spoke für den Firewall-Rückweg
Spoke	aus	LAN-VIP	Testverkehr durch die Firewall

Die Spoke-Tabelle erhält zusätzlich für jedes SSH-Quellnetz eine Internet-Route. So laufen Antworten der öffentlichen SSH-Verbindung nicht über das WAN-NAT der Firewall. Diese Ausnahmen gelten für sämtlichen Verkehr zu diesen CIDRs, nicht nur für TCP/22. Für HA-/NAT-Tests daher andere Ziele verwenden. Systemrouten bleiben im Spoke deaktiviert, damit spezifischere direkte Projektrouten den Firewall-Pfad nicht umgehen. Die Wirkung und Prioritäten von SNA-Routingtabellen beschreibt STACKIT.

WAN, LAN, Management und Spoke sind geroutet. Sync bleibt isoliert. Die beiden VIP-Ports reservieren Adressen und werden keiner VM angehängt. WAN-Port-Security erlaubt zusätzlich die WAN-VIP auf beiden Mitgliedern. WAN und LAN verwenden Port Security mit Allowed Addresses für 0.0.0.0/0 und die jeweilige VIP. Die LAN-Security-Group erlaubt alle IPv4-Protokolle in beide Richtungen; die Check-Point-Policy kontrolliert den Transit. Sync bleibt ohne Port Security. Managementports, Windows und Debian haben eigene Security Groups. WAN-Dienste bleiben außer CCP standardmäßig geschlossen und werden über checkpoint_wan_ingress_rules freigegeben.

Für ausgehenden Spoke-Internetverkehr ist Hide-NAT auf die private WAN-VIP vorgesehen. Die Zuverlässigkeit der VIP-Übernahme und der Public-IP-Zustellung zwischen Zonen muss im Zielprojekt getestet werden; Terraform kann diesen Datenpfad nicht bestätigen.

Deployment und Zugriff

terraform init
terraform fmt -check -recursive
terraform validate
terraform plan -out=checkpoint.tfplan
terraform apply checkpoint.tfplan
terraform output projects
terraform output checkpoint_interfaces
terraform output checkpoint_routing
terraform output public-vip
terraform output jumpserver
terraform output spoke
terraform output public-vm-ip

Den Plan vor apply prüfen. Er erstellt jetzt zwei neue Projekte; die bisherige Eingabe project_id entfällt. Eine bestehende Einzelprojekt-Installation würde dadurch nicht automatisch migriert. Die hier vorgenommene Umstellung geht von der zuvor abgebauten Testumgebung aus.

Terraform hängt die Gateway-NICs in der Reihenfolge Management → WAN → LAN → Sync an. Die Gaia-Namen immer anhand der ausgegebenen MAC-Adressen zuordnen.

Windows-Jumpserver

terraform output -raw jumpserver_initial_password

Nach Abschluss der Windows-Ersteinrichtung per RDP an der Jumpserver-Public-IP als .\Administrator anmelden. Das 24-stellige Passwort wird von Terraform generiert und per Cloudbase-Init gesetzt. Die STACKIT-Windows-Images aktivieren RDP selbst; die Security Group erlaubt TCP/3389 nur aus jumpserver_rdp_cidrs und additional_admin_source_cidrs. Quellen: Windows-Bootstrap, RDP-Zugriff.

Vom Windows-Browser beide privaten Gaia-Management-Adressen öffnen. In dieser Testumgebung erfolgt die VRRP-Konfiguration direkt in den beiden Gaia-Portalen; es gibt keinen von Terraform bereitgestellten Management Server und daher auch kein Menü Gateways & Servers. Windows bleibt ausschließlich Administrationshost und erhält keine zweite LAN-NIC.

Das initiale Passwort liegt trotz sensitive-Markierung in State und User-Data. Nach einer manuellen OS-Passwortänderung zeigt Terraform weiterhin das ursprüngliche Bootstrap-Passwort. Zugangsdaten, State, Backups und gespeicherte Pläne schützen; sie sind per .gitignore ausgeschlossen. Für diese lokale Testumgebung wird kein Remote-Backend vorausgesetzt.

Debian-Spoke-VM

terraform output public-vm-ip
ssh -i ~/.ssh/id_ed25519 debian@<PUBLIC_IP_SPOKE_VM>

Den privaten Schlüssel passend zu public_key_path wählen. Terraform lädt ausschließlich den Public Key hoch und richtet den Benutzer debian mit Schlüsselanmeldung ein. Die Spoke-VM übernimmt ihren lokalen Gateway per DHCP. Der vorherige LAN-Testclient mit Konsolenpasswort und einer OS-Route direkt zur LAN-VIP wurde ersetzt.

Nach Konfiguration von Gaia und VRRP:

ip route
getent hosts example.com
sudo apt-get update
sudo apt-get install -y curl
curl -I https://example.com

In Paketmitschnitten und anhand der VRRP-Statusausgabe prüfen, dass die Spoke-Verbindungen tatsächlich über den aktiven VRRP-Master laufen. Für den Failover-Test eine längere Verbindung zu einem Ziel außerhalb der SSH-Ausnahmerouten verwenden. Öffentliches SSH und RDP sollen von der Firewall unabhängig bleiben. Eine zentrale Check-Point-Policy oder SmartConsole-Logging ist ohne separaten Management Server nicht Bestandteil dieser Testumgebung.

Gaia R82 und VRRP konfigurieren

1. Interfaces auf beiden Mitgliedern einrichten

Über die STACKIT-Konsole in Gaia Clish anmelden und show interfaces all mit terraform output checkpoint_interfaces vergleichen. Das folgende Beispiel setzt voraus, dass die MAC-Zuordnung tatsächlich eth0=Management, eth1=WAN, eth2=LAN, eth3=Sync ergibt.

Mitglied 1, mit den Adressen aus der Beispieldatei:

set interface eth0 state on
set interface eth0 ipv4-address 10.220.12.10 mask-length 24
set interface eth1 state on
set interface eth1 ipv4-address 10.220.11.11 mask-length 24
set interface eth2 state on
set interface eth2 ipv4-address 10.220.10.12 mask-length 24
set interface eth3 state on
set interface eth3 ipv4-address 10.220.13.10 mask-length 24
save config

Auf Mitglied 2 dieselben Schritte mit dessen vier Adressen durchführen. Die VIPs hier nicht als physische Interface-Adressen setzen. Sie werden in den VRRP Virtual Routers hinterlegt. Änderungen mit save config dauerhaft speichern. Siehe Gaia R82: physische Interfaces.

1.1 Cloud-Gateways und SNA-Route auslesen

Auf dem Administrationsrechner zuerst die tatsächlich verwendeten Werte anzeigen:

terraform output checkpoint_routing

In dieser Testumgebung sind der WAN-Cloud-Gateway 10.220.11.1, der LAN-Cloud-Gateway 10.220.10.1 und die SNA-Range 10.220.0.0/16.

1.2 Routen auf beiden Gateways setzen

Auf Checkpoint1 und Checkpoint2 jeweils in Gaia Clish ausführen:

set static-route default nexthop gateway address <WAN_GATEWAY> on
set static-route <SNA_CIDR> nexthop gateway address <LAN_GATEWAY> on
save config
show route static all

Mit den aktuellen Testwerten lautet das:

set static-route default nexthop gateway address 10.220.11.1 on
set static-route 10.220.0.0/16 nexthop gateway address 10.220.10.1 on
save config
show route static all

Die SNA-Route 10.220.0.0/16 enthält auch das Spoke-Netz 10.220.14.0/25; die direkt angeschlossenen /24-Netze bleiben aufgrund ihrer spezifischeren Connected Routes lokal. Die Rückroute darf nicht auf die LAN-VIP 10.220.10.60 zeigen, sondern auf den STACKIT-LAN-Gateway 10.220.10.1. Keinen Default-Gateway auf dem Sync-Interface setzen.

1.3 Routen kontrollieren

Auf beiden Gateways prüfen:

show route static all
show route 10.220.14.10

Erwartet werden die Default-Route über 10.220.11.1 und die SNA-Route über 10.220.10.1.

Liegt der Management Server außerhalb des Management-Subnetzes, zusätzlich Hin- und Rückroute über einen erreichbaren Management-Router einrichten. Keinen Default-Gateway auf Sync setzen. Siehe Gaia R82: statische IPv4-Routen.

2. First Time Configuration Wizard und SIC

Vom Administrationshost https://<Management-IP> für jedes Mitglied öffnen. Bei einem unveränderten Gaia-Image lautet der erste Zugang im Gaia Portal und in der CLI Benutzer admin, Passwort admin. Der First Time Configuration Wizard fordert anschließend die Änderung dieses Passworts; bei einem bereits individualisierten QCOW2-Image kann der Zugang abweichen.

Im First Time Configuration Wizard unterschiedliche Hostnamen, passende DNS-/NTP-Einstellungen und sichere Administrator-Zugangsdaten setzen. Auf beiden Gateways müssen die folgenden Optionen gesetzt werden:

1. Als Produkt Security Gateway auswählen.
2. Im Auswahlfeld VRRP Cluster auswählen. ClusterXL ist für dieses R82-Beispiel nicht die verwendete HA-Technik.
3. Enable cluster membership for this gateway beziehungsweise Unit is a part of a cluster nur aktivieren, wenn später ein Management Server und Check-Point-State-Synchronisation verwendet werden sollen. Für den hier beschriebenen VRRP-only-Test ohne Management Server bleibt diese Option deaktiviert; VRRP-Master/Backup und VIP-Failover funktionieren trotzdem.
4. Falls der Wizard bei der Auswahl VRRP Cluster ein Feld Secure Internal Communication (SIC) anzeigt, kannst du einen eigenen Aktivierungsschlüssel setzen. Der SIC-Key wird für die spätere Management-Server-Initialisierung benötigt; er ist kein Check-Point-Lizenzschlüssel und kein Gaia-Administratorpasswort. Ohne Management Server gibt es in dieser Testumgebung keinen SmartConsole-Initialisierungsschritt. Beispiel: openssl rand -base64 24.

Den Wizard auf beiden Gateways abschließen und erforderliche Neustarts durchführen. Lizenzen und identischen R82-/Hotfix-Stand beider Mitglieder prüfen. Siehe Check Point R82: First-Time-Configuration-Wizard.

Bei einem bereits initialisierten Gateway im Expert-Modus cpconfig aufrufen, dort die Cluster-Mitgliedschaft prüfen/aktivieren und erforderlichenfalls SIC initialisieren. Die angebotenen Optionen statt fest angenommener Menünummern verwenden und angeforderte Neustarts ausführen. Siehe cpconfig.

3. VRRP direkt in Gaia konfigurieren

Die VRRP-Konfiguration kann vollständig in Gaia Clish erfolgen. Disable All Virtual Routers muss deaktiviert bleiben. Dieser Schalter löscht die Virtual-Router-Konfiguration nicht, verhindert aber global, dass irgendein VRID aktiv wird; bei aktivem Schalter gibt es keinen VRRP-Master und die VIPs antworten nicht. Für den VRRP-only-Test ohne aktivierte Cluster-Mitgliedschaft Monitor Firewall State deaktivieren; bei später aktivierter Check-Point-State-Synchronisation muss diese Überwachung wieder aktiviert werden.

Zuerst die tatsächliche Zuordnung der Gaia-Interfaces prüfen:

show interfaces all

Die folgenden Befehle auf Mitglied 1 mit der höheren Priorität ausführen. <WAN_INTERFACE> und <LAN_INTERFACE> durch die ermittelten Interface-Namen ersetzen. <VRID> muss auf beiden Mitgliedern gleich sein.

lock database override
set vrrp disable-all-virtual-routers off
set vrrp monitor-firewall off

set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> on
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> priority <PRIMARY_PRIORITY>
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> backup-address <WAN_VIP> on
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> vmac-mode interface-vmac

set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> on
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> priority <PRIMARY_PRIORITY>
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> backup-address <LAN_VIP> on
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> vmac-mode interface-vmac

save config
show vrrp
unlock database

Auf Mitglied 2 dieselben Befehle mit der niedrigeren Priorität ausführen:

lock database override
set vrrp disable-all-virtual-routers off
set vrrp monitor-firewall off

set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> on
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> priority <BACKUP_PRIORITY>
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> backup-address <WAN_VIP> on
set vrrp interface <WAN_INTERFACE> monitored-circuit vrid <VRID> vmac-mode interface-vmac

set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> on
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> priority <BACKUP_PRIORITY>
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> backup-address <LAN_VIP> on
set vrrp interface <LAN_INTERFACE> monitored-circuit vrid <VRID> vmac-mode interface-vmac

save config
show vrrp
unlock database

Für das Beispiel aus 00-variables.auto.tfvars sind <WAN_VIP> 10.220.11.60, <LAN_VIP> 10.220.10.60, <VRID> zum Beispiel 10, <PRIMARY_PRIORITY> 150 und <BACKUP_PRIORITY> 100. Das Gateway mit der höheren Priorität wird zunächst Master. Siehe Check Point R82: VRRP-Cluster vorbereiten.

VMAC-less VRRP auf STACKIT

Für STACKIT keine synthetische gemeinsame VRRP-VMAC verwenden. In einer OVN-basierten Cloud können Port-Security- und MAC-Spoofing-Prüfungen eine zusätzliche oder von der NIC abweichende Quell-MAC verwerfen. interface-vmac verwendet stattdessen die Hardware-MAC der jeweiligen virtuellen NIC. Beim Failover ändern sich dadurch IP- und ARP-Zuordnung auf die physische MAC des neuen Masters; die kurzzeitigen Duplicate-IP-Meldungen während der Umschaltung sind bei diesem Modus erwartbar. Die Befehle im vorherigen Abschnitt setzen vmac-mode interface-vmac auf WAN und LAN auf beiden Gateways. default-vmac, extended-vmac und static-vmac für diese STACKIT-Testumgebung nicht verwenden. Siehe R82 Gaia: VMAC-Modi bei VRRP.

Die Befehle konfigurieren Monitored Circuit/Simplified VRRP: ein gemeinsamer VRID für WAN und LAN, wobei beide Interfaces überwacht werden. Advanced VRRP ist nur nötig, wenn du unterschiedliche VRIDs oder bewusst unterschiedliche Failover-Zuordnungen pro Interface konfigurieren willst. Die VRRP-VIPs entsprechen WAN-VIP und LAN-VIP. Die Interface-Topologie ist:

Interface-Rolle	Cluster-Typ	VIP
WAN	Cluster, extern	WAN-VIP
LAN	Cluster, intern	LAN-VIP
Sync	Sync	keine
Management	Private, nicht überwacht	keine

Wichtig zum Sync-Port: VRRP wird in diesem Aufbau nicht auf ethernet1/3/Sync konfiguriert. Der Sync-Port (10.220.13.0/24) ist ein dediziertes, nicht geroutetes Netzwerk ohne VIP und ohne Cloud-Security-Group. VRRP-Advertisements laufen auf den WAN- und LAN-Interfaces, auf denen die beiden Virtual Router liegen. Für die VRRP-Kommunikation auf WAN ist in Terraform IP-Protokoll 112 (vrrp) als Ingress und Egress freigegeben; auf LAN und Sync gibt es keine Cloud-Filterung. Der Sync-Port ist damit für die Check-Point-interne Synchronisation frei, aber kein VRRP-Interface.

VRRP übernimmt die Gateway-Wahl. Ohne aktivierte Cluster-Mitgliedschaft und ohne Management Server werden Check-Point-Sessions, Policy und Konfiguration nicht synchronisiert. Das Terraform-Projekt legt das Sync-Netz nur als separates Testnetz an; für einen vollständigen stateful HA-Betrieb muss ein Management Server ergänzt, die Cluster-Mitgliedschaft aktiviert und State Synchronization über SmartConsole konfiguriert werden.

Anti-Spoofing passend zu den tatsächlich angeschlossenen Netzen setzen; das hinter dem LAN-Gateway geroutete Spoke-Subnetz muss zur internen LAN-Topologie gehören. VRRP verwendet IPv4-Protokoll 112 und die Multicast-Adresse 224.0.0.18; es ist kein UDP-Port. Die STACKIT-Security Group des WAN-Interfaces erlaubt dieses Protokoll explizit. LAN hat eine Security Group, die alle IPv4-Protokolle in beide Richtungen erlaubt. Sync bleibt ohne Cloud-Security-Group. Quelle: Check Point R82: VRRP und Advanced VRRP.

4. Policy, NAT und Client-Routing (optional)

Eine zentrale Check-Point-Policy und Hide-NAT-Regel können erst mit einem separaten Security Management Server und SmartConsole erstellt werden. Das ist nicht Bestandteil dieser Terraform-Testumgebung. Für die reine VRRP-Wahl ist kein Management Server erforderlich; die geladene InitialPolicy kann die VRRP-Kommunikation und ICMP zum Gateway jedoch blockieren. Für einen funktionierenden Spoke-Datenpfad ist eine passende Firewall-Policy erforderlich. Wenn später ein Management Server ergänzt wird, das Spoke-Subnetz als Netzwerkobjekt anlegen, ICMP und den gewünschten Testverkehr erlauben, die Policy auf beide Gateways installieren und für Internet-Egress Hide-NAT mit der privaten WAN-VIP einrichten. Die zusätzliche öffentliche Abbildung übernimmt die STACKIT-Public-IP-Zuordnung; die öffentliche IP wird keinem Gaia-Interface zugewiesen.

Für den isolierten Funktionstest kann die lokale Policy auf beiden Gateways temporär entfernt werden:

fw unloadlocal

Danach ist der Gateway lokal ungefiltert, aber Check Point deaktiviert dabei auch IP-Forwarding. Deshalb eignet sich dieser Zustand zum Prüfen der VRRP-Wahl und des Pings auf eine lokale LAN-VIP, nicht zum Testen des Spoke-Datenpfads. Nach dem Test die Policy auf beiden Gateways wieder laden:

fw fetch localhost
fw stat

Wenn keine lokale Policy vorhanden ist, ist dafür ein Management Server erforderlich; fw unloadlocal ist keine dauerhafte Freigabe. Siehe Check Point R82: fw unloadlocal.

Die Debian-Spoke-VM behält den per DHCP gelieferten Gateway ihres eigenen Spoke-Subnetzes. Die SNA-Routingtabelle leitet den Verkehr anschließend zur LAN-VIP weiter. Die LAN-VIP liegt nicht im Spoke-Subnetz und darf deshalb nicht direkt als Debian-Default-Gateway gesetzt werden. Die Cloud-Konfiguration ersetzt hier die bisherige lokale LAN-Testclient-Route. Eventuelle zusätzliche Clients direkt im Firewall-LAN könnten weiterhin die LAN-VIP als lokalen Gateway verwenden. Siehe Check Point R82: VRRP-Cluster vorbereiten.

Für veröffentlichte interne Dienste zusätzlich Destination-NAT und die zugehörigen Policy-/Cloud-Freigaben konfigurieren. Bei VPN hinter der Public-IP-Abbildung Peer-Identität, Link Selection und NAT-T passend zur Gegenstelle einrichten; die Cloud-Portfreigabe allein richtet keinen Tunnel ein.

Funktion und Failover prüfen

2.1 VRRP-Zustand prüfen

Auf beiden Mitgliedern in Gaia Clish (im Expert-Modus jeweils über clish -c "<Befehl>") ausführen:

show vrrp summary
show vrrp interfaces
show vrrp stats

Erwartet werden Checkpoint1 als Master (Priorität 150) und Checkpoint2 als Backup (Priorität 100). Wenn beide Gateways Master bleiben, auf beiden Mitgliedern fw stat prüfen. Steht dort InitialPolicy, kann sie VRRP blockieren. tcpdump -ni <WAN_INTERFACE> -e -vv 'ip proto 112' zeigt, ob Advertisements an 224.0.0.18 ankommen; show vrrp stats muss auf dem Backup steigende Rx Advertisement-Zähler zeigen. set vrrp monitor-firewall off entfernt keine Policy. Diese Diagnosekommandos sind im Check Point R82 Gaia Administration Guide dokumentiert.

2.2 Cloud- und LAN-Pfad testen

Zuerst von der LAN-Test-VM die LAN-VIP testen:

ping 10.220.10.60

Danach von der Spoke-VM testen:

ping 10.220.10.60
curl -4 https://ifconfig.me/ip

Wenn die LAN-Test-VM funktioniert, die Spoke-VM aber nicht, fehlen meistens die Check-Point-Rückroute 10.220.0.0/16 über 10.220.10.1, IP-Forwarding oder eine ICMP-Regel in der Check-Point-Policy. fw unloadlocal darf für diesen Datenpfad nicht aktiv sein, weil es IP-Forwarding deaktiviert.

2.3 Public-IP-Failover durchführen

Erst wenn ein Master und ein Backup angezeigt werden und die Routen auf beiden Gateways stimmen:

1. Die Public-IP aus Terraform auslesen:

   terraform output -raw public-vip
   

2. Von einem externen System eine längere Verbindung zu einem ausdrücklich erlaubten Dienst auf dieser Public-IP öffnen. SSH zur Debian- oder Windows-Administration ist kein geeigneter Nachweis, weil diese Verbindungen über separate Public IPs laufen.

3. Auf dem aktuellen Master den betroffenen Virtual Router kontrolliert deaktivieren oder seine Priorität absenken.

4. Auf beiden Gateways prüfen:

   show vrrp summary
   

   Das Backup muss Master werden; die WAN-VIP bleibt 10.220.11.60 und die STACKIT-Public-IP bleibt erreichbar.

5. Den externen Dienst erneut prüfen. Danach den Virtual Router wieder aktivieren und den Rückwechsel entsprechend der Preempt-Einstellung beobachten.

Ein erfolgreicher administrativer Wechsel ersetzt keinen Test eines VM- oder Zonenausfalls. Für die Abnahme zusätzlich einen VM-Ausfall kontrolliert nachstellen, Wiederanlauf prüfen und Unterbrechungszeiten dokumentieren. Siehe Check Point R82: VRRP-Cluster vorbereiten.

Lokale Prüfungen

Debian direkt im Firewall-LAN

11-lan-test-vm.tf erstellt zusätzlich checkpoint-lan-test im bestehenden LAN-Netz (10.220.10.0/24 in dieser Umgebung). STACKIT vergibt die freie private IP automatisch. Image (debian_image_id), VM-Größe (spoke_flavor) und SSH-Key entsprechen der Spoke-VM. Die Adressen liefert terraform output lan_test; der Login erfolgt mit ssh debian@<PUBLIC_IP> und dem vorhandenen privaten SSH-Key. Öffentliches SSH ist auf die konfigurierten SSH-Admin-CIDRs begrenzt; aus dem Managementnetz ist SSH ebenfalls freigegeben.

Dieser Client erreicht die beiden LAN-Adressen und die LAN-VIP direkt im selben Subnetz. Damit lassen sich LAN-/VRRP-Probleme getrennt vom SNA-Spoke-Routing untersuchen. DHCP liefert weiterhin den LAN-Cloud-Gateway; die LAN-Routingtabelle übernimmt den nächsten Hop zur Firewall für Default-Verkehr. Die Admin-Ausnahmeroute ermöglicht den öffentlichen SSH-Rückweg. Die VM wird bei terraform destroy mit entfernt.

Terraform prüfen

terraform fmt -check -recursive
terraform validate
terraform test

Die Mock-Tests prüfen Projektzuordnung, SNA-/Routing-Verknüpfungen, SSH-Rückwege, die feste Debian-Image-ID, Windows-Bootstrap und fehlerhafte Netzeingaben. Sie erzeugen keine Cloud-Ressourcen. Verfügbarkeit der Images, Berechtigungen, OS-Boot und echtes Cluster-Failover bleiben nach dem Deployment zu prüfen.

Testumgebung entfernen

terraform plan -destroy -out=checkpoint-destroy.tfplan
terraform apply checkpoint-destroy.tfplan

Den Destroy-Plan vor dem Apply prüfen. Entfernt werden die verwalteten VMs, Volumes, NICs, Public IPs, Security Groups, Netze, Routen, Routingtabellen, der SSH-Keypair-Eintrag, ein hier hochgeladenes Check-Point-Image, beide Projekte und die SNA. Keine zusätzlichen, nicht von dieser Konfiguration verwalteten Ressourcen in den Testprojekten ablegen.

Organisation, übergeordneter Ordner, extern bereitgestellte Images, lokale QCOW2-Datei, SSH-Schlüsseldateien, Zugangsdaten unter ~/.stackit und ein separat betriebener Management Server werden nicht verwaltet. Lokale State-/Backup- und Plan-Dateien können nach dem Destroy weiterhin das ursprüngliche Windows-Passwort enthalten.