[solved] Available Packages pkg-static: Repository pfSense load error

[p54]

Hallo zusammen,

ich habe seit kurzem ein seltsames Phenomän mit dem Available Packages Manager.

Nachdem ich meine alte Firewall-Hardware gegen einen Fitlat2 getauscht habe, findet der pgk Manager keine verfügbaren Packete nach einer gewissen Zeit.

Zum Fitlat2 ist natürlich zu beachten in der im Bootmenü der pfSense Installation vor der Installation den Punkt [3] zu wählen um die Controller Settings zu ändern, damit pfSense starten kann:

set hw.sdhci.enable_msi=0
set hint.sdhci_pci.0.disabled=1

Ist dies erledigt startet die Installationsroutine ohne Probleme, danach muss nach dem reboot der pfSense Hardware in die shell [8] gewechselt werden und unter /boot/loader.conf der Wert:

hw.sdhci.enable_msi="0"

wie auch unter /boot/device.hints :

hint.sdhci_pci.0.disabled="1"

hinterlegt werden. Nach der initialen Fertigstellung für pfSense_v2_4_4-p1 kann dann das Upgrade auf p2 durchgeführt werden. Danach sind die oberen Werte wieder unter /boot/ zu hinterlegen.

Soweit so gut. Nachdem ich von meinem alten System die Backup-XML entsprechend auf die Netzwerkinterface angepasst und diese wiederhergestellt habe bootet das System neu und im Nachgang werden alle Packetet nach und nach eingerichtet.

squid, squidGuard, pfBlockerNG-devel und suricata habe ich dennoch (ohne Backup der Settings) gelöscht und erneut installiert.

Soweit so gut ;)

Jetzt ist es so, dass das System nach einer gewissen Zeit unter Available Packages keine Packete mehr angezeigt bekommt.
Starte ich das System neu, sind diese wieder verfügbar. Dennoch kommt es nach einer Zeit (ist nicht nachvollziehbar wann genau) sind diese wieder nicht mehr verfügbar.

Nach einem reboot habe ich folgendes protokolliert:

#Enter an option: 13

>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
Your packages are up to date
pfSense - Netgate Device ID: YYYYYYYYYYYYYYYYYYY

#ls -al /var/db/pkg/
total 6624
drwxr-xr-x   2 root  wheel      512 Apr  5 06:36 .
drwxr-xr-x  21 root  wheel     1024 Apr  5 07:35 ..
-rw-r--r--   1 root  wheel  5398528 Apr  5 06:35 local.sqlite
-rw-r--r--   1 root  wheel      246 Jan  7 19:26 pfSense-core.meta
-rw-r--r--   1 root  wheel      246 Apr  5 06:36 pfSense.meta
-rw-r--r--   1 root  wheel   212992 Jan  7 19:26 repo-pfSense-core.sqlite
-rw-r--r--   1 root  wheel  1069056 Apr  5 04:16 repo-pfSense.sqlite

#uptime
8:09AM  up  1:35, 2 users, load averages: 0.26, 0.24, 0.23

#dig  _https._tcp.pkg.pfsense.org SRV

; <<>> DiG 9.12.2-P1 <<>> _https._tcp.pkg.pfsense.org SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30526
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_https._tcp.pkg.pfsense.org.   IN      SRV

;; ANSWER SECTION:
_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files00.netgate.com.
_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files01.netgate.com.

;; Query time: 266 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 05 08:13:16 CEST 2019
;; MSG SIZE  rcvd: 134

#less /conf/config.xml
 
                <pkg_repo_conf_path>/usr/local/share/pfSense/pkg/repos/pfSense-repo.conf</pkg_repo_conf_path>


#less /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf
FreeBSD: { enabled: no }

pfSense-core: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

pfSense: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

Alles tipptopp!

Nach einer Zeit jedoch sieht es dann so aus:

Enter an option: 13

