WPAD funktioniert nicht

[tt33tt]

Ich erhalte eine wpad.dat-Datei unter https://wpad.domain.local/wpad.dat Aber, wenn ich Autokonfiguration bei den Proxy-Einstellungen im Internet-Explorer einstelle, kommt folgender Fehler "INET_E_RESOURCE_NOT_FOUND". Über die manuelle Eingabe der Proxyeinstellunge, ist alles ok

Ist die Datei, die ich erhalte, richtig?

/*
  PAC file created via OPNsense
  To use this file you have to enter its URL into your browsers network settings.
*/
function FindProxyForURL(url, host) {




if (((!isPlainHostName(host)) && (!shExpMatch(host, "*.domain")) && (!shExpMatch(host, "*.domain.local")))) {
return "PROXY OPNsense.domain.local:3128";
}

   // If no rule exists - use a direct connection
   return "DIRECT";
}

[hbc]

Hallo!

Die Frage ist wohl, wie lieferst Du die wpad.dat an Deine Clients? Über DHCP-Option 252 ( Enable Web Proxy Auto Discovery im DHCP-Server) oder über DNS-Eintrag (WPAD Records in Unbound)?

Denn bei DHCP-Option 252 kann ich exakt die URL und auch Protokoll/Port angeben - also auch auf HTTPS-URLs verweisen, während über DNS und die Abfrage des wpad-Eintrags laut meiner Recherchen nur HTTP genutzt wird.

Wenn also die wpad.dat nicht auch über Port 80/http zugänglich ist, dann dürfte es nicht klappen.

Ich habe nämlich gerade dieses Problem und bin daher über Deinen Beitrag gestolpert. Ich möchte einerseits meinen Firewall-Login nur über HTTPS haben, andererseits auch WPAD über DNS nutzen.

Noch sehe ich keine Möglichkeit das über OpnSense Bordmittel zu realisieren, außer ggf. mit Revers-Proxies zu arbeiten. Weil selbst mit DHCP-Option 252 und Verweis auf eine HTTPS-URL muß ich ja HTTPS auf Clientseite freigeben, damit Zugriff auf die wpad.dat besteht - damit geben ich dann aber auch Zugriff auf den Login der Firewall frei.

Aber hierzu werde ich einen Extrapost anlegen in der Hoffnung, das jemand hier im Forum Rat weiß.

Update:
Ich habe mein Problem doch noch einfach lösen können. Mein opnSense Webinterface erst mal auf Port 8443 gelegt, damit es nicht versehentlich über irgendwelche Proxies oder HTTPS-Regeln zugänglich ist.

Das nginx-Plugin installiert und gemäß der Anleitung https://wiki.opnsense.org/manual/how-tos/nginx_hosting.html einen lokalen Webserver aufgesetzt und auf Port 80 konfiguriert. Nun einen symbolischen Link auf /usr/local/www/wpad.dat dort ins Webroot gelegt und dann Port 80 auf dem entsprechenden Interface freigegeben. Anschließend DHCP-Option 252 ebenfalls auf Port 80 konfiguriert.

Der Client erhält nun sowohl über DHCP als auch DNS WPAD die HTTP-URL und kann darüber die wpad.dat abrufen. Und da die einzige Datei im lokalen Webroot auch nur diese und das Webinterface ist nun auch nicht mehr für Clients zugänglich, da man es genau restriktieren kann.

Dank des symbolischen Links, kann weiterhin die GUI genutzt werden, um die wpad.dat zu bearbeiten. Man muß dazu nicht mehr ins Filesystem.

Wichtig:
Im DHCP-Server nicht einfach Enable Web Proxy Auto Discovery aktivieren, sonst wird eine URL generiert, die auf den Port des Firewall-Logins verweist (in meinem Fall dann 8443), sondern manuell bei Additional Options die Option 252/String eintragen und dann die URL zum lokalen Webserver Port 80.

[mimugmail]

Wenn du die http auf https Umleitung aktiv hast muss der Client dem Root Zertifikat vertrauen, dann braucht's auch kein Nginx

[fabian]

@hbc: noch einfacher währe es mit dem location match "=" und dem pfad "/wpad.dat" gegangen, wenn du das root auf das web interface setzt. dann werden die von ausßerhalb (server properties) immer noch mit dem Standard ausgeliefert (vermutlich: not found). So hättest du dir den symlink sparen können

[hbc]

@hbc: noch einfacher währe es mit dem location match "=" und dem pfad "/wpad.dat" gegangen, wenn du das root auf das web interface setzt. dann werden die von ausßerhalb (server properties) immer noch mit dem Standard ausgeliefert (vermutlich: not found). So hättest du dir den symlink sparen können

@fabian:
Guter Hinweis. Den Match mit "=" habe ich ohnehin gesetzt, aber Du hast recht: Ich hätte mir eigenen DocRoot und SymLink sparen können. Trotzdem fühle ich mich irgendwie sicherer, wenn ich nicht das opnSense DocRoot mit den ganzen php-Dateien "recycle" und den Zugriff nur auf eine Datei restriktiere, sondern einen dedizierten DocRoot erstelle.

Wenn du die http auf https Umleitung aktiv hast muss der Client dem Root Zertifikat vertrauen, dann braucht's auch kein Nginx

