System/Setting/General: Hostname und Domain

[cklahn]

Hallo Forum,

ich habe hier eine Grundlagenfrage.

Beim Installationswizard oder später im o.g. Menü, kann man den Hostnamen der OPNsense und einen Domänennamen vergeben. Ich habe hierzu folgende Fragen, die mir nicht ganz klar sind und in diversen Post und YT-Videos nicht so richtig erklärt werden:

a) Hostname ist eigentlich klar. Trage ich bei der "Domain" meine interne lokale Domain oder meine öffentlich Domain ein? Was macht es für einen Unterschied, wenn ich die lokale oder die öffentliche eintrage?

b) Wenn ich später bei einer "fertig" konfigurierten OPNsense den Hostname und/oder die Domain ändere, betrifft es dann schon erzeugte Zertifikate und muss ich die dann neu erzeugen lassen? Ich denke da an Zertifikate von OpenVPN für Server- und CLients o.ä.

[florit]

Hallo ;)

Die lokale Domain eintragen zb.: local oder localdomain

Das mit dem Cert ist die frage ob du eine ssl zugriff auf die Oberfläche der opnsense konfigurieren möchtest ... wenn ja dann anpassen

[JeGr]

zu 1) Die Hostname+Domain die du einträgst ist die, die bei der Sense intern für sie dann reserviert ist und auf die sie antworten kann. Heißt wenn der DNS auch entsprechend auflöst, dass sie antwortet. Ansonsten bekommst du bei irgendwelchen anderen Namen, die auch auf der WebUI der Sense landen würden die Login Protection, die falsche/andere Domains rausblockt wegen Security.

Sofern du eine ECHTE interne sowie externe Domain hast, solltest du die interne eintragen. Wenn du mit "interne Domain" irgendwas mit .local oder solchen Schmuh meinst, überlege dir gut VORHER, ob du ggf. mit deinem Lab/Homesetup/whatever ordentlich arbeiten und einfach mit Zertifikaten klar kommen willst. Wenn ja dann nutze eine echte (Sub-)Domain für dein Netz, es erspart dir Jahre Lebenszeit mit irgendwelchen Problemchen und Sonderlocken und anderen Dingen, die mit irgendwelchen angeblich internen Domains auftreten. Zudem ist außer .home.arpa und .internal (wobei da meine ich noch der finale Segen fehlt, aber es schon relativ sicher ist) keine Domainendung wirklich "intern" oder "privat", sondern kann jederzeit plötzlich zu einer echten Domain werden, wenn die TLD plötzlich bespielt wird. Siehe z.B. was mit .zip, .box und Co passiert ist (und ja, fritz.box war da sehr unschön betroffen).

Daher pusht seit Jahren selbst die langsamsten TechBros bei Microsoft die Agenda, dass man keine komischen internen Domains mehr basteln sollte, vor allem kein .local, weil das bei Apple, Linux und Co. für mDNS genutzt wird und einfach nur an jeder zweiten Ecke scheppert. (siehe https://learn.microsoft.com/en-us/archive/technet-wiki/34981.active-directory-best-practices-for-internal-domain-and-network-names)

Also im Schnelltext:

a) Entweder man wills ganz geheim geheim privat und ohne öffentliche Zertifikate je nutzen (eher weniger schön)
  --> man nimmt <name>.home.arpa oder <name>.internal

b) Man will sich alle Features für später offen lassen:
  --> man nimmt sich eine extra Domain für das Heimnetz (wenn man nicht eh eine brach rumliegen hat) oder nutzt eine Subdomain einer vorhandenen Domain, damit man nicht mit Live-Adressen kollidiert. Also bspw. home.meinedomain.de oder lab.myhome.net o.ä.


zu 2)
Der Hostname hat erstmal nichts mit irgendwelchen erzeugten Zertifikaten zu tun, außer du hast explizit ein self-signed oder eigenes Zert mit eigener CA für die Adresse gebaut. Dann ist ein Wechsel von Hostname+Domain natürlich unpraktisch, aber wenn man eh eine eigene CA erstellt hat, ist das auch schnell auf die neue Adresse angepasst. Wenn man eh gleich wie oben bei b) eine ordentliche echte (Sub)Domain genutzt hat, dann stellt sich die Frage hier ja nicht :)

Zertifikate für OVPN Server/Clients sind zudem völlig uninteressant, da es hier um eigens kreierte Zerts für den Zweck geht, da steht im CN meist eh was völlig anderes drin wie "openvpn-server" oder "client1" oder "client-cklahn" o.ä. - das sind keine Domains und die haben dann damit auch nichts am Hut. Das würde allerhöchstens Zertifikate betreffen, die du für die WebUI oder Services wie HAproxy, Nginx als Reverse Proxy, FreeRadius o.ä. nutzt und das hängt dann noch davon ab, unter welchem Namen die Services laufen. Hat also auch mit Firewall-Hostnamen und -Domain meistens nichts zu tun.

Cheers

[cklahn]

Hi,

klasse erklärt. Vielen Dank. Dazu noch kurz zwei Fragen zum Verständnis:

zu a) Wenn ich eine OPNsense dort einsetze, wo es eine "richtige" externe Domains gibt und dieser eine externe feste IP hat, also z.B. mustermann.de, dann sollte ich lieber beim Hoster einen A-Record mit der festen IPauf eine Subdomain setzen wie z.B. opnsense.mustermann.de
anstatt opnsense. mustermann.local?

zu b) Wenn ich das "originale" WebGui-Zertifikat belasse und dann später den Hostnamen inkl. Domain ändere, dann stimmt das WebGui-Zertifikat ja nicht mehr (habe mal mit einem Editor in das Zertifikat geschaut). Dort ist als CN ja der Hostname und die Domain hinterlegt. Sollte ich ein komplett neues Zertfikat für das WebGui erzeugen oder das bestehende editieren und über "Reissue and replace" updaten?

