Messages

It turns out you are right again.

I have configured my reverse proxy with Basic Authentication:

Code Select Expand

   <Proxy *>
       Order deny,allow
       Allow from all
       Authtype Basic
       Authname "Password Required"
       AuthUserFile /etc/apache2/.htpasswd
       Require valid-user
#       SetEnv proxy-chain-auth
   </Proxy>


So i gues the problem is that Authentication headers are passed to OpnSense.
Once I remove Basic Authentication on the Reverse Proxy everything works just fine.

Can anybody give me a hint on how to not passing the Authorization header ?

Thnx for your reply !

I checked with browser console and it gives the following error:

Code Select Expand

scheme
https
host
reverse.domain.com
filename
/api/core/menu/search/
_
16545493428251
Adresse
217.154.123.111:443
Status
401
Unauthorized
VersionHTTP/1.1
Übertragen239 B (48 B Größe)
Referrer Policysame-origin

menu.search : Unauthorized

So I guess this means that you r right and API calls are blocked.
I cannot see anything unnormal in the logs of the Reverse Proxy.

Is OPNSense blocking these calls ?
What can I do to prevent it from doing so ?

Hi,

I am using OPNsense 21.7.7-amd64 in a Lab Enviroment.
to make the Web GUI available from outside I have set up an external reverse Proxy to connect to the GUI.

I have set Alternate Hostnames accordingly and I am able to log into the GUI.
Strange thing is ... I am missing some parts of the configuration altough I am logged in with root.

e.g. Settings for the ACME client are missing: Plugin is disabled, no account is defined, etc.

If I log in with the same user locally (not using the external reverse proxy) ... I can see the full config Plugin is enabled, account is set up, etc.

I am pretty new to OpnSense .... Can anybody give me a hint ?

Hallo Zusammen,

meine Frage hat sich nun aufgeklärt.
Offensichtlich ist es so, dass OPNSense das Paket rejected, wenn der Service (Ziel) für den die Regel konfiguriert ist, nicht erreichbar ist.
Das bedeutet, im LOG erscheint die Meldung, dass das Paket abgewiesen wurde, obwohl die Regel (pass) richtig konfiguriert ist. Dieses Verhalten kenne ich von anderen Firewalls so nicht.
In meinem Fall war der ReverseProxy nicht gestartet und die Pakete wurden als rejected gelogged... als matched rule wurde die "default deny" angegeben (wie gesagt trotz existierender und richtig konfigurierter "pass" Regel)
Ich finde dieses Verhalten ziemlich verwirrend ...
Ist dieses VErhalten so bekannt ?
Passiert das auch, wenn der Service nicht direkt auf der OPNSense liegt, sondern auf einem Host in der DMZ ?

UDP statt TCP bei HTTP als Protokoll? Das würde mich doch stark wundern. HTTPS - ja OK. Da wird inzwischen einiges via QUIC via 443/udp versucht, aber selbst dann ist der Aufbau eigentlich tcp.

Ansonsten scheint mir der Punkt von Patrick plausibler. In deinem Debug Shot steht ne externe public IP6 drin. Du nutzt WAN address - da ist es aber abhängig davon, was dein WAN als IP6 definiert hat. Und je nach Konfiguration kann die dazu noch abweichen. Daher war der Gedanke mit This Firewall (self) gar nicht so abwegig.

Aber wenn du schreibst du hast DSlite - hast du überhaupt eine statische IP6 oder ändert sichd as Prefix nicht eh alle Nase lang? Dann kannst du da recht viel reinschreiben, aber die IP6 wird sich ständig ändern.

Cheers

Es handelt sich um einen Anschluss von Unitymedia...
Ich habe das Thema jetzt länger beobachtet und habe schon das Gefühl, dass sich die IPv6 sehr selten ändert ...
von außen greife ich btw. per dynamischem dns zu ...
Wenn sich die IPv6 aktualisieren würde, müsste die Regel mit Destination WanAdress ja trotzdem weiter funktionieren oder ?

Aber ganz abgesehen davon wundert es mich halt, dass das Paket ja offensichtlich tatsächlich bei der Firewall ankommt und dann verworfen wird.. und das sogar wenn ich Destination any einstelle ...
Kann es sein, dass ich unter Firewall --> Rules --> WAN einfach an der falschen Stelle die Regel eintrage ?
Müsste es unter floating sein ? Soetwas hatte ich mal irgendwo gelesen...
Kann sich jemand von euch einen Reim darauf machen, warum das hier nicht funktioniert ?

Schau mal im Dashboard im "Interfaces" Widget nach, was WAN tatsächlich für eine IPv6 Adresse hat. Oft ist die nämlich link local. Dann geht das so mit der Regel nicht sondern Du musst Deine Global Unicast Adresse da explizit reinschreiben.

Guter Hinweis. Vielen Dank leider sehe ich im Dashboard unter WAN  genau die IPv6 Adresse, an die auch das verworfene Paket geht.
Dieses wird also aus dem Internet korrekt zur OpnSense geroutet und erst dort verworfen.
Ich habe daher versucht, die Regel auf Destination "any" zu schalten.
Auch das bringt keinen Effekt... Ich bin da echt ratlos... aber vielleicht verstehe ich die Grundlagen von OpnSense nicht gut genug.

...leider nein.


PS: Äh, doch! Probier mal UDP statt TPC in der FW-Regel...

Angefragt wird von extern gans normales http also tcp port 80.
Der Screenshot besagt ja auch, dass ein TCP Paket mit dem Ziel Port 80 verworfen wird.
Daher erscheint mir der Anratz unwahrscheinlich.
ICh habe trotzdem mal probiert das Protokoll auf any zu stellen ... leider ohne Erfolg :(

Nein.

Korrekt :) Hast du eine Idee, was hier falsch ist ?

Vielleicht besser als Destination "This Firewall".

Hatte ich auch schon probiert. Leider ohne Erfolg :(

Hallo Zusammen,

ich bin seit kurzem auf die OpnSense umgestiegen und habe da eine Situation die ich nicht verstehe.

Ich hänge mit der OpnSense an einem DSLite-Anschluss und möchte via Reverse Proxy auf der OpnSense meinen Webserver aus dem LAN (IPv4) im Internet zur Verfügung stellen.
Der ReverseProxy ist mit nginx bereits aufgesetzt.

Eine entsprechende Regel habe ich unter Firewall -> Rules -> WAN angelegt (vgl. Screenshot1).
Gateway steht auf "default"

Leider werden eingehende Pakete trotzdem geblockt (vgl. Screenshot2)

Vielleicht könnt ihr hier weiter helfen ?