Updates / Packages sind nicht verfügbar auf primary pfsense

genesis_mp

Hallo,

wir haben bei uns 2 PFSense im Einsatz die über CARP Failover miteinander verknüpft sind. Nennen wir Sie FW1 und FW2. Die FW1 ist die primary und die FW2 die secondary.

Nun habe ich das Problem dass ich bei der FW1 die Meldung bekommen "Unable to check for updates." und bei Packages "Unable to communicate with https://packages.pfsense.org. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity.".
WAN1 ist Default Gateway. Wenn ich nun Ping zu packages.pfsense.org mache bekomme ich bei Source WAN1 korrekte Pakete zurück. Über LAN1 kann er es nicht erreichen.
DNS und Trace das selbe Spiel. Das komische ist allerdings, dass die FW2, welche ja die Einstellungen mit/von der FW1 synchronisiert diese Probleme nicht hat. Dort kann es die Updates und die Packages prüfen.

Als Fehlermeldung habe ich bei der FW1 im Log:

php-fpm[57920]: /pkg_mgr.php: XMLRPC communication error: Operation timed out
php-fpm[57920]: /pkg_mgr.php: XML_RPC_Client: Connection to RPC server packages.pfsense.org:443 failed. Operation timed out 103

Da ich schon verschiedene Threads durchgelesene habe, IPV6 is enabled, Default Gateway ist WAN1, kein Proxy, kein Snort, DNS Resolver ist an (ALL, ALL), MTU ist Default (1500)

Version PFSense: 2.2.6-RELEASE (amd64)
built on Mon Dec 21 14:50:08 CST 2015

Was kann dieses Problem verursachen?

Danke für eure Hilfe!

Lg
David

flix87

Ich vermute unter System: Firmware und da unter Updater Settings steht eine alte URL drin.
Sollte bei dir so was drin stehen: https://updates.pfsense.org/_updaters/amd64
oder du wählst einfach unter Default Auto Update URLs deine PfSense Version aus dann sollte die richtige URL unten eingetragen werden

viragomann

@genesis_mp:

WAN1 ist Default Gateway. Wenn ich nun Ping zu packages.pfsense.org mache bekomme ich bei Source WAN1 korrekte Pakete zurück.

Was ist WAN1? Ein Router, Modem?

@genesis_mp:

Das komische ist allerdings, dass die FW2, welche ja die Einstellungen mit/von der FW1 synchronisiert diese Probleme nicht hat. Dort kann es die Updates und die Packages prüfen.

Als Fehlermeldung habe ich bei der FW1 im Log:
php-fpm[57920]: /pkg_mgr.php: XMLRPC communication error: Operation timed out
php-fpm[57920]: /pkg_mgr.php: XML_RPC_Client: Connection to RPC server packages.pfsense.org:443 failed. Operation timed out 103

Das steht im Widerspruch. Der Fehler bedeutet, dass die pfSense nicht synchronisieren kann. Überprüfe IP, Passwort und dass beide auf dem selben Port für die WebGUI lauschen.

Welche der beiden ist Master?

genesis_mp

@flix87:

Ich vermute unter System: Firmware und da unter Updater Settings steht eine alte URL drin.
Sollte bei dir so was drin stehen: https://updates.pfsense.org/_updaters/amd64
oder du wählst einfach unter Default Auto Update URLs deine PfSense Version aus dann sollte die richtige URL unten eingetragen werden

Dort ist gar nichts eingetragen, weder bei FW1 noch bei FW2.

@viragomann:

@genesis_mp:

WAN1 ist Default Gateway. Wenn ich nun Ping zu packages.pfsense.org mache bekomme ich bei Source WAN1 korrekte Pakete zurück.

Was ist WAN1? Ein Router, Modem?

@genesis_mp:

Das komische ist allerdings, dass die FW2, welche ja die Einstellungen mit/von der FW1 synchronisiert diese Probleme nicht hat. Dort kann es die Updates und die Packages prüfen.

Als Fehlermeldung habe ich bei der FW1 im Log:
php-fpm[57920]: /pkg_mgr.php: XMLRPC communication error: Operation timed out
php-fpm[57920]: /pkg_mgr.php: XML_RPC_Client: Connection to RPC server packages.pfsense.org:443 failed. Operation timed out 103