>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core/meta.txz: No route to host
repository pfSense-core has no meta file, using default settings
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core/packagesite.txz: No route to host
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: Repository pfSense load error: access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or directory
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4/meta.txz: No route to host
repository pfSense has no meta file, using default settings
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4/packagesite.txz: No route to host
Unable to update repository pfSense
Error updating repositories!
pfSense - Netgate Device ID: YYYYYYYYYYYYYYYYYYY

# uptime
 9:12AM  up  2:38, 2 users, load averages: 0.13, 0.29, 0.29
 
# dig  _https._tcp.pkg.pfsense.org SRV

; <<>> DiG 9.12.2-P1 <<>> _https._tcp.pkg.pfsense.org SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59177
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_https._tcp.pkg.pfsense.org.   IN      SRV

;; ANSWER SECTION:
_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files01.netgate.com.
_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files00.netgate.com.

;; Query time: 236 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 05 09:13:10 CEST 2019
;; MSG SIZE  rcvd: 134

# ls -al /var/db/pkg/
total 5536
drwxr-xr-x   2 root  wheel      512 Apr  5 09:01 .
drwxr-xr-x  21 root  wheel     1024 Apr  5 08:35 ..
-rw-r--r--   1 root  wheel  5398528 Apr  5 06:35 local.sqlite
-rw-r--r--   1 root  wheel      246 Jan  7 19:26 pfSense-core.meta
-rw-r--r--   1 root  wheel      246 Apr  5 06:36 pfSense.meta
-rw-r--r--   1 root  wheel   212992 Jan  7 19:26 repo-pfSense-core.sqlite

#less /conf/config.xml
                <pkg_repo_conf_path>/usr/local/share/pfSense/pkg/repos/pfSense-repo.conf</pkg_repo_conf_path>

				#less /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf
FreeBSD: { enabled: no }

pfSense-core: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

pfSense: {
  url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

Kann sich das jemand erklären warum die repo-pfSense.sqlite einfach so entfernt wird? Liegt dies an einem Sync, wenn er kein git-repo beziehen kann, dass dann diese DB einfach gelöscht wird? Und warum sagt er auf einmal "No route to host" obwohl es davor ja funktioniert hat, nach dem reboot?

Ich habe schon viel probiert und verschiedene Packete weg gelassen oder nach dem zurückspielen der BACKUP-XML jedoch lag es an keiner dieser Anwendungen.

Es ist es seltsam. Was ich noch nicht gemacht habe, einfach alles ohne Backup zu installieren und konfigurieren, aber dann wäre ja dieses Backup für die Katz wenn es damit nicht funktionieren würde.

VG, p54

[Grimson]

@p54 said in Available Packages pkg-static: Repository pfSense load error:

Nachdem ich meine alte Firewall-Hardware gegen einen Fitlat2 getauscht habe, findet der pgk Manager keine verfügbaren Packete nach einer gewissen Zeit.

Zum Fitlat2 ist natürlich zu beachten in der im Bootmenü der pfSense Installation vor der Installation den Punkt [3] zu wählen um die Controller Settings zu ändern, damit pfSense starten kann:

Tja, hättest halt vernünftige Hardware kaufen sollen.

hinterlegt werden. Nach der initialen Fertigstellung für pfSense_v2_4_4-p1 kann dann das Upgrade auf p2 durchgeführt werden. Danach sind die oberen Werte wieder unter /boot/ zu hinterlegen.

Wenn man mal ordentlich RTFM macht sollte man wissen das man eigene tunings nicht in die loader.conf schreibt. Sondern in die loader.conf.local, denn diese wird bei updates eben nicht überschrieben.

Und warum sagt er auf einmal "No route to host" obwohl es davor ja funktioniert hat, nach dem reboot?

Ich habe schon viel probiert und verschiedene Packete weg gelassen oder nach dem zurückspielen der BACKUP-XML jedoch lag es an keiner dieser Anwendungen.

Na warum schaust du dir nicht erstmal Diagnostics -> Routes an wenn du schon gesehen hast das es da ein Problem gibt? Ich würde ja fast wetten das die pfSense das default gateway gewechselt hat, du hast nicht zufällig ein (sinnfreies) gateway auf dem LAN eingerichtet? Geh auf System -> Routing und setze die default gateways mal ordentlich.

[p54]

Moinsen,

@Grimson said in Available Packages pkg-static: Repository pfSense load error:

Tja, hättest halt vernünftige Hardware kaufen sollen.

Ja, ärgert mich auch ein wenig. Vorallem mit Zoll und RMA (was über 3 Monate dann Zeit gekostet hat) In Summer hätte ich mir dann doch eine ander Hardware zulegen können. :( Aber jetzt habe ich sie schon zuhause. Evtl. kann ich die dann mal in der Familie weiter verteilen und mir eine neue zulegen ;) Dachte auch für den Preis, cooles Ding....würde ich nicht noch einmal kaufen - aber eher meine Meinung dazu.

Wenn man mal ordentlich RTFM macht sollte man wissen das man eigene tunings nicht in die loader.conf schreibt. Sondern in die loader.conf.local, denn diese wird bei updates eben nicht überschrieben.

Oh, danke für den Tipp! Soweit bin ich noch nicht vorgedrungen. Bisher hatte ich so eine "bescheidene" Hardware noch nicht im Einsatz, die nicht vom OS unterstützt wurde und sonst auch keine Bedürfnisse hatte in der loader etwas zu ändern. Aber der Tipp wird hier gern angenommen, auch die RTFM ;)