Danke und LG

[JeGr]

Hi,

klasse erklärt. Vielen Dank. Dazu noch kurz zwei Fragen zum Verständnis:

zu a) Wenn ich eine OPNsense dort einsetze, wo es eine "richtige" externe Domains gibt und dieser eine externe feste IP hat, also z.B. mustermann.de, dann sollte ich lieber beim Hoster einen A-Record mit der festen IPauf eine Subdomain setzen wie z.B. opnsense.mustermann.de
anstatt opnsense. mustermann.local?

zu b) Wenn ich das "originale" WebGui-Zertifikat belasse und dann später den Hostnamen inkl. Domain ändere, dann stimmt das WebGui-Zertifikat ja nicht mehr (habe mal mit einem Editor in das Zertifikat geschaut). Dort ist als CN ja der Hostname und die Domain hinterlegt. Sollte ich ein komplett neues Zertfikat für das WebGui erzeugen oder das bestehende editieren und über "Reissue and replace" updaten?

Danke und LG

a) Prinzipiell kannst du immer eine echte Domain einsetzen, wenn du eine hast. Muss auch keine neue sein, dafür gibt's ja die Möglichkeit eine Subdomain zu nutzen, die mit der aktuellen Nutzung nicht kollidiert.

Beispiel:

Du hast "cklahn.foo". Dort läuft aber korrekt eingerichtet ein externer Dienst. Also bspw. eine Webseite etc. und die Domain selbst und www. zeigen da drauf. Dann kannst du da trotzdem die Domain nutzen für dein Lab/Homenet/whatever, indem du als Domain dann z.B. home.cklahn.foo definierst und deine Firewall wäre dann sowas wie opnsense.home.cklahn.foo oder fwl01.home.cklahn.foo (oder beides). Das kannst du dann intern komplett erstmal so einrichten wie du willst, es wird nicht extern aufgelöst, weil die DNSe im Internte keine Ahnung von home.cklahn.foo haben, außer du trägst was dazu ein (was man nicht sollte außer ggf. die IP der Sense von extern).

Je nach DNS Dienstleister bei dem du die Domain geparkt hast, kannst du dann bspw. via ACME und DNS API problemlos dann echte Zertifikate für die Domain bzw. Hostnamen erstellen oder das über Umwege wie Domain Aliasing auf einer anderen Domain nutzen. Ich wollte das einfach haben und hab mir deshalb eine Domain geschossen und den DNS bei deSEC.io geparkt, wo man den DNS fein managen kann und direkt auch ne API nutzen kann, die von ACME unterstützt wird. Das geht aber über den Scope hier gerade :)

Wenn du keine statische IP hast, wirst du eh eher keine feste A/AAAA Konfig für deine Sense hinterlegen wollen/können, da sich deine IP ständig ändert. Das könntest du dann nur per Dyndns lösen und den Record von bspw. opnsense.home.cklahn.foo dann via CNAME auf den DynDNS Namen setzen, den die Sense selbst aktualisiert, dann würde es klappen.


zu b) Das Originale WebUI Zert hat eh keinen vollen FQDN Namen drin, denn OPNsense weiß den ja (noch) nicht. Wenn du das erste Mal die Sense konfigurierst, ist der Name ja noch nicht einmal festgelegt, trotzdem musst du schon via SSL/TLS zugreifen, ergo steht da eh nur ein Platzhalter drin. Ich meine schlicht OPNsense. Darum auch der Error beim Aufruf via IP oder irgendeinem anderen Namen, dass das Zert nicht passt. Kann es ja nicht :) Ergo ändert sich auch nichts an dem "Fehler" wenn du nen anderen Namen nutzt. Das wird nur dann relevant, wenn du der Kiste bspw. den Namen wie oben gibst: opnsense.home.cklahn.foo und dann via ACME z.B. dir ein Zertifikat hast ausstellen lassen für den Namen. Dann sollte es beim Aufruf lokal keinen Error mehr geben. Du kannst via unbound Host Overrides dann beliebig DNS Adressen von home.cklahn.foo definieren, die du dann intern nutzen kannst (weil dein DNS die Sense ist und die das dann kennt) ohne dass das im public DNS deiner Domain drinstehen muss.
Und ja, wenn du dann auf die Idee kommst, dass jedes Mal opnsense.home.cklahn.foo zu tippen zu lang ist und du gern fwl.home.cklahn.foo nutzen willst, dann musst du ein anderes Zert erstellen lassen (bzw. nen SAN mit mehreren Einträgen drin) damit kein TLS Error kommt nach dem Umbenennen aber ansonsten hat das erstmal keine wirklichen Auswirkungen.


Kleiner Hinweis:

Wenn man statt Firefox was "Chrome"-artiges benutzt und man kommt wegen eines HSTS Fehlers nicht weiter, weil das Zertifikat nen Error wirft oder abgelaufen ist o.ä. und da man HSTS konfiguriert hat will der Browser nicht weitermachen?
Gebt einfach mal

thisisunsafe

ein, während der Browser so eine Fehlermeldung wirft. Da gibts keine Dialogbox oder sonstwas, einfach blind tippen, wenn ein HSTS Error geworfen wird und man wird direkt mit einem Laden der Seite belohnt. Der Override ist direkt in Chrome Source Code eingebettet.

Kann man bspw. auf "badssl.com" testen. -> Bad HSTS Subdomain check
Auf der Seite sollte in Chrome(-ium) Browsern kein "weiter" angeboten werden. Dann einfach direkt "thisisunsafe" tippen ohne irgendwas markiert zu haben. Also nicht in die URL Leiste, das hilft nicht ;)

Cheers