Messages

Hallo viragomann,

danke erst Mal für die Rückmeldung!

Nur den Zugriff auf die WAN IP zu erlauben, reicht nicht aus. Da muss auch ein Dienst die Anfrage entgegennehmen.

Ich möchte ja das Zertifikat für diese Verbindung auf meiner OPNsense hinterlegen. Diese ist ja das Ziel von "ibins.no-ip.irgendwas". Damit mir no-ip dieses Zertifikat für diese Verbindung zur Verfügung stellt, muss ich no-ip den CSR an der Stelle generieren, an der ich später das Zertifikat hinterlegen möchte. Also gehe ich hier her <siehe Screenshot> und erstelle mir die Zertifikatsanfrage. Wenn ich das Prozedere durch habe (incl. natürlich dem Eintrag für meine "ibins.no-ip.irgendwas"), dann stelle ich den durch die OPNsense generierten CSR bei no-ip ein. Leider kann ich dir keinen Screenshot von den Kommentaren und dem HowTo der no-ip-Seite zur Verfügung stellen, weil ich da aufgrund der ausstehenden Verifizierung nicht mehr hin komme. Deshalb mit meinen Worten erklärt, so wie ich es von no-ip verstanden habe:

• Stelle deinen CSR hier bei uns ein,
• leite den Port 443 auf deinen Webserver weiter (dort wo du das Zertifikat hinterlegen möchtest)
• anschließend wird verglichen, dass die Anfrage auch tatsächlich von da kommt, wo das Zertifikat hinterlegt werden soll.
• Sobald wir das verifiziert haben, kannst du dir das Zertifikat runter laden und hinterlegen.

Sobald ich auf der OPNsense eine CSR erstelle, wartet die doch von selbst auf die Abfrage der Zertifizierungsstelle?

Passt dieser vielleicht im CSR nicht?

Doch, sonst hätte ich den CSR nicht einreichen dürfen. Beim ersten Versuch habe ich da nicht dran gedacht - meine OPNsense kennt den no-ip-Hostname (sie aktualisiert ihn ja auch) und no-ip weiß ja auch für welchen Hostname ich das Zertifikat beantrage. Warum sollte ich also den Domainname nochmal eintragen? CSR wurde von no-ip sofort abgelehnt.

Und was soll die damit?
Möchtest du die Zertifikate dann von OPNsense auf die Ziel kopieren?
Ansonsten müsste OPNsense Server spielen. Kann sie das für die benötigten Protokolle?

Jetzt kommt der Punkt wo du mich etwas stutzig machst:
Dort wo die OPNsense jetzt steht, hat zuvor eine pfSense den Dienst verrichtet. Zu diesem Zeitpunkt hatte ich eine registrierte Domain und habe die (zusammengefasst) auf meine DMZ gepointed. Über den Domainhoster das Zertifikat geholt, in die pfSense eingespielt und alles war gut. Egal welchen Dienst von welchen Server ich von außen über meine Domain angeboten habe, dieser Dienst lief stets über das Zertifikat. Also ohne die klassische "nicht sicher"-Meldung. Und genau dasselbe möchte ich durch mein Vorgehen bei no-ip erreichen.
Da ich bei dem pfSense-Prozedere das Zertifikat auf keinem einzigen Server in der DMZ hinterlegen musste, scheint mir das der richtige Weg. Der Server wird ja nach der OPNsense ganz anders angesprochen, als auf der Strecke von meinem Client über den ISP zur OPNsense...

