Messages

I see. Thank you.

I don't run HTTPS backends behind Caddy to be honest. But I do behind HAproxy.

However, I'm wondering, what's the particular meaning of removing the host header or overriding it with something else.
The host header is mostly used differentiator to select the proper virtual server, when running multiple websites on a single backend. The client is sending the proper header value. So why does Caddy change it?

HAproxy doesn't behave like that.

header_up Host {host}

Strange. This header already exists in the clients request and Caddy shouldn't remove it by default.

And also HAproxy doen't add it without specific settings.

Firewall -> Rules -> LAN -> top level rule to direct _vpn_group too the OpenVPN gateway

Note that this redirects any traffic to the VPN gateway.

If the VM is configured to use OPNsense for DNS resolution, this leads into failing DNS.

Best practice for VPN gateway rules is to limit its destination to public address ranges only.
You can achieve this by creating an network alias and add all RFC 1918 networks to it. Then specify this alias in the policy routing rule as destination and check "Invert Destination".

To allow internal access, e.g. DNS, you need additional rules of course.

And obviously only OpenVPN has reasonable routing features for road warriors.

My battery in iphone working well good :) hahah
So what the solution about that case ??

But possibly your iPhone halts the VPN app to spare battery.
If this is the case, there should be an option to disable battery management for this app.

Hallo

Ziel:**
Die Verbindung soll so umgesetzt werden, dass die Firewall als Absender erscheint, damit der interne Zielhost 10.10.11.5 das VPN-Netz 172.17.30.0/24 nicht kennen bzw. nicht routen muss.

Früher reichte dafür eine einfache Destination-NAT-Regel. Das scheint in dieser Form nicht mehr zu funktionieren.

Nein. Destination NAT macht und machte keine Umsetzung der Source-Adresse. Dazu war eine Outbound NAT Regel nötig.

Also nach dem du sowohl Source- als auch Distination NAT machen möchtest benötigst du zwei Regeln, heute wie damals.
- Destination NAT am OpenVPN Interface
- Source NAT am Interface, an dem die Pakete zum Zielhost rausgehen.

Eine Firewall-Regel braucht es auch. Dafür gibt es nach wie vor im Destination NAT die Möglichkeit, im Destination NAT eine erstellen zu lassen, ist aber nicht mehr Default, oder einfach "pass" zu setzen.

Fürs korrekte Routing sollte es allerdings reichen, dass der Zielhost die OPNsense als Standardgateway nutzt.
Die Source-NAT Regel sollte dann nicht nötig sein.

Grüße

I wanted to switch my reverse proxy from HAProxy to Caddy over the weekend. It worked fine at first. Then yesterday I noticed that logging in to Synology DSM (username/password/Yubikey as a security key) no longer works. The login is 'interrupted' – but not completely. This means that DSM registers it as an incorrect login.

Did you enable the X-Forwarded-For header in the advanced settings?

Do you proxying the whole domain or a virtual directory?

Is Caddy using the same protocol (http / https) as HAproxy to access the backend?

Evtl. müsste ich die MASTER Node an eine abschaltbare Steckdose setzen, wenn ich dann vom Peer alle 5 Minuten einen SSH auf die HA Schnittstelle mache und das nicht funktioniert: Kopf ab (STONITH)

Aber SSH hätte wahrscheinlich im obigen Fall auch noch funktioniert.

HA in OPNsense basiert auf CARP, und das ist eben ein Netzwerkprotokoll.

Du kannst natürlich Monit konfigurieren, um verschiedene Parameter zu überwachen. Aber dazu müsste man erst wissen, welche möglichen Ursachen es für ein Versagen geben könnte.
Am einfachsten wäre es vielleicht, das System-Log auf bestimmte Fehler-Logs zu monitoren. Vermutlich findet sich da alles Relavante als Fehlereintrag.
Als Aktion könntest du dann das Abschalten eines CARP-Interface festlegen, was ein Failover auslösen müsste.

Wieso gehen die Anfragen jetzt dennoch über Port 53 raus? Woher weiß ich denn jetzt, ob die DNS requests verschlüsselt sind?

Anfragen woher? Von OPNsense selbst oder von intenen Clients?

Um sicher zu gehen, dass Unbound verwendet wird, leite ich per Port Forwarding Regel sämtliche DNS Anfrage auf Unbound um.
Würde ein Client dennoch einen öffentlichen DNS abfragen, bekäme er die Antwort von Unbound und würde es nicht mal bemerken.