Na warum schaust du dir nicht erstmal Diagnostics -> Routes an wenn du schon gesehen hast das es da ein Problem gibt? Ich würde ja fast wetten das die pfSense das default gateway gewechselt hat, du hast nicht zufällig ein (sinnfreies) gateway auf dem LAN eingerichtet? Geh auf System -> Routing und setze die default gateways mal ordentlich.

Sinnfrei ist gut ;) ich habe mich da ein wenig verkünstelt für meine VPN, aber stört die denn dort wirklich?

GW_WAN (default)		Default (IPv4) 	WAN 	192.168.178.1 	192.168.178.1 	Interface wan Gateway
RW_VPN_VPNV4 		                        RW_VPN 	10.2.25.1 	10.2.25.1 	Interface RW_VPN_VPNV4 Gateway 

VG, p54

[Grimson]

@p54 said in Available Packages pkg-static: Repository pfSense load error:

Sinnfrei ist gut ;) ich habe mich da ein wenig verkünstelt für meine VPN, aber stört die denn dort wirklich?

Seit version 2.4.4 hat sich die Gateway Logik von pfSense geändert (Release Notes immer lesen!), pfSense wählt jetzt per default das standard Gateway selbst aus den verfügbaren. Sollte also dein normales WAN gateway kurzzeitig Probleme (Ping, Paketverlust) zeigen bzw. dein VPN Gateway da einfach bessere Werte bieten schaltet die pfSense auf dieses um.

Also am besten genau schauen ob dein VPN Gateway wirklich sinn macht, und ansonsten eben unter System -> Routing dein WAN Gateway fest als default einstellen:

Evtl. musst du die Einstellung, auch wenn sie zu stimmen scheint, nochmals mit dem Save Button explizit speichern.

[p54]

Hi,

okay. Zum Test habe ich die VPN GW deaktiviert. Somit nutzt er wieder standardmäßig das WAN GW.
Hab jetzt sogar die IPv6 mit none hinterlegt und gespeichert.

Aktuell zeigt er mir noch nichts an in Available Packages nach dem Save & Apply.
Werde vorsichtshalber einen reboot anstoßen und es beobachten was er dann macht.

Echt nervig das Thema.

Danke erst einmal, ich werde später berichten ;)

