Messages

Ich hatte es als Standardanforderungen angesehen. Normales Reverseproxying auf verschiedene Backends. Einige Services sollen über HTTPS laufen, andere über HTTP. Alle HTTPS Domains sollen Let's Encrypt Zertifikate erhalten.

Etwas verkürzt:

Code Select Expand

https://nc.mydomain.tld  >  Webserver Port 80
https://host.otherdomain.tld  >  Webserver Port 80
https://pv.mydomain.tld  >  PV-Wechselrichter Port 80
http://stream.mydomain.tld/hi  >  Musikserver Port 42287
http://stream.mydomain.tld/lo  >  Musikserver Port 42288

HTTP-Anfragen auf Domains, die HTTPS bereitstellen, sollen automatisch auf HTTPS umgeleitet werden.

Für mich sind das sehr elementare Anforderungen, deren Umsetzung auf keinem Reverse-Proxy eine große Herausforderung sein sollte.

Wie Let's Encrypt mit Caddy funktioniert, ist mir leider noch immer rätselhaft. Das einzige, was die GUI dafür anbietet ist die Mailadresse. Ich frage mich, wie es die CA auswählt.
Daher könnte ich einfach nur versuchen, alle Reverse-Proxy Domains einzurichten. Sollte es nicht klappen, geb ich mein Caddy-Abenteuer eben auf. Es hat mich schon zu viel Zeit gekostet.
HAproxy ist kein Leichtgewicht und die GUI Integration in OPNsense ist fern ab von guter Nachvollziehbarkeit, was die Konfiguration deutlich aufwendiger gestaltet, aber damit habe ich schon wesentlich komplexere Projekte umgesetzt. Da weiß ich nun, was welcher Konfigurationsabschnitt bewirkt.

Caddy braucht kein Acme Client Plugin, es macht Acme selber mit einem eingebauten client (certmagic).

Gelesen hatte ich den Absatz, so verstanden aber nicht. :-/

/well-known wird reserviert, aber wenn du z.B. http domains reverse proxiest, werden alle Pfade durchgereicht. Hier ein beispiel:
https://docs.opnsense.org/manual/how-tos/caddy.html#redirect-acme-http-01-challenge

Eben genau dieses hätte ich gedacht, müsste konfiguriert werden, damit Caddy die HTTP-01 Challenge durchreicht. Und daher hatte ich angenommen, dass er es sonst nicht tut.

Im Grunde benötigt man eigendlich /nie/ das http frontend

Ich nutze jedoch HTTP, bspw.  für Audio-Streams. Muss ich dann nur diese Domains für HTTP konfigurieren und http-Anfragen auf andere Domains werden automatisch auf https umgeleitet?

Das Acme sh script plugin (Also os-acme-client) benutzt PF Anchors um einen upper port in der firewall zu öffnen und darüber die challenge zu machen. Das ist ein anderer mechanismus. Die HTTP01 challenge kann auch über einen anderen port als 80 erfolgen.

Ja, so etwas hatte ich schon vermutet. Jedoch zeigte pcap Port 80 Zugriffe von LE, weswegen ich angenommen hatte, dass Caddy diese handeln müsste.

Ich denke hier werden ein paar Konzepte miteinander vermischt und das ergibt Verwunderung.

Und die hält immer noch an...

Ich muss also ins kalte Wasser springen, auch sämtliche https Domains auf Coddy einrichten und dann schauen, was passiert.

Werden die Zertifikate von Coddy eigentlich auch im Trust Store von OPNsense abgelegt, so dass man dies auch verifizieren kann?

Es gab nun einen Erfolg.

Ich hatte das ACME Client Plugin nicht aktiviert gehabt. Ich hatte gedacht, dass dies für den Testmodus nicht nötig wäre. Ich hatte ACME schon auf zwei anderen OPNsense Instanzen eingerichtet, doch hier wohl erstmalig die Test CA verwendet, was auch gut war. :-/
Muss sagen, das Fehlerbild dieser Misskonfiguration ist aber ziemlich seltsam. Warum da Let's Encrypt keine Antwort bekommt, eine andere Quelle aber schon...?
Und warum der ACME-Client dennoch Let's Encrypt kontaktiert hatte?