Wenn alles korrekt konfiguriert ist, sollte das dann nicht mehr nötig sein, aber um seine Paranoia zu stillen, kann man noch am WAN eine Floating Regel für die Direction out setzen, die sämtlichen ausgehende Verbindungen auf Port 53 blockiert (Hatte ich auch so konfiguriert).
Voraussetzung ist, dass auch OPNsense Unbound verwendet.

Am Rande bemerkt, gehen nicht alle DNS-Anfrage per 853 raus - beispielsweise die erste nach der IP des DoT-Servers nicht - aus Gründen

Die Server IP fragt Unbound auf OPNsense ab?? Man gibt die IP doch schon in der Konfiguration vor.

Ich hatte eine solche Konfiguration auf pfSense. Da hatte ich eben alle ausgehenden Verbindungen auf Port 53 blockiert - soweit ich mich erinnern kann, ausnahmslos.
Und nachdem in OPNsense ebenso die Server IP gefordert ist, denke ich nicht, dass hier was aufgelöst werden muss.
Den CN kann man angeben, damit der Server per TLS verifiziert werden kann. Der Eintrag ist aber optional, doch empfohlen, wenn ein öffentlicher Server verwendet wird.

Unbound ist auf Port 53 aktiv.

Dann ist Unbound wohl der DNS, der die Geräte bedient. Und diesen möchtest du vermutlich ändern.

Unbound nutzt standardmäßig Root-DNS-Server zur Auflösung. Wenn du aber jene verwenden möchtest, die in den General Settings gesetzt sind, musst du in Serivces: Unbound DNS: Query Forwarding oben bei "Use System Nameservers" einen Haken setzen und die Einstellung speichern.

Wenn man jetzt noch bestimmte URLs sperren kann, dann denke ich sollte er auch das machen was ein HAProxy kann, hoffe ich zumindest.
Damit meine ich z.B. wie bei Wordpress, dasn /wp-admin nicht von außen aufrufbar ist.

Ja, habe ich auch konfiguriert.
Du kannst ACLs anlegen mit erlaubten IPs od. Subnetzen und dann einen Handler für den Pfad /wp-admin, der diese ACL anwendet.

Aber wenn der HAProxy sich Sache sicherer macht, dann muss ich mich damit mal beschäftigen.

Ich denke nicht bis auf das Verbindungslimit, was eine Überlastung des Webservers durch DDoS Angriffe verhindern kann.

Was ich noch nicht weiß, ist wie ich in der OPNsense einstelle, dass der Zugriff auf interne Ressourcen den selben Weg geht, als wenn der Zugriff von Außen kommt.

In dem du am besten die betroffenen Domänen nicht im internen DNS überschreibst, wie schon oben geschrieben.
Dann wird die Domäne entsprechend dem öffentlichen DNS aufgelöst und das Paket wird zur WAN IP geschickt. Wenn es der Reverse-Proxy laut seiner Konfiguration auf einen bestimmten internen Port weiterleitet, macht er das natürlich auch für Zugriffe von intern.

Es scheint da eine gewisse Abneigung zu bestehen, von intern auf die WAN IP zuzugreifen.. Besonderheiten hier gibt es aber nur normalem Port Forwarding. Bei Einsatz eines Reverse-Proxy funktioniert das völlig normal. Lediglich die FW Regeln müssen den Zugriff auf die WAN IP erlauben.
Und ja, die Firewall kann grundsätzlich von allen Interfaces aus mit all ihren IPs angesprochen werden, wie jeder andere Rechner auch.

Also es ist außer Frage, das der Zugriff über VPN der sicherste Weg ist.

Nicht der ganzen Welt Zugang zu gewähren ist natürlich sicherer, aber wenn Dienste von außen od. von Leuten, denen man keine VPN zumutet, erreichbar sein sollen, muss eben ein Kompromiss eingegangen werden. Netzwerksegmentierung nach Sicherheitsbereichen ist dann schon zu empfehlen. Wenn das Netzwerk ohnehin virtualisiert ist, ist das kein großer Aufwand.

Du kannst aber auch VPN und Reverse-Proxy kombinieren. Hab ich auch so im Einsatz. Zu gewissen Backends bzw. gewissen URL wird nur Zugriff via VPN oder von internen Quellen erlaubt.

Der Reverse Proxy soll einfach auch noch eine zusätzliche Sicherheit bieten