Das steht im Widerspruch. Der Fehler bedeutet, dass die pfSense nicht synchronisieren kann. Überprüfe IP, Passwort und dass beide auf dem selben Port für die WebGUI lauschen.

Welche der beiden ist Master?

WAN1 ist ein Zyxel Router für den Internetzugang. Aus diesem gehen 2 Kabel, eines zur FW1 und eines zur FW2.
WAN2 ist ein weiterer Zyxel Router für den Backup Internetzugang. Selbes Spiel.

Der Sync zwischen Firewalls funktioniert aber. Wenn ich eine Regel ändere, ist diese sofort auch auf der FW2.

Log:
php-fpm[28395]: /rc.filter_synchronize: Filter sync successfully completed with https://10.250.250.2:443.
php-fpm[28395]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://10.250.250.2:443.
php-fpm[28395]: /rc.filter_synchronize: Beginning XMLRPC sync to https://10.250.250.2:443.
check_reload_status: Reloading filter
check_reload_status: Syncing firewall

Die FW1 ist Master, die FW2 ist Backup.

JeGr

Ich glaube das hat virago vielleicht nicht ganz gesehen, dass sich hier der Paketmanager über das Problem beschwehrt und nicht der Fliter/sonstwas Sync Prozess. Der Fehler ist schon im Paketmanager. Die Frage ist nur, ob FW1 und FW2 die gleichen Paket/Firmware Quellen konfiguriert haben? Die Frage ist auch wie lange das Problem bereits besteht. Ein Ping auf packages.pfsense.org und ein Port Check auf TCP 443 der Adresse auf beiden Maschinen von deren WAN IP aus, wäre hilfreich. Und ggf. - wenn so konfiguriert - von deren CARP VIP.

Was ist bei den Zyxeln als Weiterleitung eingetragen? Ich denke mal die sind auf volles Forwarding zur pfSense konfiguriert. Leiten die beide sauber auf die VIP weiter? Oder leiten sie auf eine der beiden IPs? Wichtig wäre dann auch, dass die Maschinen ggf. über ihre VIP und normale IP sauber ins Netz kommen. Das letzte mal als ich so einen Fehler gesehen habe, war eines davon nicht gegeben (Weiterleitung landete auf einem der Knoten, nicht auf der VIP) bzw. die CARP IP auf dem WAN konnte nicht ins Netz, die spezifischen IPs aber schon.

Gruß Jens

flix87

schon mal

oder du wählst einfach unter Default Auto Update URLs deine PfSense Version aus dann sollte die richtige URL unten eingetragen werden

probiert wie ich es gesagt hatte?

bei dir wird ja nach " https://packages.pfsense.org" gesucht bei mir steht aber "https://updates.pfsense.org/_updaters/amd64" drin und da bekomme ich einen Status bei mir

ich vermute mal bei dir steht druch Updaten einfach eine alte und damit falsche Adresse drin.

genesis_mp

@flix87:

schon mal

oder du wählst einfach unter Default Auto Update URLs deine PfSense Version aus dann sollte die richtige URL unten eingetragen werden

probiert wie ich es gesagt hatte?

bei dir wird ja nach " https://packages.pfsense.org" gesucht bei mir steht aber "https://updates.pfsense.org/_updaters/amd64" drin und da bekomme ich einen Status bei mir

ich vermute mal bei dir steht druch Updaten einfach eine alte und damit falsche Adresse drin.

Ich hab das auch gecheckt, allerdings ist es auch so wenn ich nichts eintrage steht bei Auto Update folgendes:
Could not contact pfSense update server https://updates.pfsense.org/_updaters/amd64
Also nimmt er dort schon die richtige Adresse…

@JeGr:

Ich glaube das hat virago vielleicht nicht ganz gesehen, dass sich hier der Paketmanager über das Problem beschwehrt und nicht der Fliter/sonstwas Sync Prozess. Der Fehler ist schon im Paketmanager. Die Frage ist nur, ob FW1 und FW2 die gleichen Paket/Firmware Quellen konfiguriert haben? Die Frage ist auch wie lange das Problem bereits besteht. Ein Ping auf packages.pfsense.org und ein Port Check auf TCP 443 der Adresse auf beiden Maschinen von deren WAN IP aus, wäre hilfreich. Und ggf. - wenn so konfiguriert - von deren CARP VIP.