@mimugmail:
Das ist korrekt, aber ganz ehrlich? Wer will den Zugriff auf das opnSense-Admin-GUI für das komplette LAN und somit jeden öffnen, nur damit die Clients dann an die wpad.dat kommen?
Das kann man zuhause bei sich im Heimnetz machen, wenn man der einzige Nutzer im LAN ist. Aber in einer größeren Einrichtung oder gar einem Studentenwohnheim wäre das wohl grob fahrlässig. Da ist dann OTP für den Login ohnehin obligatorisch und ich könnte regelmäßig Brute-Force-Attacken von intern auf die Loginseite feststellen. Da würde ich dann eher noch einen bestehenden Web-Server mitnutzen, um die wpad.dat auszuliefern, aber das schafft dann eben Abhängigkeiten.

[mimugmail]

Irgendeinen Tod muss man immer sterben

[tt33tt]

Bei mir klappt WPAD weiterhin leider nicht.

Ich habe den Zugriff auf OPNSense für alle geöffnet.
Außerdem werde ich von http://198.51.100.1/wpad.dat automatisch nach https://198.51.100.1/wpad.dat weitergeleitet.
Ich bekomme trotzdem einen Zertifkatsfehler. Ist der Zertifikatsfehler die Ursache dafür, dass es nicht funktioniert?

Ich habe die Pac-Datei sogar soweit angepasst, dass sie wie folgt aussieht:

Code: [Select]

/*
  PAC file created via OPNsense
  To use this file you have to enter its URL into your browsers network settings.
*/
function FindProxyForURL(url, host) {




if (((dateRange("JAN", "DEC")))) {
return "PROXY 198.51.100.1:3128";
}

   // If no rule exists - use a direct connection
   return "DIRECT";
}

Das habe ich nun mit Chrome debuggt: chrome://net-internals/#proxy Infos hier: http://artica-proxy.com/how-to-debug-proxy-pac-with-google-chrome/
Ergebnis:
--
Effective proxy settings
Use DIRECT connections.
Original proxy settings
PAC script: http://198.51.100.1/wpad.dat
--

[mimugmail]

Ja, hab ich doch geschrieben. Dann leg ein selbstsigniertes Zertifikat für Webfrontend an und installier die CA am client. Oder du schaltest den automatischen Redirect von http auf https ab.

[tt33tt]

Achso, ich hatte das so herum verstanden, dass man kein NGIX mehr braucht, weil alles super ist ;-)

Ich habe nur eine Möglichkeit gefunden über die GUI die Weiterleitung zum Webinterface abschalte. Ist das über die GUI möglich oder muss ich da in die Shell?

[mimugmail]

System : Settings : Advanced : Disable Web UI redirect

Dann kannst du wpad OHNE nginx verwenden, musst aber aufpassen dass du zu Admin von OPN immer https verwendest, sonst ist es plain

[hbc]

Ich habe nur eine Möglichkeit gefunden über die GUI die Weiterleitung zum Webinterface abschalte. Ist das über die GUI möglich oder muss ich da in die Shell?

Wenn Du aber die Weiterleitung von HTTP zu HTTPS abschaltest, dann hast Du wieder das Problem, das WPAD via DNS nicht funktionieren wird, weil hier auf Port 80 gesucht wird und der Webserver Deinem Client eben nicht via Redirect sagt, das er auf Port 443 suchen soll...

Klar sollte man die Zahl der Dienste auf einer Firewall so minimal wie möglich halten, aber der nginx macht hier durchaus Sinn, wenn man eben keinen Redirect möchte und sich aber nicht nur alleine auf DHCP Option 252 verlassen will. Viele Clients unterstützen das gar nicht und greifen nur via WPAD DNS auf die wpad.dat Datei zu.

Es besteht natürlich immer die Möglichkeit den DNS Eintrag für WPAD auf einen extra Webserver zu verweisen, der dann Port 80 und 443 offen hat - dies dann auch gerne via Redirect. Der Client muß ja nur bei Anfrage auf Port 80 zum richtigen Ziel geführt werden. Wenn Du die wpad.dat von der opnSense outsourced, dann biste dort selbst natürlich völlig frei was Ports angeht.

[tt33tt]

System : Settings : Advanced : Disable Web UI redirect

Dann kannst du wpad OHNE nginx verwenden, musst aber aufpassen dass du zu Admin von OPN immer https verwendest, sonst ist es plain

Ich habe WPAD über DNS im Einsatz.
Ich würde gerne die Weiterleitung auf HTTPS abschalten. Es heißt bei mir auf Deutsch "Deaktiviere die Umleitungsregel für die Weboberfläche". Leider klappt es nicht, die Umleitungsregel abzuschalten. Sogar beim Webinterface werde ich weiterhin automatisch von HTTP auf HTTPS umgeleitet.

[mimugmail]

Puh, kein Plan, Neustart?

[tt33tt]

Nach der kompletten Deaktivierung von HTTPS auf der Weboberfläche Funktioniert der Firefox und Chrome nun mit der automatischen Erkennung. Nach der Reaktivierung geht es wieder nicht mehr.
Der IE 11 kann das weder über automatische Erkennung noch über die direkte Angabe des Skripts. Komisch ist, dass Chrome das schafft, obwohl es die IE-Einstellungen benutzt. IE schafft es nicht.

Notfalls muss ich den Domain Controller mit IIS ausstatten und dann läuft das darüber.

Der Punkt HTTP-Umleitung
" HTTP-Umleitung    Deaktiviere die Umleitungsregel für die Weboberfläche
Wenn dies abgehakt ist, wird der Zugang zur Weboberfläche unabhängig vom konfigurierten hörenden Port immer über Port 80 erlaubt. Haken Sie diese Box an, um diese automatisch hinzugefügte Regel zu deaktivieren." hat bei mir bisher keine Auswirkung gezeigt.