HAProxy auf OPNsense mit Let’s Encrypt Wildcard-Zertifikaten in einem Multi-Homed WireGuard Mesh-VPN

Zugegeben, allein die Überschrift klingt ein wenig aufgeblasen, aber mein Home-Netzwerk ist auch alles andere als 08/15.
Das folgende Tutorial hat mich viel Zeit und Nerven gekostet, bis ich eine für mich akzeptable Lösung hatte. Diese wurde sogar mit einem 100 % A+ Rating bei SSL-Labs belohnt.

Letztendlich dreht sich hier viel um DNS und darum, was an welcher Stelle im Netzwerk wie aufgelöst wird. Lass mich das zu Beginn grafisch darstellen:

… und erläutern:

In einer solchen Multi-Homed-Wireguard-Mesh-Umgebung (vergleiche auch meine Homelab-Netzwerkinfrastruktur) muss man verstehen, wie und unter welchen Bedingungen DNS-Anfragen gestellt und beantwortet werden. Es spielt nämlich eine Rolle, ob ich mich im lokalen Netzwerk befinde – ich schließe das Wireguard-Mesh mit ein – oder ob ich mich direkt im Internet befinde. Je nachdem landet die Anfrage in erster Instanz bei einem anderen DNS-Server. Aber Schritt für Schritt: Wir beginnen im lokalen Netz (unten rechts):

Ein Standard-PC oder Mac bekommt über DHCP sowohl seine IP-Adresse als auch sein Gateway und seinen DNS-Server zugewiesen, zum Beispiel bei der Fritzbox die 192.168.178.100 mit einer CIDR-Subnetzmaske von /24 sowie als Gateway die 192.168.178.1 (das ist die Fritzbox selbst) und als DNS-Server. Letzteres ist standardmäßig auch die 192.168.178.1 (also die Fritzbox). Die Anfrage wird dann an den DNS-Server im Internet weitergeleitet, den die Fritzbox wiederum vom Internet Service Provider (ISP) zugewiesen bekommen hat oder den du manuell unter „Internet” > „Zugangsdaten” > „DNS-Server” eingetragen hast. Aus Gründen von Fallback und Redundanz bin ich hier bei den Standardeinstellungen geblieben. Eine Ausnahme gibt es bei DNS über TLS ganz unten: Hier habe ich meine Adguard-Home-Instanz im Internet eingetragen. Solange diese erreichbar und funktional ist, wird sie von der Fritzbox selbst und nur bei Ausfall wird der vom ISP zugewiesene DNS genutzt.

Aber stopp! Das betrifft nur DNS-Anfragen, die von der Fritzbox selbst kommen. Unter „Heimnetz” > „Netzwerk” > „Netzwerkeinstellungen” > „Erweiterte Netzwerkeinstellungen ändern” > „IPv4” habe ich den lokalen DNS-Server, der den Endgeräten per DHCP mitgeteilt wird, auf 192.168.178.2 geändert. Dort läuft meine lokale Adguard-Home-Instanz innerhalb des LAN/WLAN.

Wie du dort siehst, kannst du den DNS-Server, der im Gastnetz zugewiesen wird, nicht ändern. Das bedeutet, dass DNS-Anfragen, die aus dem Gastnetz an die Fritzbox gesendet werden, auch an die Adguard-DNS-Instanz im Internet gesendet werden. Das ist eine Eigenheit der Fritzbox. Bei Routern anderer Hersteller lässt sich der DNS-Server auch im Gastnetz in der Regel ändern. Aus meiner Sicht ist das jedoch nicht weiter relevant, da ich nicht möchte, dass die Geräte im Gastnetz (bei mir sind das IoT-Geräte) Verbindungen ins Standard-LAN haben. Daher muss ich das Gastnetz nicht weiter betrachten. Alles andere kann ich bei Bedarf auf der Adguard-Home-Instanz im Internet regulieren.

Eine DNS-Anfrage aus dem lokalen Netzwerk geht also an die 192.168.178.2, das ist die lokale Adguard-Home-Instanz. Hier habe ich eine entscheidende benutzerdefinierte Regel angelegt.

||internally.duckdns.org^$client=192.168.0.0/16,dnsrewrite=NOERROR;A;192.168.178.5

