Packages update über einen Proxy Server

cheesi

[2.5.2-RELEASE][admin@cpststzgw01.cpstst.jc.local]/root: curl --proxy "https://172.21.100.8:3128" "https://packages.netgate.com/pfSense_v2_4_5_amd64-core/packagesite.txz"
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Würde gern auch mal versuchen die Sense ohne Internet zum Updaten. Aber finde hierzu auch nicht wirklich was.

Langsam glaub ich, dass es ein DNS auflösungsproblem mit dem SRV record ist.

mansior

dachte zuerst, dass der A Record bei pkg.pfsense.org fehlt. Aber laut github pfsense repo hat es gar keine A Records. Curl kann mit SRV Records aber nichts anfangen, das "Feature" steht auf der Todo Liste: https://curl.se/docs/todo.html#SRV_and_URI_DNS_records

Ich bin mir nicht sicher ob HTTP(s) Proxy Server das können. Das zu prüfen wäre für mich der nächste "Schritt".

VG

viragomann

@mansior
Interessant. Das erklärt, dass man den URL nicht im Browser aufrufen kann.

Die Ausgabe von pfSense-upgrade verschleiert dann aber auch nur allzu schön den tatsächlichen Hostnamen. Finde ich irreführend.

mansior

@viragomann
copy&paste von dem verlinkten Artikel, ich bin jedoch nicht tief genug in pfSense drin um sagen zu können, dass die update Schritte hiermit auch manuell "nachbauen" kann:

pkg does not use A/AAAA records. It uses service (SRV) records. The update
server meta names such as pkg.pfsense.org are not meant to be accessed
directly using a browser.

To find the actual update servers, lookup the SRV record for the host:


  $ host -t srv _https._tcp.pkg.pfsense.org
  _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files01.netgate.com.
  _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files00.netgate.com.

  $ host files01.netgate.com.
  files01.netgate.com has address 162.208.119.40
  files01.netgate.com has IPv6 address 2610:1c1:0:6::40

  $ host files00.netgate.com.
  files00.netgate.com has address 162.208.119.41
  files00.netgate.com has IPv6 address 2610:1c1:0:6::41

Accessing the hosts using their real hostnames will work with a browser:


  $ curl --output /dev/null --silent --head --fail \
   "https://files00.netgate.com/pfSense_v2_4_5_amd64-core/meta.txz"
  $ echo $?
  0

viragomann

@mansior
Ja, hab ich mir angesehen und tlw. nachvollzogen. Kannte den Umstand aber zuvor nicht.

Die Zeilen mit "host" zeigen aber lediglich DNS Abfragen zur Darstellung, dass pkg.pfsense.org keinen A-Record hat. Einen SRV ja übrigens auch nicht.

Damit die pfSense an die Update Pakete kommt, muss sie dann aber explizit den SRV für _https._tcp.pkg.pfsense.org abfragen und das ist nicht, was die Ausgabe von

pfSense-upgrade -d -c

glauben lassen möchte.

Ja, es bleibt zu untersuchen, ob der Proxy den SRV Eintrag überhaupt abfragt, nachdem die pfSense nicht selbst Namensauflösungen machen darf und dann infolge den daraus ermittelten Hostnamen. Dem hatte ich nichts hinzu zu fügen.

mansior

ein möglicher "Workaround" wäre eventuell die notwendigen DNS Records manuell im DNS des Proxy zu hinterlegen. @cheesi kommst du an die Logs des Proxy Servers? Kannst du die PCAPs zur Verfügung stellen? Dann kann man zumindest nachvollziehen was genau die pfSense "verlässt"...

JeGr

@viragomann said in Packages update über einen Proxy Server:

Die Ausgabe von pfSense-upgrade verschleiert dann aber auch nur allzu schön den tatsächlichen Hostnamen. Finde ich irreführend.