Was ist bei den Zyxeln als Weiterleitung eingetragen? Ich denke mal die sind auf volles Forwarding zur pfSense konfiguriert. Leiten die beide sauber auf die VIP weiter? Oder leiten sie auf eine der beiden IPs? Wichtig wäre dann auch, dass die Maschinen ggf. über ihre VIP und normale IP sauber ins Netz kommen. Das letzte mal als ich so einen Fehler gesehen habe, war eines davon nicht gegeben (Weiterleitung landete auf einem der Knoten, nicht auf der VIP) bzw. die CARP IP auf dem WAN konnte nicht ins Netz, die spezifischen IPs aber schon.

Gruß Jens

FW1 Ping / TCP Check zu packages.pfsense.org von WAN1:

PING packages.pfsense.org (208.123.73.88) from 10.10.1.2: 56 data bytes
64 bytes from 208.123.73.88: icmp_seq=0 ttl=49 time=186.274 ms
64 bytes from 208.123.73.88: icmp_seq=1 ttl=49 time=185.919 ms
64 bytes from 208.123.73.88: icmp_seq=2 ttl=49 time=186.053 ms

–- packages.pfsense.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 185.919/186.082/186.274/0.146 ms

Connection to packages.pfsense.org 443 port [tcp/https] succeeded!

Das selbe Spiel von LAN1:

PING packages.pfsense.org (208.123.73.88) from 10.10.10.2: 56 data bytes

–- packages.pfsense.org ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Connection failed (Refused/Timeout)

FW2 Ping / TCP Check zu packages.pfsense.org von WAN1:

Selbes Ergebnis wie bei FW1

von LAN1:
PING packages.pfsense.org (208.123.73.88) from 10.10.10.3: 56 data bytes
64 bytes from 208.123.73.88: icmp_seq=0 ttl=49 time=186.430 ms
64 bytes from 208.123.73.88: icmp_seq=1 ttl=49 time=186.147 ms
64 bytes from 208.123.73.88: icmp_seq=2 ttl=49 time=186.034 ms

–- packages.pfsense.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 186.034/186.204/186.430/0.167 ms

von LAN1:
Connection to packages.pfsense.org 443 port [tcp/https] succeeded!

Das Problem scheint also folgendes zu sein. Von FW1 komme ich über LAN1 nicht an packages.pfsense.org, von FW2 schon. Die Regeln bei FW2 werden aber von FW1 synchronisiert also kann es daran nicht liegen. Woran kann es dann liegen? Da die FW1 so wie die FW2 aber WAN1 von dem selben Zyxel Router kommen kann es ja auch nicht an dem liegen…

Danke euch für eure Hilfe.
David

viragomann

@genesis_mp:

WAN1 ist ein Zyxel Router für den Internetzugang. Aus diesem gehen 2 Kabel, eines zur FW1 und eines zur FW2.
WAN2 ist ein weiterer Zyxel Router für den Backup Internetzugang. Selbes Spiel.

Der Sync zwischen Firewalls funktioniert aber. Wenn ich eine Regel ändere, ist diese sofort auch auf der FW2.

Die FW1 ist Master, die FW2 ist Backup.

Dass du "WAN1" einmal für einen Router und einmal für das pfSense Interface verwendest, hat mich verwirrt. Und dass du eine Dual-WAN-Konfiguration hast, hast du ja auch im Eröffnungs-Post verschwiegen.

Die Fehlermeldung "pkg_mgr.php: XMLRPC communication error: Operation timed out" deutet jedenfalls auf eine Problem mit der XMLRPC Synchronisation hin. In diesem Fall offenbar vom Paket-Manager-Modul.
Warum es anderswo funktioniert, ist mir da auch ein Rätsel. Der Paket-Mgr. verwendet die Konfiguration, die in System > High Availability Sync angegeben ist und die auch für die Filter verantwortlich ist.

Das Problem mit dem fehlschlagenden Ping vom LAN wäre auf der Backup-FW normal, daher die Frage.
Funktioniert denn der Ping auf einen anderen Host im Web?
Und hast du in Status > CARP auf beiden FWs überprüft, dass FW1 für jedes Interface Master und FW2 Backup ist?