Das führt dazu, dass, wenn eine DNS-Anfrage nach *.internally.duckdns.org (stellt hier im Beispiel die Domain meines lokalen Netzwerks dar) aus dem Netzwerk 192.168.0.0/16 kommt, diese nicht an den Upstream-DNS-Server (bei meiner lokalen Adguard-Home-Instanz ist das die Adguard-Home-Instanz im Internet) weitergeleitet wird, sondern mit 192.168.178.5 beantwortet wird. Das ist wiederum die IP-Adresse der OPNsense, auf der HAProxy läuft. Klartext: Wenn ich z. B. https://paperless.internally.duckdns.org in den Browser eingebe, geht die DNS-Anfrage an den lokalen Adguard-Home. Dieser gibt die IP-Adresse der OPNsense zurück, sodass der Browser die Anfrage für paperless.internally.duckdns.org an die OPNsense schickt. Andere Anfragen, die nicht auf .internally.duckdns.org enden, werden an den hinterlegten Upstream-DNS-Server gesendet und von dort iterativ beantwortet.

Soweit ist es im lokalen Netzwerk für Standard-LAN/WLAN und Gastnetz klar. Aber warum gleich 192.168.0.0/16? Das hängt wiederum mit dem Wireguard-Mesh-VPN zusammen. Schauen wir uns eine typische Wireguard-Konfiguration an:

[Interface]
PrivateKey = *************************************=
Address = 192.168.58.1/24
DNS = 192.168.178.2

[Peer]
PublicKey = *****************************************=
PresharedKey = *****************************************=
AllowedIPs = 192.168.178.0/24
Endpoint = *****************.myfritz.net:54250
PersistentKeepalive = 25

Diese besteht immer aus mindestens zwei Abschnitten: Interface und Peer. Ersteres beschreibt die Konfiguration der loaklen Schnittstelle, in diesem Fall also des externen OpenWRT-Routers mit installiertem Wireguard (als Client), letzteres die Gegenstelle. „AllowedIPs” bedeutet, dass alle IP-Pakete, die zu dieser Range gehören, in den WireGuard-Tunnel „gesteckt” werden und auf der anderen Seite (Endpunkt) wieder herauskommen. Da aber auch der DNS-Server 192.168.178.2 in dieser Range ist, werden auch DNS-Anfragen in den Tunnel „gesteckt”. Das heißt, die DNS-Anfrage wird letzten Endes gar nicht vom externen OpenWRT-Router oder dessen konfigurierten DNS-Server beantwortet, sondern vom DNS in meinem Heimnetzwerk. Dieser weiß, dass Anfragen auf *.internally.duckdns.org mit 192.68.178.5 beantwortet werden müssen. Somit kennen alle Geräte im WireGuard-Mesh-VPN den Weg, um Anfragen auf *.internally.duckdns.org korrekt intern aufzulösen. Um den Rest muss sich dann der HAProxy auf der OPNsense kümmern, aber dazu kommen wir noch.

Schauen wir uns nun die mobilen Endgeräte an, wobei ich mich auf Android konzentriere. In den Netzwerkeinstellungen kannst du auch einen DNS-over-TLS-Server eintragen, so wie ich es hier gemacht habe.

Dabei ist jedoch zu beachten, dass diese Einstellungen einen per DHCP zugewiesenen DNS-Server im WLAN überschreiben, d. h., unabhängig davon, welchen DNS-Server der DHCP zuweist, wird die Anfrage in meinem Fall an dns.kwellkorn.de gesendet. Das ist problematisch, da DNS-Anfragen nach *.internally.duckdns.org nicht mehr durch den lokalen Adguard-Home mit der IP-Adresse 192.168.178.5, sondern durch den Adguard-Home im Internet beantwortet werden. Doch wie erfährt der DNS-Server im Internet die passende *.internally.duckdns.org? Ganz einfach: Wenn du DuckDNS korrekt auf deiner Fritzbox unter „Internet” > „Freigaben” > „DynDNS” eingerichtet hast, meldet die Fritzbox ihre öffentliche IP-Adresse ohnehin regelmäßig per DynDNS. Eine Anfrage nach *.internally.duckdns.org wird dann mit der öffentlichen IP-Adresse der Fritzbox beantwortet. Dort wiederum habe ich eine Portweiterleitung auf die OPNsense eingerichtet.