Hat tatsächlich nichts mit Verschleiern zu tun und ist in der Doku auch so dargestellt und aufgeschlüsselt. Dass files00 und 01 abgefragt werden ist gängig und die Methode via SRV nutzt eben FreeBSDs PKG an der Stelle. Machen andere Tools auch, SRV Calls sind jetzt nichts Neues. Da findet man bei TrueNAS oder FreeBSD selbst auch ein zwei Posts zu wo Leute mit kaputten DNS Configs Probleme haben und beim Debugging meinen, die PKG Quellen wären "kaputt" weil es keinen A sondern loadbalanced regionale SRV Entries gibt.

viragomann

@jegr said in Packages update über einen Proxy Server:

Hat tatsächlich nichts mit Verschleiern zu tun und ist in der Doku auch so dargestellt und aufgeschlüsselt.

Weiß man aber erst, nachdem man die Doku so ausführlich gelesen hat.
Dieses Kapitel hab ich wohl ausgespart. ;-)

Der Update-Prozess stellt es jedenfalls nicht transparent dar. Die Zeile

pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-core/meta.txz: Bad Gateway

lässt für mein Dafürhalten nicht erkennen, dass das Problem tatsächlich bei

https://files01.netgate.com/pfSense_v2_4_5_amd64-core/meta.txz

auftritt.

Somit verschleiert für mich die Funktion den wahren URL. Ich habe damit aber keine Böswilligkeit unterstellt.

JeGr

@viragomann said in Packages update über einen Proxy Server:

Dieses Kapitel hab ich wohl ausgespart. ;-)

Wie viele - ich auch am Anfang :D

@viragomann said in Packages update über einen Proxy Server:

lässt für mein Dafürhalten nicht erkennen, dass das Problem tatsächlich bei
https://files01.netgate.com/pfSense_v2_4_5_amd64-core/meta.txz

Ist für das Debugging tatsächlich schwerer, stimme ich voll zu.

Soweit ich mich aber erinnere wurde/wird das für Loadbalancing und Redirection via DNS genutzt, aber da steck ich grad nicht tief drin, ich hab da nur damals die Diskussion zu gesehen. Da gehts mehr drum, dass du ne saubere zentrale Repo-URI hast die man nicht überall auf irgendwelche Mirrors anpassen musst und untendrunter dann eben je nach DNS Streuung und SRV Antwort du verschiedene lokale(re) Mirrors transparent ergänzen kannst ohne dass die Leute selbst was tun müssen. Aber wie gesagt, da bin ich nicht so irre drin :)

cheesi

Hi Community,
ich habe eine Lösung gefunden. Also wie es scheint, haben proxys Probleme bei SRV Lookup. Somit konnte das Update nicht sauber funktionieren. Daher habe ich ein paar Veränderungen vorgenommen.
-) Zuerst habe ich die pkg.conf angepasst, so dass pkg immer den Proxy benützt.

*![97641e0c-fc2f-4c7f-a2eb-82dc1a87f4e2-image.png](/assets/uploads/files/1649746577303-97641e0c-fc2f-4c7f-a2eb-82dc1a87f4e2-image.png) italicised text*/usr/local/etc/pkg.conf to -> 
PKG_ENV {
HTTP_PROXY = 172.21.100.8:3128;
HTTPS_PROXY = 172.21.100.8:3128;
SSL_CA_CERT_PATH = /usr/local/share/certs;
}

Weiters habe ich die URL statt dem SRV record, den DNS record benützt.
/usr/local/etc/pkg/repos/pfSense.conf

pfSense-core: {
  url: "pkg+https://files00.netgate.com/pfSense_v2_6_0_amd64-core",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/local/share/pfSense/keys/pkg",
  enabled: yes
}

Das Updaten funktioniert nur auf der CLI sowie Packages zu installieren.
Warum es in der GUI nicht funktioniert, habe ich leider nicht herausgefunden. Tippe mal, dass die GUI irgendwelche andere Config Files benützt.

LG