3
PfSense HA Sync funktioniert nicht (Error: Operation timed out)
Hallo zusammen,
aktuell setze ich eine HA-Umgebung mit PfSense auf - das funtkioniert auch soweit, bis auf den Sync der Einstellungen zwischen den PfSensen.
Sync-Interfaces sind up und in den EInstellungen unter HA als Sync-Interface ausgewählt. Die States werden erfolgreich synchronisiert.
CARP VirtualIPs funktionieren auch, inkl Failover.
Ping zwischen den beiden Routern über die SYNC-IP ist in beide Richtungen möglich.
Firewall Rules im Sync Tab: Allow any
Beide PFSensen sind auf Port 444 mit HTTPS erreichbar.
Beide FW Version: 2.7.2-Release
Beide Firewalls exakt die selben Interfaces.
Master PF: 172.22.1.2
Backup PF: 172.22.1.3
Identifizierter Fehlercode:
A communications error occurred while attempting to call XMLRPC method host_firmware_version: Unable to connect to tls://172.22.1.3:444. Error: Operation timed out
Syslog Master PF:
Syslog Backup PF:
Ich habe im Internet gelesen man solle testweise den DNS-Resolver/Forwarder deaktivieren: Selber Fehler.
Ich habe auch in den Sync-Einstellungen testweise nur eine Checkbox aktiviert (Firewall rules): Selber Fehler.
Irgendjemand eine Idee?
Danke schonmal
aktuell setze ich eine HA-Umgebung mit PfSense auf - das funtkioniert auch soweit, bis auf den Sync der Einstellungen zwischen den PfSensen.
Sync-Interfaces sind up und in den EInstellungen unter HA als Sync-Interface ausgewählt. Die States werden erfolgreich synchronisiert.
CARP VirtualIPs funktionieren auch, inkl Failover.
Ping zwischen den beiden Routern über die SYNC-IP ist in beide Richtungen möglich.
Firewall Rules im Sync Tab: Allow any
Beide PFSensen sind auf Port 444 mit HTTPS erreichbar.
Beide FW Version: 2.7.2-Release
Beide Firewalls exakt die selben Interfaces.
Master PF: 172.22.1.2
Backup PF: 172.22.1.3
Identifizierter Fehlercode:
A communications error occurred while attempting to call XMLRPC method host_firmware_version: Unable to connect to tls://172.22.1.3:444. Error: Operation timed out
Syslog Master PF:
Nov 16 15:54:22 kernel carp: demoted by 0 to 0 (pfsync bulk fail)
Nov 16 15:54:01 php-fpm 44568 /rc.filter_synchronize: The pfSense software configuration version of the other member could not be determined. Skipping synchronization to avoid causing a problem!
Nov 16 15:54:01 php-fpm 44568 /rc.filter_synchronize: XMLRPC versioncheck: -- 23.3
Nov 16 15:54:01 php-fpm 44568 /rc.filter_synchronize: New alert found: A communications error occurred while attempting to call XMLRPC method host_firmware_version: Unable to connect to tls://172.22.1.3:444. Error: Operation timed out
Nov 16 15:54:01 php-fpm 44568 /rc.filter_synchronize: A communications error occurred while attempting to call XMLRPC method host_firmware_version: Unable to connect to tls://172.22.1.3:444. Error: Operation timed out
Nov 16 15:53:51 php-fpm 44568 /rc.filter_synchronize: Beginning XMLRPC sync data to https://172.22.1.3:444/xmlrpc.php. Syslog Backup PF:
Nov 16 15:49:33 kernel carp: demoted by 0 to 0 (pfsync bulk fail)
Nov 16 15:48:29 php-fpm 46926 /system_hasync.php: Configuring CARP settings finalize...
Nov 16 15:48:29 php-fpm 46926 /system_hasync.php: pfsync done in 1 seconds.
Nov 16 15:48:28 kernel carp: demoted by 0 to 0 (pfsync bulk start)
Nov 16 15:48:28 php-fpm 46926 /system_hasync.php: waiting for pfsync...
Nov 16 15:48:28 check_reload_status 428 Syncing firewall Ich habe im Internet gelesen man solle testweise den DNS-Resolver/Forwarder deaktivieren: Selber Fehler.
Ich habe auch in den Sync-Einstellungen testweise nur eine Checkbox aktiviert (Firewall rules): Selber Fehler.
Irgendjemand eine Idee?
Danke schonmal
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669576
Url: https://administrator.de/forum/pfsense-ha-sync-funktioniert-nicht-error-operation-timed-out-669576.html
Ausgedruckt am: 22.12.2024 um 04:12 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
funktioniert auch ein Porttest auf 172.22.1.3:444?
Wenn ok, dann würde ich mal testweise HTTPS deaktivieren, um ein TLS Problem auszuschließen.
Grüße
funktioniert auch ein Porttest auf 172.22.1.3:444?
Wenn ok, dann würde ich mal testweise HTTPS deaktivieren, um ein TLS Problem auszuschließen.
Grüße
1
Moin,
danke für den Input:
Porttest:
SSL deaktivieren:
Interessanter Vorschlag. Ich hatte tatsächlich schon eine CA erstellt, in beiden PFS als vertrauenswürdig importiert und dann die WebGUI mit Certs dieser CA geschützt, leider ohne Erfolg.
Wenn ich HTTP statt HTTPS für das Webinterface an beiden PFS aktiviere, bekomme ich (wie auch zuvor) einen "Firewall PASS" im Log, es wird also wie bei HTTPS irgendwie eine Verbindung aufgebaut.
Im Log zum Sync der Master-PFS:
Im Log zum Sync der Backup-PFS:
Garnichts.
Für weitere Vorschläge offen
danke für den Input:
Porttest:
Port test to host: 172.22.1.3 Port: 444 successful.SSL deaktivieren:
Interessanter Vorschlag. Ich hatte tatsächlich schon eine CA erstellt, in beiden PFS als vertrauenswürdig importiert und dann die WebGUI mit Certs dieser CA geschützt, leider ohne Erfolg.
Wenn ich HTTP statt HTTPS für das Webinterface an beiden PFS aktiviere, bekomme ich (wie auch zuvor) einen "Firewall PASS" im Log, es wird also wie bei HTTPS irgendwie eine Verbindung aufgebaut.
PASS Nov 18 18:38:42 SYNC USER_RULE (1731798405) 172.22.1.2:3465 172.22.1.3:444 TCP:SIm Log zum Sync der Master-PFS:
Nov 18 18:40:43 php-fpm 29931 /rc.filter_synchronize: Retrying XMLRPC Request due to error: A communications error occurred while attempting to call XMLRPC method restore_config_section: Request timed out due to default_socket_timeout php.ini setting
Nov 18 18:39:43 php-fpm 29931 /rc.filter_synchronize: Beginning XMLRPC sync data to http://172.22.1.3:444/xmlrpc.php.Im Log zum Sync der Backup-PFS:
Garnichts.
Für weitere Vorschläge offen
Update:
Die etwas veränderte Fehlermeldung hat mich auf diesen Beitrag gebracht:
https://forum.netgate.com/topic/171959/a-communications-error-occurred-w ...
Lösung:
Die MTU-Size manuell herabsetzen. (In meinem Fall 1360)
Warum?
Ich habe ein VXLAN+IPSEC zwischen den Nodes, welches Overhead erzeugt. Deshalb ist die MTU in meinem virtuellen Switch auf 1360 gesenkt. Leider hat das die PFSense nicht mitbekommen, in der Status der Adapter war die MTU auf 1500. Das manuelle herabsetzen auf 1360 war letzten Endes die Lösung.
Danke
Die etwas veränderte Fehlermeldung hat mich auf diesen Beitrag gebracht:
https://forum.netgate.com/topic/171959/a-communications-error-occurred-w ...
Lösung:
Die MTU-Size manuell herabsetzen. (In meinem Fall 1360)
Warum?
Ich habe ein VXLAN+IPSEC zwischen den Nodes, welches Overhead erzeugt. Deshalb ist die MTU in meinem virtuellen Switch auf 1360 gesenkt. Leider hat das die PFSense nicht mitbekommen, in der Status der Adapter war die MTU auf 1500. Das manuelle herabsetzen auf 1360 war letzten Endes die Lösung.
Danke
3