Hallo zusammen!
Bevor ich Mekker bekomme, hab ich gleich mal ein Pic angehängt um zu verdeutlichen was ich vor habe, bzw. wo's mit dem Verständnis klemmt - und somit auch mit der Umsetzung...
In der DMZ habe ich sowohl Cloud (Telefonsynchronisation, etc.), als auch Spieleserver (<-Plural) für meine Kids und ihren Freundeskreis. Damit das alles einfach zu handhaben ist, habe ich bei no-ip zwei Hostnamen, welche über den DynDNS-Client in der OPNsense auf meine öffentliche IP verweisen. Ein Hostname wird (sobald das Gerät ins W-Lan kommt) auf die Cloud geroutet und der andere auf die Gameserver. Läuft soweit.
Nun nutze ich bei meinen "Möchtegern-Roadwarriors" (ist ja kein VPN) verschiedene Apps um auf verschiedene Clouddienste zugreifen zu können. Wer jetzt die Frage stellt "Warum kein VPN": Weil ich permanent in zwei Netzen unterwegs bin, welche einen VPN-Tunnel blockieren. Zumindest IPsec und openvpn. Zwei dieser Apps meckern nun, da ich kein offizielles Zertifikat besitze. Das wäre aber mittels CSR bei no-ip möglich.
Und da komme ich ins Stolpern:

• Ich habe den CSR auf der OPNsense erzeugt und bei no-ip eingetragen.
• no-ip bleibt auf dem Status "Ausstehende Verifizierung" - heißt für mich, der no-ip-Dienst kann weder über 443 noch 80 mit meiner OPNsense kommunizieren.

Es funktioniert aber keines der beiden angehängten Regelwerke. Bei mir wurde auch kein Regelwerk automatisch angelegt.
Kann mir jemand verraten wo mein Denkfehler liegt?

Alles was mir Tante Google und diverse Foren bieten ist immer "NAT-Regel", "interne IP", "Port 443 und 80", tralala. Ich will aber das Zertifikat nicht auf meinen Servern oder der Cloud haben, ich will das Zertifikat auf meiner OPNsense liegen haben. Die ist ja das Ziel der no-ip-Verbindung.

Danke,
Stefan

[.]

So, das mit der Änderung von FQDN auf IP hat gar nichts gebracht.
Allerdings habe ich inzwischen festgestellt, dass die OPNsense das MAC-binding beim KeaDHCP nicht sauber umsetzt, was eine Ursache des Problems sein könnte.

Beispiel (geschieht nur bei zwei Clients, einer davon ist der Desktop):
Es ist für die physikalische MAC des Clients "Desktop" die IP 10.10.50.100 vorgegeben. KeaDHCP weist dem Client aber die IP 10.10.50.50 zu (obwohl diese IP gar nicht in der DHCP-Range liegt) und zeigt mir bei den Leases die tatsächliche MAC an, die falsch vergebene IP und den Host "desktop.". Dieser Client und der zweite Client sind die einzigen Beiden, die den"." dahinter bekommen. Ich finde jedoch keine Erklärung zu dem dot...

Hallo patient0,
vielen Dank für die Infos! Ich frage mich warum man das mit dem first- und last-match macht und die Regeln nicht einfach der Reihenfolge nach listed. Aber na gut, dann ist dem so.

Den Vermerk aus deinem Link der Dokumentation kenne ich, verstehe ich aber so, dass eher der Switch ein Problem damit hat und nicht die OPNsense (bis auf die Anzeige des Traffic). Die Separierung der Geräte in die jeweiligen V-Lans funktioniert einwandfrei, incl. DHCP und DNS. Ich benutze als Hardware eine ausrangierte Sophos XG125, hätte also genügend physikalische Ports zur Verfügung. Würde aber mit anderen Worten heißen, wenn ich es 100%-ig machen möchte, ich müsste jedes V-Lan auf einen eigenen Port legen und diese dann am Switch jeweils tagged wieder im System zusammenführen?

Dein Hinweis die IP zu verwenden statt dem FQDN: Werd ich jetzt mal mit ein paar Geräten ausprobieren und dann Feedback geben!

Dankeschön
Stefan

Hallo zusammen!