Zusammengefasst werden also bis hierhin alle Anfragen, egal ob sie aus dem LAN, WLAN, dem Gastnetz, dem Wireguard-Mesh oder dem Internet kommen und auf .internally.duckdns.org enden, immer korrekt aufgelöst. HTTP- und HTTPS-Anfragen werden an die OPNsense durchgereicht.

Damit kommen wir zur eigentlichen Konfiguration der OPNsense. Was möchte ich hier erreichen?

1. Anfragen die per HTTP kommen, sollen automatisch auf HTTPS umgeleitet werden
2. sollen die entsprechende Anfrage an den jeweiligen Server und an dessen Anwendungs-Port weitergeleitet werden? Das muss ja nicht immer Port 80 oder 443 sein.

Alle folgenden OPNsense-Screenshots beruhen auf zum Zeitpunkt des Schreibens dieses Tutorials installierten OPNsense Version 25.1.10, ggf. findest du einzelne Einstellungen in einer späteren oder früheren Version an anderer Stelle.

HAProxy-Plugin installieren

Stelle sicher, dass deine OPNsense aktuell ist (System > Firmware > Aktualisierungen). Klicke anschließend auf Erweiterungen und suche im Suchfeld nach „os-.haproxy”. Klicke am Ende der Zeile auf das Pluszeichen.

Let’s Encrypt (ACME) Zertifikat

Gehe zu Dienste > ACME Client > Einstellungen. Nimm dir Zeit und lies die dortige Anleitung. Klicke anschließend auf den Reiter „Einstellungen”. Übernimm die Einstellungen wie im Screenshot dargestellt. Wenn du die Einführungsseiten (ganz unten) deaktivierst, werden auch die Anleitungen ausgeblendet. Wenn dir etwas unklar ist und du mehr Hilfe benötigst, schalte oben rechts die vollständige Hilfe ein.

Als Nächstes solltest du unter „Dienste/ACME-Client/Einstellungen/Zeitplan aktualisieren” einen Zeitpunkt auswählen, zu dem dein Zertifikat erneuert wird. Am besten wählst du eine Zeit aus, in der du erwartungsgemäß keine große Auslastung hast. Ich vermeide gerne die volle Stunde, da das sicherlich viele aus Bequemlichkeit machen.

Als Nächstes gehst du zu Dienste / ACME-Client / Konten, wo du dir ein neues Konto anlegst, sofern du noch keines hast. Name und Beschreibung sind beliebig. Trage bei E-Mail-Adresse deine E-Mail-Adresse ein (kein Dummy). Wähle für das erste Konto die Let’s Encrypt Test CA aus.

Als Nächstes gehst du zu Dienste / ACME Client / Challenge Types, wo du deinen DynDNS-Provider hinterlegst (bei mir ist es DuckDNS; den API-Token erhältst du auf der DuckDNS-Seite ganz oben und hast ihn bereits bei der Konfiguration deiner Fritzbox verwendet).

Zunächst stellen wir über Dienste > ACME-Client > Automation sicher, dass das Plugin neu gestartet wird, wenn ein neues Zertifikat installiert wurde.

Um dir im letzten Schritt über Dienste/ACME Client/Zertifikate ein solches zu besorgen. Achte dabei auf folgende Eintragungen:

• Common Name: Am besten den Namen deiner Wildcard-FQDN.
• ACME-Benutzerkonto: Der unter „Konto” erstellte Eintrag mit deiner E-Mail-Adresse (hier ausgeblendet).
• Challenge Type: deine DuckDNS-Challenge (oder eine vergleichbare).
• „Key Length“: ec:384 (du kannst aber auch bei RSA 4096 Bit bleiben).
• Automation: Der Eintrag für den Neustart des Plugins.

Nachdem du das gespeichert hast, klicke auf den Button „Issue or Renew Certificate“, um den Vorgang zu beschleunigen.

Unter „Dienste/ACME-Client/Protokolldateien/ACME-Log” sollte dann etwas von „…successfully…” stehen.

Wenn dem so ist, gehe erneut auf dein ACME-Client-Konto und wähle statt der Test-CA die Standard-Let’s-Encrypt-CA.

Gehe erneut auf „Zertifikate” und starte manuell den Vorgang „Issue or Renew Certificate” (Button wie oben). Du erhältst ein gültiges Wildcard-Zertifikat für deinen Common Name (hier ausgeblendet), mit dem du weiterarbeiten kannst.

