Packages update über einen Proxy Server

viragomann

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

Die Auflösung der externen Domain übernimmt ja der Proxy und nicht das lokale System.

Ach, das habe ich erst nicht so verstanden. Danke für die Aufklärung.

cheesi

Lieber Viragomann ich bedanke mich für deinen Input. Sorry, dass ich fragen stelle wie ein Anfänger das bin ich leider auch :(. Tut mir sehr leid dafür.

Wie Mansior schreibt wenn ich eine HTTP(s) anfrage mit einem Proxy stelle benötige ich ja kein DNS. So hätte ich das verstanden und auch glaub ich stunden lange heute recherchiert :).

Damit ich das jetzt richtig versteh braucht man jetzt für externe Domain wenn man über einen Proxy geht keinen DNS? Da die externen Domaine der Proxy auflöst.

curl --proxy "http://172.21.100.8:3128" "http://www.google.at" funktioniert einwand frei bekomme den html code der seite zurück

<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="de-AT"><head><meta content="text/html; charset=UTF-8" http-equiv="Content-Type"><meta content="/logos/doodles/2022/get-vaccinated-wear-a-mask-save-lives-january-20-copy-6753651837109686-law.gif" itemprop="image"><meta content="Lass dich impfen. Trag eine Maske. Rette Leben." property="twitter:title"><meta content="Lass dich impfen. Trag eine Maske. Rette Leben. #GoogleDoodle" property="twitter:description">.......

und so weite. Danke für eure Hilfe !

viragomann

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

curl --proxy "http://172.21.100.8:3128"

Genau so hast du auch die Proxy-Einstellungen in der pfSense gemacht?

Vielleicht solltest du auch noch in System > General Setup den DNS rauslöschen, damit die pfSense nicht versucht ist, selbst aufzulösen.
Bzw. bei "DNS Resolution Behavior" "ignore local DNS" auswählen.

Sollte es nicht funktionieren, wäre interessant, was denn würde ich mal ins System-Log schauen, ob es Hinweise auf das Problem gibt.

cheesi

@viragomann
Sollte alles so haben

werde mal auch in der zwischen Zeit mal System logs durchwühlen

Danke für eure Hilfe !!

cheesi

Habe paar Logs durchforstet aber glaube habe das richtig log nicht gefunden.
Im Systemlog steht leider nichts und im Upgrade Log auch nichts.
Habt Ihr eine Idee wo die Update abfrage gelogt werden könnte.

vi upgrade_log.txt
ERROR: It was not possible to determine pkg remote version
ERROR: It was not possible to determine pfSense-repo remote version
ERROR: Unable to compare version of pfSense-repo

LG und Danke,

mansior

@cheesi
Bei sowas stöbere ich immer etwas im dunkeln, aber ich würde einfach mal ein pcap aufzeichnen und schauen wohin die Anfrage geht. Quell IP müsste die von der pfSense sein....

cheesi

@mansior Hi sorry war ein wenig beruflich eingespannt. Werde mal schauen wie ein pcap aufzeichent und werde es hier posten. Danke mal für deinen Tipp

cheesi

Hallo Community,

leider hänge ich immer noch an meinem Problem, dass ich über einen Proxy keine Updates ziehen kann.

Ich habe jetzt auch mit einem 2 Proxy-Server getestet

HTTP_PROXY=172.21.100.5:3333
HTTPS_PROXY=172.21.100.5:3333
[2.5.2-RELEASE][admin@cpststzgw01.cpstst.jc.local]/etc: pfSense-upgrade -d -c
>>> Updating repositories metadata...
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
Updating pfSense-core repository catalogue...
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-core/meta.txz: Bad Gateway
repository pfSense-core has no meta file, using default settings
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-core/packagesite.txz: Bad Gateway
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-pfSense_v2_4_5/meta.txz: Bad Gateway
repository pfSense has no meta file, using default settings
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-pfSense_v2_4_5/packagesite.txz: Bad Gateway
Unable to update repository pfSense
Error updating repositories!
ERROR: Unable to compare version of pfSense-repo

Jedoch passt alles mit CURL

 curl --proxy "http://172.21.100.5:3333" "http://packages.netgate.com/pfSense_v2_4_5_amd64-core/packagesite.txz"

                    <!doctype html>
                    <html>
                        <head>
                            <meta charset='utf-8'>
                            <title></title><style type='text/css'> @charset 'utf-8';
                        html, body          { height: 100%; margin: 0; }
                        body                { font-family: 'Helvetica Neue','Helvetica','Segoe UI', Arial, sans-serif; color:#5c5c5c; background: #fafafa}
                        a                   { text-decoration: none; color: #169ad5; }

Ich habe auch ein Packet Trace mitlaufen lassen! Ich würde es auch gerne zu Verfügung stellen

Ich weiß leider nicht mehr weiter und würde auf eure Hilfe hoffen.

LG und Danke!

micneu

@cheesi ich gebe zu, ich lese jetzt nicht nochmal alles.
warum kannst du keine internetverbindung ohne proxy machen?
in was für einer umgebung brauchst du den proxy?
es hat zwar nichts mit deiner problemlösung zu tun aber ich möchte es verstehen.
2. sehe ich das du hier noch eine 2.4.5 einsetzt. ich verstehe es so da sie noch nicht mit deinem proxy richtig läuft ist sie ja nicht produktiv. warum setzt du sie dann nicht neu auf mit der 2.6er?

viragomann

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

Jedoch passt alles mit CURL
curl --proxy "http://172.21.100.5:3333" "http://packages.netgate.com/pfSense_v2_4_5_amd64-core/packagesite.txz"

Beim Aufruf von http://packages.netgate.com.
Der Updater ruft aber https://pkg.pfsense.org auf.

Du musst schon idente Bedingungen vergleichen.

cheesi

Hi micneu,

also diese Umgebung ist eine art DMZ. Somit bekommt ich hier keine "direkten" Zugriff zum Inet. Deswegen der weg über den Proxy.
Meinst du soll ich mal eine PfSense mit 2.6 isntallieren und schauen ob dies hiermit besser ist?
Ich würde es mir wünschen. Mir kommt es halt immer noch vor, dass das "System" nicht sauber den Proxy benützt.

cheesi

@viragomann

[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 :)