Ich versuche gerade eben von pfsense auf OPNsense umzusteigen und stoße da auf ein für mich nicht erklärbares Problem.
Schnittstellen/Netze:
ix0: LAN - darauf liegen vlan0.2, 0.5 und 0.9
ix1: WAN
opt1: DMZ
opt2: WAN2 (derzeit offline)

Mein Ziel ist es bestimmte Clients aus dem Client-VLan in das IoT-VLan zu lassen. Dies funktioniert aber nicht und ich habe keine Ahnung wo in meinem Regelwerk der Fehler ist...
Womit ich bei der OPNsense gar nicht klar komme ist, dass die automatisch generierten Regeln oben stehen, verschachtelt in einer Kategorie, und sich hier anscheinend nicht an first-hit-wins gehalten wird. Wie auf dem Scrennshot ersichtlich, steht im automatischen Regelwerk gleich mal ganz oben eine deny-all mit dem Vermerk "Letzte Zuordnung". Und sämtliche darauffolgende Regeln, die bei der Abarbeitung eigentlich drüber kommen, stehen drunter. Bei mir gefühlt 15x mit dem Vermerk "Erste Zuordnung".

Kann mir jemand sagen welche Regel meinen Traffic von "desktop -> emlog" blockiert und den Traffic von "Handys -> IoT..."? Den Eintrag "IoT-Adresse" habe ich auf dem Screenshot nur drinnen, da ich mit "IoT Netzwerk" nicht weiter gekommen bin..
Im Screenshot ist auch erkennbar, dass der Desktop auf den Server "ourminecraft" in der DMZ zugreifen können darf/soll. Kann er auch nicht.

Bei meinem Regelwerk, so wie ich es nun verstanden habe, geschieht bei einem Zugriff über die Schnittstelle Client in Richtung V-Lan IoT folgendes:
Zugriff "desktop -> emlog" -> Auflösen von "emlog" in IP
-> Check von oben nach unten:
1. Gehört nicht in die Gruppe "handys" -> weiter
2. Ist nicht der Host "cloud" -> weiter
3. Ist der Host "desktop" - > trifft zu, Regel auflösen
4. Hat als Ziel den Host "emlog" -> trifft zu, Regel auflösen
5. Regel ist "erlaubt" -> lass die Quelle auf das Ziel zugreifen.
Zu der Regel "deny LAN Netzwerk, ADMIN Netzwerk, IOT Netzwerk" kommts gar nicht mehr, da alle Regeln auf "quick" gesetzt sind.
Ebenso dürfte es auch nicht mehr zu einer Prüfung der automatisch generierten Regeln kommen.

Im Übrigen war das so grob (ohne die automatisch generierten Regeln) auch das Regelwerk der pfsense. Hier jedoch hatte ich hinter den Aliasen der Firewall die IP-Adressen versteckt. Hier bei der OPNsense habe ich im Alias den Hostnamen aus dem KeaDHCP. Die Auflösung der Hostnamen funktioniert übrigens bei einer allow all:)

Wo habe ich meinen Denkfehler?

Danke schon mal,
Stefan

Super, genau das war's!
Hab einfach nach dem Falschen gesucht...

Danke!

Hallo zusammen!

Da ich mit OPNsense noch überhaupt keine Erfahrung habe, eine ganz banale Frage zu opnsense welche ich so auf Anhieb im Wiki nicht beantwortet bekam:
Ist es möglich bei OPNsense eine zweite WAN-Schnittstelle zu betreiben?
Hintergrund: Die Firewall soll sowohl via GSM-Gateway, als auch über ein bereits bestehendes Netzwerk auf das Internet Zugriff erlangen. Die "Hauptschnittstelle" ist für das bestehende Netzwerk, die zweite WAN-Schnittstelle (die Rückfallebene) das Gateway.

Mit den mir als "Freizeit-Admin" bekannten Firewalls wie IPcop und IPfire ist das leider nicht möglich weshalb ich mich für diesen einen Anwendungsfall nach etwas Neuem umsehen muss...

Dankeschön derweil mal,
Stefan