Probleme mit Subdomains in lokalem Netz in Verbindung mit Wireguard

Started by theblackraven, April 19, 2021, 05:49:03 PM

Previous topic - Next topic
Hi,

ich versuche gerade ein abgeschottetes Netzwerk in einer virtuellen Umgebung zu realisieren, welche von außen nur über Wireguard zu erreichen ist.
Sowohl OPNsense als auch die virtuellen Maschinen befinden sich alle auf einem Server, auf dem Proxmox installiert ist.

Das meiste davon habe ich auch schon realisiert bekommen.
Allerdings habe ich gerade noch folgendes Problem:
Ich würde gerne meine Webservices, welche in einer der virtuellen Maschinen laufen, gerne über Subdomains ansprechen.

Ich habe OPNsense auf meinem Proxmox Server als virtuelle Maschine installiert.

Der Server sitzt hinter meiner Fritzbox mit dynamischer IP und ich missbrauche MyFritz um die Fritzbox auch immer erreichen zu können.
Dadurch ist die Fritzbox über eine kryptische Subdomain immer zu erreichen. Z.B. ttps://dsafdsafdsaffd54875.myfritz.net
Bei der Fritzbox habe ich die Portweiterleitung für Wireguard eingerichtet, welche den Port auf das WAN Interface von OPNsense weiterleitet.

Für OPNsense habe ich zwei Netzwerkinterfaces unter Proxmox eingerichtet:
VMBR0 für das WAN Interface
VMBR3 für das LAN  Interface

VMBR0 hat bei Proxmox CIDR 192.168.1.129/24 und als Gateway die Fritzbox.
VMBR3 hat bei Proxmox die CIDR 192.168.4.1/24 und keinen Gateway.

Der prinzipielle Verbindungsweg ist daher ungefähr so:
Internet----->Fritzbox----->Proxmox---->OPNSense

Meine Virtuelle Maschinen sollen später nur über Wireguard von außen erreichbar sein. Die virtuellen Maschinen haben aber Zugang zur Außenwelt.

Aus diesem Grund haben diese alle nur die VMBR3 als Netzwerkinterface zugewiesen bekommen.

An der VMBR3 (Laninterface von OPNsense) hängt auch eine virtuelle Maschine mit Docker.

Bisher habe ich es hinbekommen, dass ich mich per Wireguard einwählen kann und auch die Namespaces von OPNsense sehe.
Ich will weiterhin noch Zugriff auf mein lokales Netzwerk haben. Deshalb sollen nur bestimmte IP-Bereiche über das Wireguard Interface laufen. Das scheint auch alles wie gewollt zu funktionieren.

Meine Wireguard Clientconfig sieht so aus:

[Interface]
PrivateKey = privatkey
Address = 10.8.0.2/32
DNS = 192.168.4.2

[Peer]
PublicKey = pubkey
AllowedIPs = 10.8.0.0/24, 192.168.4.0/24
Endpoint = namenskette.myfritz.net:port


Die ganzen Regeln habe ich auch so eingestellt, dass ich vom WG Net in das Lan Net komme.
Dazu bin ich nach folgender Anleitung vorgegangen: https://docs.opnsense.org/manual/how-tos/wireguard-client.html


Arbeitsplatz--->Wireguardtunnel--->Internet----->Fritzbox------>Proxmoxhost---->OPNSense---->WG-Net--->Lan---Virtuelle-Maschine mit Docker.

Allerdings will ich nun meine verschiedenen Webservices, welcher in einem Dockercontainer in der virtuellen Maschine laufen, über Subdomains ansprechen.

Dafür habe ich bei OPNsense unter General->Settings den Domainnamen auf opnsense.local eingestellt.
Der Hostname meiner virtuellen Maschine lautet: docker.

Um das ganze zu realisieren habe ich Unbound aktiviert und ich erreiche die virutelle Maschine nun auch über docker.opnsense.local

Unter Docker laufen mehrere Webservices, welche über einen zusätzlichen Dockercontainer mittels reverse-proxy über die subdomains erreichen will.
Dafür benutze ich folgendes Image: https://hub.docker.com/r/jwilder/nginx-proxy

Die Webservices können alle nur per HTTP erreicht werden.

Um die Webservices nun über ihre Subdomains zu erreichen, habe ich bei Unbound DNS Overides hinzugefügt, wie z.B.: gitea.opnsense.local --> 192.168.4.101 (Ip von der virtuellen Maschine mit den Webservices)

Dies funktioniert tatsächlich auch. Allerdings nur per HTTP.