Dann hatte ich in meiner Verzweiflung noch für den letzten Test einen Reverse-Proxy Handler mit meinem Backend-Webserver hinzugefügt. Damit hatte ACME auch nicht funktioniert. Ich musste ihn wieder entfernen.
Warum eigentlich? Sollte Caddy nicht den "/.well-known/acme-challenge/" Pfad automatisch umleiten?

Hallo,

auf meiner Heiminstallation von OPNsense habe wollte ich nun Caddy versuchen, weil es hier im Forum vielfach als einfach zu konfigurierender Reverse-Proxy bejubelt wird und meinen Anforderungen hier wohl genügt.
Bislang macht mein primärer Webserver (Apache) den Reverse-Proxy für die wenigen Anfragen, die auf andere Hosts gehen sollen. Und auf diesem läuft auch der ACME-Client. Funktioniert eigentlich alles zu gut, als dass ich mich allzu lange mit Alternativen beschäftige. Aber jetzt ist gerade Zeit und auf der OPNsense wäre das auch vielleicht schöner gelöst.

Mit dem Reverse-Proxy muss aber auch der ACME-Client auf die OPNsense übersiedeln. Doch der Client meldet einen Timeout beim Versuch, ein Zertifikat anzufordern.
Mir auch nicht klar, wie HTTP-01 Challenge zusammen mit Caddy überhaupt funktionieren soll. Dieser bekommt ja die HTTP Anfragen und müsste sie dahin weiterleiten, wo der ACME-Client die Challenge deponiert. Hinweise darauf, dass das auch passiert, konnte ich nicht finden.

Nun der ACME-Client bietet hierfür nur "OPNsense Web Service (automatic port forward)". Anders als das HAproxy Plugin stellt Caddy hier ja kein eigenes Service bereit.
Wie soll das nun funktionieren? Ist hier eine entsprechende Weiterleitung manuell in Caddy zu konfigurieren? Wenn ja, wie?

Im Web konnte ich dazu nichts finden. Ich bin nur mehrfach auf Loblieder gestoßen, dass Caddy alles automatisch machen würde. So dachte ich mir, vielleicht trifft das hier auch zu, ist ja wohl keine seltene Herausforderung, und habe mal versucht, ein Zertifikat anzufordern, aber da kommt nichts.
Der ACME-Client loggt

Code Select Expand

Invalid status. Verification error details: <WAN IP>: Fetching http://host.mydomain.tld/.well-known/acme-challenge/yvQjtqi_r-FZsC6gsmn1QWQx389QJ3OkCFsbJOk0MHU: Timeout during connect (likely firewall problem)Auch im 'debug 2' Level findet sich kein genauerer Anhaltspunkt.
Und Hinweise im Web deuten meist auf ein Firewall-Problem hin, das hier wohl nicht zutrifft. Die Firewall-Regeln habe ich überprüft, Geo-Blocker habe ich deaktiviert und auch den Zugriff von außen getestet.

Letztendlich habe ich während der Zertifikatsanforderung Pcap am WAN laufen lassen. Da sehe ich die Pakete von Let's Encrypt auf meine WAN-IP Port 80 mit der Länge 0, es kommt aber keine Antwort.
Rufe ich selbst den o.g. Pfad von außen auf, sehe ich die Antwortpakete.
Ja, das riecht nach Geo-Blocking. Die Regel hatte ich aber deaktiviert. Die Qell-IP (USA) sollte ohnehin nicht im Alias enthalten sein.
Was ist es dann??
Ich habe das Logging sämtlicher Regeln am WAN aktiviert, ebenso das der Default-Deny Regel und sehe den versuchten Zugriff nicht im Log.
So stellt sich die Frage, was kann die Pakete nach dem Pcap und vor den Filter-Regeln blockieren?

Was mir in diesem Zusammenhang auch ziemlich seltsam erscheint: Caddy beantwortet jede Anfrage auf http://host.mydomain.tld/<egal-was> mit 200.
Die Zusatzfrage wäre also: Kann vielleicht jemand den Sinn dieses erklären?