Firewall und virtuelles Interface konfigurieren

Aufgrund der Portweiterleitung in der Fritzbox werden mir Anfragen per HTTP oder HTTPS an das WAN-Interface der OPNsense weitergeleitet. Beachte, dass dafür auch der Standard-Port für den Internetzugriff der WebGUI in der Fritzbox unter „Internet” > „Freigaben” > „Fritz!Box-Dienste” > „TCP-Port für HTTPS” geändert werden musste, da nicht mehrere Anwendungen gleichzeitig auf einer Schnittstelle auf Port 443 lauschen können. Du kannst ihn beispielsweise auf 4443 ändern. Wenn du aus dem Internet darauf zugreifen willst, musst du hinter die URL deiner Fritzbox einen Doppelpunkt, gefolgt von der neuen Portnummer, schreiben, also etwas wie https://****************.myfritz.net:4443 oder wie in meinem Beispiel hier: https://internally.duckdns.org:4443.

Dasselbe machen wir auch auf der OPNsense, denn auch die WebGUI lauscht auf Port 443 und dort soll der HAProxy lauschen. Gehe dazu unter OPNsense zu „System” > „Einstellungen” > „Verwaltung” und ändere dort auch den TCP-Port (zum Beispiel auf 4443). Da du jetzt ein gültiges Wildcard-Zertifikat hast, kannst du dieses auch unter „SSL-Zertifikat” auswählen.

Die OPNsense ist jetzt unter https://<IP>:4443 oder im Beispiel unter https://internally.duckdns.org erreichbar.

Auf der OPNsense soll die WAN-Schnittstelle (in meinem Beispiel 192.168.178.5) auf den Ports 80 und 443 lauschen. Bis jetzt steht dem jedoch die Firewall im Weg. Dazu gehst du zunächst in der OPNsense auf „Firewall” > „Aliase”, klickst auf das + und legst einen neuen Alias wie folgt an:

Dann legst du unter „Firewall/Regeln/WAN” eine neue Firewall-Regel mit folgenden Bedingungen an:

• Protokoll: TCP
• Quelle: jeglich (die Anfragen kommen ja aus dem lokalen Netz oder dem Internet – das schränken wir später noch ein).
• Ziel: WAN-Adresse
• Zielportbereich: HAProxy_Ports (der soeben erstellte Alias).

Dazu arbeiten wir mit einem mehrstufigen Front-/Backend. IP-Pakete für HTTP/HTTPS kommen auf dem WAN-Interface der OPNsense an und werden als Nächstes zu einem virtuellen Interface weitergeleitet. Dort wird eine Trennung vorgenommen zwischen HTTP und HTTPS.

Internet — Stufe 1 —> *.internally.duckdns.org (DuckDNS zu Fritzbox, Portweiterleitung zu OPNsense) — Stufe 2 —> OPNsense + HAProxy + LE — Stufe 3 —> interne Server

Gehe dazu zunächst unter OPNsense > Schnittstellen > Virtuelle IPs > Einstellungen und klicke auf das +. Hinterlege als IP-Alias auf der Schnittstelle Loopback die 127.4.4.3/32 – unsere virtuelle IP für SSL.

HAProxy

Kommen wir zum eigentlichen Punkt: HAProxy. Dazu gelangst du über OPNsense > Dienste > HAProxy. Auch hier kannst du über die Schnellstartanleitung und die einzelnen Einführungsseiten eine Menge lernen. Klicke dich durch die einzelnen Reiter und lies dir das erst einmal in Ruhe durch.

Unter „Dienste” > „HAProxy” > „Einstellungen” > „Dienst” solltest du den Dienst zunächst aktivieren. Vergiss nicht, nach jedem Schritt auf „Speichern” zu klicken.

Hinweis! Du musst immer wieder auf die kleinen Dreiecke/Pfeile rechts neben den Reitern klicken, um die entsprechenden Untermenüs zu öffnen.

Weiter geht es mit „Dienste” > „HAProxy” > „Einstellungen” > „Globale Parameter” (klicke auf den Schalter „Erweiterter Modus”), wo du deine Einstellungen entsprechend anpassen kannst. Die Anzahl der HAProxy-Threads sollte die Anzahl der CPU-Threads deiner OPNsense nicht überschreiten.