Allerdings will ich den Reverseproxy des Dockercontainers auch dazu verwenden, dass bis hier hin https verwendet wird. Auch im lokalen Netzwerk hätte ich gerne eine verschlüsselte Übertragung.
Dafür habe ich zusätzlich diesen Container installiert: https://github.com/sebastienheyd/docker-self-signed-proxy-companion

Ich weiß, dass selbst signierte Zertifikate nicht genutzt werden sollten. Allerdings fliegt Letsencrypt und Co raus, da die virtuellen Maschinen von außen ja nicht erreicht werden sollen.

Die Zertifikate etc. werden auch für die einzelnen Webservices angelegt, allerdings wird meine Verbindungsanfrage abgewiesen.
Da ich mich mit HTTPS etc. nicht auskenne, weiß ich nicht wo der Fehler liegt. Könnte dies auch durch OPNsense selbst kommen, da Unbound DNS Overrides für https nicht ausreichen?

Müsste ich für diese Vorhaben auch in OPNsense einen reverse-proxy einrichten ?

Ich muss dazu sagen, dass ich kompletter Neueinsteiger in OPNSense bin und auch mich mit Webservern allgemein nur bedingt auskenne.
Zudem wäre meine Frage auch, ob der prinzipielle Aufbau für eine sichere Verbindung und eine abgeschottetes Netzwerk sinnvoll ist.

Zusätzlich hätte noch noch folgende Frage:
Wie muss die Firewall Regel aussehen, das ich vom LAN-Interface von OPNSense nur öffentliche Adressen über das WAN interface erreichen kann und nicht meine andere lokalen Adressen von VMBR0 ?


Ich danke euch schon mal für eure Unterstützung

Achso,
Ziel ist es ein dezentralisiertes Firmennetzwerk aufzubauen, welche nur über Wireguard zu erreichen ist.
Der Server soll später mal auf einen Rootserver, ebenfalls mit Proxmox umgezogen werden.

Zum testen läuft dies allerdings alles erst mal lokal.

Zum https Thema.

Wenn du getrennte DNS Namen im Unbound überschreibst und auf deine passenden Server legst funktioniert auch https.
Dem DNS ist egal welchen Port du am Ende ansprichst, einzig die Regeln für Port 443/https müssen da sein (so wie für Port 8ß/http).

Deine Verbindung wird wahrscheinlich abgelehnt da dein Client dem Selbstsignierten Zertifikat nicht traut.
Entweder du kommst mit solchen Meldungen klar und drückst immer auf "weiter" oder "dennoch Verbinden", alternativ installierst du das Zertifikat auf allen CLients (händisch oder per PKI, etc.).

Den HAProxy würdest du in dem Fall verwenden um z.B. die Zertifikate zentral zu hinterlegen. Wäre bei LetsEncrypt ganz praktisch. Nur die OPNsense ist für LetsEncrypt Zertifikate aus dem Internet erreichbar, der HaProxy sorgt dann für ordentliche https Anfragen mit Vertrauenswürdigen Zertifikaten, der Traffic bleibt aber lokal und geht nicht über das Internet.
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support

Ok, danke für die Hilfe.
Es lag an dem docker revers proxy. Mit dem traefik-docker-image funktioniert es nun.

Allerdings finde ich keine Lösung dafür, wie ich zertifizierte SSL Zertifikate ohne erhebliche Kosten für meine lokale Domains erstellen kann. Benutze ich letsencrypt, dann sind die Zertifikate ja für meine .de domain ausgestellt. Zudem muss ich ja die Zertifikate immer wieder erneuern. Dafür müsste ich ja dann auch den Port 80 zu meiner virtuellen Docker-Maschine aus dem Web freigeben. Aber genau das will ich ja gerade nicht...

Habe schon das halbe Internet leergesucht.

Ich will doch eigentlich nur erreichen, dass auch in meinem internen Netzwerk eine verschlüsselte Datenübertragung zu den Webservices möglich ist. Also ein reines Intranet mit verschlüsselter Datenübertragung.

Ich finde es irgendwie nicht ganz zu Ende gedacht, dass eine verschlüsselte Datenübertragung an eine CA gebunden ist oder man keine Möglichkeit hat, diesen selbst erstellten Zertifikaten unter allen Systemen dauerhaft (mit einfachen mitteln) zu vertrauen.

Praktisch passiert in meinen Augen gerade folgendes, sofern das notwendige Geld fehlt:

1.
Werden selbst signierte Zertifikate eingesetzt, dann werden Sicherheitswarnungen irgendwann ignoriert. Wie oft habe ich das schon gehört: Ja einfach das Sicherheitsrisiko bestätigen. Das führt dazu, dass dies auch bei einer potentiellen Gefahr ignoriert wird.

2.
Es wird einfach auf https verzichtet.




Quote from: theblackraven on May 11, 2021, 04:01:16 PM
Ok, danke für die Hilfe.
Es lag an dem docker revers proxy. Mit dem traefik-docker-image funktioniert es nun.

Allerdings finde ich keine Lösung dafür, wie ich zertifizierte SSL Zertifikate ohne erhebliche Kosten für meine lokale Domains erstellen kann. Benutze ich letsencrypt, dann sind die Zertifikate ja für meine .de domain ausgestellt. Zudem muss ich ja die Zertifikate immer wieder erneuern. Dafür müsste ich ja dann auch den Port 80 zu meiner virtuellen Docker-Maschine aus dem Web freigeben. Aber genau das will ich ja gerade nicht...

Habe schon das halbe Internet leergesucht.

Ich will doch eigentlich nur erreichen, dass auch in meinem internen Netzwerk eine verschlüsselte Datenübertragung zu den Webservices möglich ist. Also ein reines Intranet mit verschlüsselter Datenübertragung.

Ich finde es irgendwie nicht ganz zu Ende gedacht, dass eine verschlüsselte Datenübertragung an eine CA gebunden ist oder man keine Möglichkeit hat, diesen selbst erstellten Zertifikaten unter allen Systemen dauerhaft (mit einfachen mitteln) zu vertrauen.

Praktisch passiert in meinen Augen gerade folgendes, sofern das notwendige Geld fehlt:

1.
Werden selbst signierte Zertifikate eingesetzt, dann werden Sicherheitswarnungen irgendwann ignoriert. Wie oft habe ich das schon gehört: Ja einfach das Sicherheitsrisiko bestätigen. Das führt dazu, dass dies auch bei einer potentiellen Gefahr ignoriert wird.

2.
Es wird einfach auf https verzichtet.

Vertrauenswürde Zertifikate gehen also nur mit einer public Domain (de, com, org,...) oder selbsignierte wo du diese zentral im Netzwerk verteilst (PKI oder auch Gruppenrichtlinien in einer MS-Domäne)

An deiner Stelle würde ich SplitDNS verwenden. So werden intern z.B. cloud.xyz.de auf die lokale IP aufgelöst, dort kannst du aber trotzdem ein LetsEncrypt Zertifikat hinterlegen, da der Name auf dem Zertifikat passt
Und das in Kombination mit dem HAProxy hast du auch nur eine Stelle wo die Zertifikate verwaltet werden
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support

Hi,

lfirewall1243 hat mir die Worte größtenteils aus dem Mund genommmen.
Einziger zusätzlicher Hinweis ist, die Let's Encrypt Zertifikate mit dem DNS-01 Challenge zu erstellen. Dann brauchst du auch den Port 80 nicht freigeben.

Quote from: lfirewall1243 on May 11, 2021, 04:06:13 PM
Quote from: theblackraven on May 11, 2021, 04:01:16 PM
Ok, danke für die Hilfe.
Es lag an dem docker revers proxy. Mit dem traefik-docker-image funktioniert es nun.

Allerdings finde ich keine Lösung dafür, wie ich zertifizierte SSL Zertifikate ohne erhebliche Kosten für meine lokale Domains erstellen kann. Benutze ich letsencrypt, dann sind die Zertifikate ja für meine .de domain ausgestellt. Zudem muss ich ja die Zertifikate immer wieder erneuern. Dafür müsste ich ja dann auch den Port 80 zu meiner virtuellen Docker-Maschine aus dem Web freigeben. Aber genau das will ich ja gerade nicht...

Habe schon das halbe Internet leergesucht.

Ich will doch eigentlich nur erreichen, dass auch in meinem internen Netzwerk eine verschlüsselte Datenübertragung zu den Webservices möglich ist. Also ein reines Intranet mit verschlüsselter Datenübertragung.

Ich finde es irgendwie nicht ganz zu Ende gedacht, dass eine verschlüsselte Datenübertragung an eine CA gebunden ist oder man keine Möglichkeit hat, diesen selbst erstellten Zertifikaten unter allen Systemen dauerhaft (mit einfachen mitteln) zu vertrauen.

Praktisch passiert in meinen Augen gerade folgendes, sofern das notwendige Geld fehlt:

1.
Werden selbst signierte Zertifikate eingesetzt, dann werden Sicherheitswarnungen irgendwann ignoriert. Wie oft habe ich das schon gehört: Ja einfach das Sicherheitsrisiko bestätigen. Das führt dazu, dass dies auch bei einer potentiellen Gefahr ignoriert wird.

2.
Es wird einfach auf https verzichtet.

Vertrauenswürde Zertifikate gehen also nur mit einer public Domain (de, com, org,...) oder selbsignierte wo du diese zentral im Netzwerk verteilst (PKI oder auch Gruppenrichtlinien in einer MS-Domäne)

An deiner Stelle würde ich SplitDNS verwenden. So werden intern z.B. cloud.xyz.de auf die lokale IP aufgelöst, dort kannst du aber trotzdem ein LetsEncrypt Zertifikat hinterlegen, da der Name auf dem Zertifikat passt
Und das in Kombination mit dem HAProxy hast du auch nur eine Stelle wo die Zertifikate verwaltet werden

Wenn ich das richtig verstehe (kenne mich einfach zu wenig mit DNS etc. aus), dann brauche ich den HAProxy nur für die letsencrypt Zertifikate, damit ich diese bekomme und auffrische. Der Port 80 muss von meiner Fritzbox zum WAN-Port von OPNSense weitergeleitet werden, damit ich über http-01 die Zertifkate erhalte.

Die Zertifikate muss ich dann zu meinen Webapps in meiner virtuellen Maschine kopieren. Kann man dies mit OPNSense irgendwie automatisieren, zb. mit scp?

Mittels Ubound kann ich dann mittels Override die Anfragen, welche z.B. an webapp1.example.com gehen an die virtuelle Maschine umleiten?


Würde es so machen

Du richtest den HAProxy als vollwertigen Dienst mit Backends ein. Wie hier:
https://docs.opnsense.org/manual/how-tos/haproxy.html

Die DNS Einträge überschreibst du mit der IP des HAProxys. Somit gehen alle deine Clients an den HAProxy welcher die Zertifikate breitstellt (evtl. noch mit Authentifizierung wenn du vom Internet kommst) diese Leitet den Traffic dann selbständig an deine Dienste weiter, da haben die Clients nichts mehr mit zutun, die sehen nurnoch den HAProxy.


Vorteil: Du brauchst deine ganzen Zertifikate nicht irgendwie ausrollen und hast alles an einer zentralen Stelle
und kannst zudem noch besser kontrollieren was in deinem Netzwerk so abgeht
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support

Hi,

Quote from: theblackraven on May 12, 2021, 12:03:21 AM

Wenn ich das richtig verstehe (kenne mich einfach zu wenig mit DNS etc. aus), dann brauche ich den HAProxy nur für die letsencrypt Zertifikate, damit ich diese bekomme und auffrische.

Nein. Für das Let's Encrypt Zertifikat brauchst du das Let's Encrypt Plugin. Und wenn ich dich richtig verstehe, willst du Port 80 nicht verwenden, dann solltest du auch die HAProxy-Integration des Let's Encrypt Plugins nicht verwenden. Nur den HAProxy automatisch neu starten, wenn ein neues Zertifikat da ist, falls du ihn verwendest.

Quote from: theblackraven on May 12, 2021, 12:03:21 AM
Der Port 80 muss von meiner Fritzbox zum WAN-Port von OPNSense weitergeleitet werden, damit ich über http-01 die Zertifkate erhalte.

Ja, wenn du die HTTP-01 Challenge verwendest. Ausserdem mußt du noch auf dem WAN-Port eine Regel hinzufügen, damit Port 80 akzeptiert wird. Mit dem HTTP-01 Challenge musst du aber einen öffentlich erreichbaren Namen verwenden. Sprich docker.beispiel.de IN CNAME dsafdsafdsaffd54875.myfritz.net in deinem öffentlichen DNS-Server eintragen, wenn deine Domäne beispiel.de ist. Dies dann für jede Subdomäne machen.
Wenn du Port 80 nicht freigeben willst bleibt nur die DNS-01 Challenge.
Im Nameserver musst du in allen Fällen was eintragen, wenn du das mit den Subdomänen verwenden willst.

Quote from: theblackraven on May 12, 2021, 12:03:21 AM
Die Zertifikate muss ich dann zu meinen Webapps in meiner virtuellen Maschine kopieren. Kann man dies mit OPNSense irgendwie automatisieren, zb. mit scp?

Das gibt es als Automation in dem Let's Encrpyt Plugin.
Alternativ verwendest du den HAProxy als TLS-Entpoint wie von lfirewall1243 und sparst dir die ganze Rumkopiererei.