Vielleicht sollte ich auch noch erwähnen: Caddy funktioniert ansonsten offenbar. Services, die nicht TLS nutzen, habe ich bereits vor Tagen migriert und sind von intern und extern erreichbar. Diese laufen auf Port 80, was mir sagt, dass dieser auf Caddy ankommt. Den zuständigen Reverse-Proxy auf meinem Webserver habe ich deaktiviert.

Hat jemand eine Erklärung für dieses Phänomen?

Grüße

In a port forwarding rule you should state a certain destination address instead of any, WAN address in this case.

However, according to the log, the forwarded traffic is passed out on the MGMT interface. You can sniff the traffic on the interface with the pacekt capture tool (Interfaces > Diagnostic) to investigate this.

Possibly your webserver blocks access from outside of its subnet and you have to allow the access in its firewall.

Ziel ist also:

WAN / in → eingehenden Traffic von Blocklisten-IPs blockieren

LAN (bzw. relevantem Interface) / out → ausgehenden Traffic zu Blocklisten-IPs blockieren

Daher plane ich eine separate Regel mit Ziel = Blocklisten-Alias und Richtung ,,out" auf dem entsprechenden Interface.

Auf den internen Interfaces müsste dafür die Richtung "in" sein, eben aus Sicht der Firewall.

Alternativ kannst du die Regel für Ziel = Blockliste am WAN erstellen, dann mit Richtung "out" oder "any". Falls du das loggen möchtest, würdest du aber hier nur die WAN-IP als Quelle sehen.

Grüße

Hallo,

nicht ganz.

Die Richtung sollte "in" sein.
Die Richtung ist immer aus Sicht der Firewall zu sehen und auf den gesetzten Schnittstellen möchtest eingehenden Traffic mit Ziel Blockliste blockieren.

Alle internen Interfaces. Protokoll: ICMP, Host: 8.8.8.8

Ein anderer Prozess auch OPNsensen fällt mir dazu nicht ein.
Möglicherweise kommt es von intern.
Lass mal ein Packet Capture auf den internen Interface laufen.

Yes that's what I ended up doing last week. I took a /28 out of the DHCP pool for VLAN 900

It's not possible to nat a /24 subnet to /28. This is not going to work at all.

Use a single IP (/32) and type "NAT" as suggested above.

if I wanted to just move remote access from one VLAN to another, I'm not sure why one wouldn't just change the tunnel setup.

For instance, if you were not able to make changes on the remote site.

What are you trying to achieve exactly?

What you are doing here would move remote access from VLAN900 to VLAN1000. You cannot have bidirectional access to both subnets.

If you only need access to the remote site, but not the remote to your site, it should be possible to nat the VLAN1000 to a single unused IP within the 192.168.246.0/24. But to achieve this, you have to use NAT type "NAT" and state the NAT IP with a /32 mask.

If you don't have a VLAN-capable switch to terminate the VLANs, but connect a PC directly to Proxmox, you have to configure the proper VLAN (2) on it's network interface to access OPNsense.

I am running into the same problem as you, but I just read an article where it talks about creating a Linux bridge, assigning an IP, and that becomes the LAN side. My problem with that is that my network has a few vlans, so how do I get those in the OPNsense config also?

If you run OPNsense virtualized you can do the whole VLAN termination on the hypervisor, Proxmox in your case. So you don't need to create any VLAN inside OPNsense, just add a virtual interface to it for each.
Or you do the VLAN termination inside OPNsense. Both is possible.

In both cases you need to enable VLAN awareness on the Proxmox bridges.

It seems there's not much activity here.

Sadly you didn't provide the requested information. So it's hard to help.

You need to add virtual IPs if you have multiple WAN IPs from your ISP or a subnet and want services on OPNsense to listen on multiple of them.
Also if you run two OPNsense in high availability you need to add a VIP of type CARP in this case.

Virtual IPs are just additonal IP to access OPNsense or even services on it.
Type Proxy ARP works a bit different, however. It cannot used for services on OPNsense itself. With this OPNsense just responses ARP requests to this IP. You can use it for forward traffic behind.

On internal interface there are very rara good use cases. That's why I asked for it.
One is if you want to run multiple layer 2 subnets on a singel network interface for instance.