Das kann er gewiss, allerdings braucht es eine tiefer gehende Konfiguration.
In der Grundkonfiguration leitet der Reverse-Proxy sämtliche Anfragen and das Backend weiter, ohne irgendetwas zu filtern. Caddy hat nicht einmal ein Verbindungslimit. So bietet das keinen tatsächlichen Sicherheitsgewinn.

Es kommt also darauf an, wieweit du bereit bist, dich in die Sache zu vertiefen.
Du kannst den Reverse-Proxy bspw. auch mit Crodsec verbinden, so dass es die Logs bekommt und Angriffe erkennen und blocken kann.

Ist der HAProxy besser als der Caddy?

HAproxy bietet umfangreichere Funktionen. Ob das ein Segen oder Fluch ist, hängt vom beabsichtigten Einsatzzweck ab. Es bereitet auch deutlich mehr Aufwand, HAproxy zu konfigurieren.

Caddy ist da rascher eingerichtet. Er bringt bspw. auch gleich einen integrierten ACME Client mit, der SSL-Zertifikate für die definierten Domönen von LE zieht, wenn man das möchte.
Die nötigsten Funktionen eines Reverse-Proxy bietet Caddy auch wie ACL, Authentifizierung, HTTP Header-Manipulation, URL-Umleitung.

Ich verwende beide, HAproxy in einer komplexeren Umgebung, Caddy zuhause.

Nun ja, der sorgt dafür, dass die internen Dienste (unabhängig von deren IP / Port) über die externe IP basierend auf dem DNS-Namen erreichbar sind.

Und eben die Sinnhaftigkeit dessen habe ich hinterfragt.

Sämtliche oben aufgezählten Dienste verwenden standardmäßig verschiedene und eindeutige Ports. Je nach Client braucht der nicht angegeben zu werden oder doch.
Wird er nicht angegeben könnte der konkrete Service über SNI oder HTTP-Header ermittelt werden. Hab ich auch oben geschrieben, damit der TO selbst beurteilen kann, ob das für ihn Sinn macht.
Für nur einen Webserver, einen Mailserver und 3CX sehe ich aber keine unbedingte Notwendigkeit.

Intern werden die Dienste über den DNS-Server der OPNSense mit ihren privaten IPs aufgelöst und extern zeigen deren DNS-Namen auf die WAN-IP, wo der HA-Proxy dann das weiterleiten an die interne Adresse übernimmt.

Pakete weiterleiten kann OPNsense auch nativ, und für mehr verwendest du HAproxy offenbar nicht, weil interne Verbindungen umgehen ihn ja. So hat er nur für externe Verbindungen Nutzen.
Ich vermute aber, du hast mehrere Webserver auf verschiedenen internen Hosts. Dann macht ist ein Reverse-Proxy natürlich eine Lösung.

Du könntest in Erwägung ziehen, die betroffenen Hosts aus dem internen DNS raus zu schmeißen und HAproxy auch für interne Verbindungen zu nutzen. So kommst du bspw. in den Genuss der öffentlichen SSL Zertifikate, ohne sie auf das Backend kopieren zu müssen.
Auch weitere Funktionen (bspw. URL-Rewrites) könnte HAproxy dann übernehmen, die gleichermaßen für externe und interne Verbindungen gelten. Auch Filter kann man einbauen, die bspw. Zugriff auf bestimmte Zielpfade nur internen Quellen erlauben.
Aber das sollte in diesem Thread eigentlich nicht behandelt werden.

Jetzt stehen aber ein paar Umstellungen an und es gibt Überlegungen verschiedene Dienste direkt online verfügbar zu machen.

Überlegungen?
Die Frage sollte sein, ob es eine Notwendigkeit dafür gibt.

Falls ja, ist Segmentieren ein guter Weg, um das Angriffspotential zu verringern, weil es die VMs von anderen eventuell kompromittierten je nach FW-Regeln schützen kann.
Also Nextcloud und Mailcow in eigene Netzwerksegmente zu setzen, halte ich schon für sinnvoll.

Aber inwiefern dir hierbei Caddy oder ein anderer Reverse-Proxy helfen kann, ist mit nicht klar.
Caddy kann eine externe IP:Port-Kombination auf unterschiedliche interne weiterleiten, entweder auf Basis von HTTP-Analysen oder SNI, und ggf. kann er Zugriffe auch einschränken. Aber bei dir nutzt anscheinend ohnehin jeder Service eine anderen interne IP.
Einzig die Anzahl der Verbindungen auf die Backends kann er einschränken, um sie vor DDoS-Angriffen zu schützen.

So maybe it's time to update your OPNsense.