VG, p54

PS: Nach dem reboot siehts noch gut aus:

[Grimson]

Falls es dann noch immer nicht geht schau dir mal Diagnostics -> Routes an.

[p54]

Und jetzt ist es soweit. Wieder alles weg.

Aber was mir gerade aufgefallen ist, meine SSH session wurde kurzzeitg beendet - ich sitz extern und bin via VPN verbunden, daher habe ich es bemerkt.

Es kann daher schon irgendwie mit dem GW WAN zusammenhängen, aber ich finde kein Logs dazu.

Und hier mal die Routen:

Aber hier fällt mir nichts auf was nicht stimmen könnte.

[Grimson]

Hmm, lass mal von der pfSense auf der Konsole ein traceroute auf files01.netgate.com und files00.netgate.com laufen.

[p54]

Hey,

also nachdem ich mich vergewissert habe, läuft jetzt aktuell auf meiner alten Firewall - mit all den Settings wie oben deaktivert, ohne Probleme. Der tracert funktioniert natürlich auch.

#traceroute files00.netgate.com
traceroute to files00.netgate.com (162.208.119.41), 64 hops max, 40 byte packets
 1  192.168.178.1 (192.168.178.1)  0.446 ms  0.365 ms  0.422 ms
 2  YYYYYYY (YYYYYYY)  4.953 ms  5.159 ms  4.747 ms
 3  ZZZZZZZZ (ZZZZZZZZ)  15.238 ms  15.304 ms  15.392 ms
 4  * 80.157.129.202 (80.157.129.202)  16.617 ms  16.285 ms
 5  * 4.69.214.26 (4.69.214.26)  105.103 ms  105.309 ms
 6  the-new-yor.ear1.newark1.level3.net (4.15.150.218)  101.619 ms  101.621 ms  101.455 ms
 7  cs90.cs99new.v.ewr.nyinternet.net (96.47.77.218)  101.267 ms  101.596 ms  101.495 ms
 8  * * *
 9  *^C

#traceroute files01.netgate.com
traceroute to files01.netgate.com (162.208.119.40), 64 hops max, 40 byte packets
 1  192.168.178.1 (192.168.178.1)  0.497 ms  0.398 ms  0.376 ms
 2  YYYYYYY (YYYYYYY)  4.905 ms  4.663 ms  4.994 ms
 3  ZZZZZZZZ (ZZZZZZZZ)  15.929 ms  18.529 ms  16.219 ms
 4  * 80.157.129.202 (80.157.129.202)  16.622 ms  16.390 ms
 5  * 4.69.214.26 (4.69.214.26)  105.065 ms  104.954 ms
 6  the-new-yor.ear1.newark1.level3.net (4.15.150.218)  101.627 ms  101.755 ms  108.128 ms
 7  cs90.cs99new.v.ewr.nyinternet.net (96.47.77.218)  102.330 ms  101.756 ms  101.449 ms
 8  * *^C

während ich gestern kurz auf der neuen Firewall den trace angesehen hatte, einen zugriff verweigert erhalten habe. Google und andere funktionierten problemlos.
Ich teste dies jetzt ohne Backup-REcovery auf der neuen Firewall und schau mal was dann da so passiert.

VG, p54

[p54]

Hi,

hier ein kleines Update. Nachdem ich alles neu und manuell installiert hatte, funktioniert auch alles wie gewohnt.
Was jetzt der Grund für diesen Fehler war, kann ich nicht sagen. Ich schätze es kam wahrscheinlich aus der Netzwerkecke und der Zuordnung der physikalischen Schnittstellen. Ich hatte zwar deren Bezeichnung auf die neue Hardware angepasst, aber evtl. einen Punkt übersehen. Aber nur eine Mutmaßung an dieser Stelle.

Danke für eure Unterstützung dennoch zu diesem Thema. #likepfsense #likepfsensecommunity ;)

VG, p54