Ich hätte hier eigentlich ein falsch konfiguriertes Outbound NAT in Verdacht. Damit wir das überprüfen können, musst du uns aber deine ganze Interface-, CARP- und Outbound NAT-Konfig. verraten. Am schönsten via Screenshots.

genesis_mp

@viragomann:

@genesis_mp:

WAN1 ist ein Zyxel Router für den Internetzugang. Aus diesem gehen 2 Kabel, eines zur FW1 und eines zur FW2.
WAN2 ist ein weiterer Zyxel Router für den Backup Internetzugang. Selbes Spiel.

Der Sync zwischen Firewalls funktioniert aber. Wenn ich eine Regel ändere, ist diese sofort auch auf der FW2.

Die FW1 ist Master, die FW2 ist Backup.

Dass du "WAN1" einmal für einen Router und einmal für das pfSense Interface verwendest, hat mich verwirrt. Und dass du eine Dual-WAN-Konfiguration hast, hast du ja auch im Eröffnungs-Post verschwiegen.

Die Fehlermeldung "pkg_mgr.php: XMLRPC communication error: Operation timed out" deutet jedenfalls auf eine Problem mit der XMLRPC Synchronisation hin. In diesem Fall offenbar vom Paket-Manager-Modul.
Warum es anderswo funktioniert, ist mir da auch ein Rätsel. Der Paket-Mgr. verwendet die Konfiguration, die in System > High Availability Sync angegeben ist und die auch für die Filter verantwortlich ist.

Das Problem mit dem fehlschlagenden Ping vom LAN wäre auf der Backup-FW normal, daher die Frage.
Funktioniert denn der Ping auf einen anderen Host im Web?
Und hast du in Status > CARP auf beiden FWs überprüft, dass FW1 für jedes Interface Master und FW2 Backup ist?

Ich hätte hier eigentlich ein falsch konfiguriertes Outbound NAT in Verdacht. Damit wir das überprüfen können, musst du uns aber deine ganze Interface-, CARP- und Outbound NAT-Konfig. verraten. Am schönsten via Screenshots.

Der Ping und Port Test hat ja auf der Backup FW funktioniert, auf der Primary PFSense eben nicht. Obwohl ja die FW Regeln von der FW1 auf die FW2 übertragen werden deshalb verstehe ich das nicht…

Ich glaube genau darin liegt das Problem, dass die Primary FW1 nicht mehr über LAN1 (die FW1 hat eine IP aus dem LAN1 netz) ins Internet kommt. Die Backup FW2 hat dieses Problem nicht.

JeGr

Ich hätte hier eigentlich ein falsch konfiguriertes Outbound NAT in Verdacht. Damit wir das überprüfen können, musst du uns aber deine ganze Interface-, CARP- und Outbound NAT-Konfig. verraten. Am schönsten via Screenshots.

@Virago: Dito, hatte ich auch, aber die Ergebnisse wären genau verkehrt herum dafür, was mich sehr stutzig macht.

@genesis: hast du mal spaßeshalber die Primäre FW neu gebootet und die sekundäre übernehmen lassen?

genesis_mp

@JeGr:

@genesis: hast du mal spaßeshalber die Primäre FW neu gebootet und die sekundäre übernehmen lassen?

Werde ich heute Abend mal ausprobieren und testen. Vielleicht auch gleich den Zyxel Router dazu durchstarten so dass alles über die Backup FW und Backup Internetleitung geht. Danach beides wieder neu starten…

viragomann

@genesis_mp:

Der Ping und Port Test hat ja auf der Backup FW funktioniert, auf der Primary PFSense eben nicht. Obwohl ja die FW Regeln von der FW1 auf die FW2 übertragen werden deshalb verstehe ich das nicht…

Mit Quelle LAN Interface IP oder LAN CARP VIP dürfte er auf der Backup-FW gar nicht funktionieren, nur mit Quelle = Default (die FW selbst) oder WAN address.
Und wenn es auf der Master-pfSense mit Quelle = LAN IP nicht funktioniert, müssten die LAN-Host auch ein Problem haben, mit Hosts im WAN zu kommunizieren.

Da ist also einiges seltsam, aber ohne genaue Informationen, lässt sich das nicht klären.