Dann zu den Dienste / HAProxy / Einstellungen / Einstellungen / Standardparameter:

Dann legen wir unsere virtuelle IP-Adresse 127.4.4.3 als tatsächlichen Server in der HAProxy-Konfiguration unter „Dienste” > „HAProxy” > „Einstellungen” > „Tatsächliche Server” durch Klick auf „+” an. Name und Beschreibung können frei gewählt werden, wichtig ist die IP unter FQDN oder IP. Außerdem muss die Option „Überprüfen Sie das SSL-Zertifikat” deaktiviert werden.

Dann kannst du auch gleich deinen ersten internen Server anlegen. In diesem Beispiel ist es Paperless, was bei mir ein eigener Docker-Host mit einem Paperless-Container ist. Paperless hört standardmäßig auf Port 8001. Genau das musst du bei all deinen Servern so hinterlegen.

Auf diese Art kannst du auch die Weboberfläche der OPNsense später erreichbar machen. Sie hört jetzt auf Port 4443 und SSL. Wann setzt du den Haken bei SSL und wann nicht? Wenn du beim Web-Zugriff (http://<IP>) auf einen Server die Meldung erhältst, dass das Zertifikat ungültig ist (diese Meldung kennst du sicherlich), dann verlangt der Server nach SSL und genau dann setzt du den Haken. Das Zertifikat musst du dann nicht überprüfen, denn erstens bräuchte der Zielserver ein gültiges Zertifikat (erheblich mehr Aufwand) und zweitens findet deine SSL-Überprüfung/Absicherung bereits mit dem Wildcard-Let’s-Encrypt-Zertifikat statt.

Klicke weiter zu den Backends unter HAProxy > Einstellungen > Virtuelle Dienste > Backend-Pools. Für jeden angelegten tatsächlichen Server benötigst du einen Backend-Pool. Das mag dir im Moment zwar unlogisch erscheinen, aber letztendlich geht es hier um Load Balancing. Auch wenn du für jeden Dienst nur einen Server hast, musst du deinen einzelnen Server mit einem jeweiligen Backend verknüpfen. Im Beispiel sind das jetzt drei anzulegende Backend-Pools: SSL, Paperless und OPNsense. Wichtige Einstellungen im SSL-Backend sind:

• Modus TCP (Layer 4)
• Proxy-Protokoll: Version 2 (der zuvor konfigurierte tatsächliche Server, also 127.4.43, wenn du dich erinnerst).

Bei den Backends der einzelnen Dienste gibt es weniger zu beachten.

• Name: am besten passend zum realen Server
• Modus: HTTP (Layer 7).
• Server: den realen Server auswählen (hier jetzt paperless bzw. opnsense).

Bevor wir uns an die Frontends machen, konfigurieren wir noch den Rest: Bedingungen, Regeln und, weil es viel bequemer ist, Map-Files.

Wir beginnen mit den beiden Map-Files unter HAProxy > Einstellungen > Erweitert > Map-Files. Im PUBLIC-Mapfile werden nur die Einträge von Servern gemacht, die über das Internet erreichbar sein sollen. Pro Server ist eine Zeile erforderlich, die aus dem „Namen des tatsächlichen Servers” und dem „Namen des zugehörigen Backends” besteht. In diesem Beispiel ist also nur „paperless” von extern zu erreichen.

Im lokalen Map-File werden alle Server mit ihrem jeweiligen Backend eingetragen, unabhängig davon, ob sie im öffentlichen Map-File bereits verzeichnet sind (siehe Beispiel). So sind von intern alle Server über ihre DNS-Namen auflös- und erreichbar, von extern jedoch nur die zugelassenen Dienste. Die OPNsense sollte beispielsweise nicht über das Internet über ihr Webinterface erreichbar sein.

Für die letztendliche Entscheidungsfindung der OPNsense brauche ich dann zwei Bedingungen unter HAProxy/Einstellungen/Regeln & Prüfungen/Bedingungen:

• „NoSSL”, wenn der Traffic (noch) nicht SSL ist und deshalb erst „hochgestuft” werden muss.
• „lokaleIPs”, um zu unterscheiden, ob Anfragen aus dem internen Netz kommen oder nicht, denn ich mache nicht alle Dienste über das Internet öffentlich erreichbar.

Unter HAProxy/Einstellungen/Regeln & Prüfungen/Regeln formulieren wir abhängig von diesen beiden Bedingungen drei Regeln.

• „HTTPtoHTTPS”, um Daten von HTTP zu HTTPS hochzustufen (hier ist das Redirect Command wichtig).
• „LOCAL_SUBDOMAINS” regelt, welches Map-File bei privaten IP-Adressen erreichbar ist.
• „PUBLIC_SUBDOMAINS“ regelt, welches Map-File bei öffentlichen IP-Adressen (also außerhalb des MESH-VPN) erreichbar ist.

Kommen wir zum letzten Teil: die Frontends. Wir haben jetzt alles, was wir brauchen. Ich fasse noch einmal bis hierhin zusammen:

• DNS lässt sich sowohl intern als auch extern korrekt auflösen.
• Interne HTTP-/HTTPS-Anfragen gehen direkt an die OPNsense, externe Anfragen werden durch Portweiterleitung von der Fritzbox zur OPNsense geroutet.
• Die OPNsense ist abhängig von interner/externer IP und dem passenden MAP-File in der Lage, aufgrund des Hostnames (also der Teil vor .internally.duickdns.org) ein passendes Backend und damit Zielserver zu wählen.

Es bleiben die drei Frontends:

• Eins, das auf der WAN-IP auf Port 80 oder 443 lauscht und an die virtuelle IP weiterleitet.
• Ein weiteres Frontend stuft HTTP-Traffic zu HTTPS-Traffic hoch.
• und eines, das auf die Map-Files verweist und damit die Server unter ihrem FQDN erreichbar macht.

Die Frontends werden unter HAProxy > Einstellungen > Virtuelle Dienste > Öffentliche Dienste angelegt.

Wichtig ist Folgendes beim SNI-Frontend:

• Hörende Adressen: IP der OPNsense jeweils mit Port 80 bzw. 443.
• Typ: TCP.
• Standard-Backend-Pool: backend-SSL.

Beim HTTP-Frontend (erweiterter Modus aktiviert) ist Folgendes wichtig:

• Hörende Adresse: 127.4.4.3:80 (also nur HTTP)
• Bindeoptionsdurchleitung: accept-proxy
• Typ: HTTP / HTTPS (SSL-Offloading)
• Stand-Backend-Pool: keiner!
• Bindungsoptionen: no-sslv3, no-tlsv10, no-tlsv11, no-tlvs-tickets
• Regeln: HTTPtoHTTPS_rule

Beim HTTPS-Frontend (erweiterter Modus aktiviert) ist Folgendes wichtig:

• Hörende Adresse: 127.4.4.3:443 (also nur HTTPS)
• Bindeoptionsdurchleitung: accept-proxy
• Typ: HTTP / HTTPS (SSL Offloading)
• Stand-Backend-Pool: keiner!
• Aktiviere SSL-Entlastung: aktiviert
• Zertifikate: das erstellte Wildcard-Let’s Encrypt-Zertifikat
• Liste der Verschlüsselungsalghorithmen: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384
• Cipher Suites: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
• Aktiviere HSTS: aktiviert
• HSTS inkl. Subdomain: aktiviert
• HSTS Vorladen: aktiviert
• Bindungsoptionen: no-sslv3, no-tlsv10, no-tlsv11, no-tlvs-tickets
• Regeln: LOCAL_SUBDOMAINS_rule, PUBLIC_SUBDOMAINS_rule <- und zwar genau in der Reihenfolge!

Die Reihenfolge der beiden Regeln ist deshalb so wichtig, weil sie genau in dieser Reihenfolge durchlaufen werden. Sobald ein Eintrag übereinstimmt, wird der Rest nicht mehr abgearbeitet. Das bedeutet: Wenn die Reihenfolge falsch ist (also zuerst „Public”), erhältst du keinen Zugriff auf die nur lokal zugänglichen Subdomains. Andersherum kann dasselbe passieren. Deshalb ist es wichtig, dass das lokale MAP-File alle Subdomains enthält.

Wenn du das hast, solltest du alle konfigurierten Server/Dienste lokal über ihren FQDN und die ausgewählten auch über das Internet erreichen können. Letzteres kannst du auch von zu Hause aus testen, indem du auf deinem Handy oder Tablet temporär WLAN deaktivierst und den jeweiligen FQDN über die mobile Datenverbindung im Browser aufrufst.