Messages

[was ist einfacher und auf veränderungen]

Die Frage war eigentlch:_ für jeden Vlan/Alias eigene Port regeln erstellen oder
für "jeden" Port was man freigibt Vlan/Alias zuordnen.

was ist einfacher und auf veränderungen

Du stellst eine Frage die überhaupt nicht existiert :)

Wenn du Regeln erstellst, dann ja auf dem Interface, wo der Traffic reinkommt. Und das ist bspw. das VLAN_123 Interface. Das Einzige was du da als Source auswählen könntest wäre entweder das ganze Netz (VLAN123_net) oder eben einzelne IPs via Alias. Für das Netz brauchst du kein Alias, das wird automatisch angelegt. So. Die Frage war entweder Alias für Source und einen Port oder "alle"/Netz mit mehreren Ports. Das besteht aber nicht, weil du - wenn das sauber aufgetrennt ist und man keine Sonderlocken-Hosts hat, ist die Source einfach IMMER "xy net". Und dann ist deine Freigabe entweder nach Destination oder Destination+Port. Und was da "besser" oder nicht ist, ist für jeden anders. Ich habe Kunden, die wollen da lieber jeden Port einzeln oder zumindest nach Dienst getrennt und haben dann Port-Aliase nach Diensten. Da wird dann eben Destination "fileservers" mit Ports "cifs" als Alias freigegeben. Andere limitieren intern nicht auf Ports, sondern nur auf Hosts und nur ausgehend ins Internet werden Ports eingeschränkt, etc. etc.

Da existiert kein "Das ist besser als Das" weil es sehr auf deinem Einzelfall beruht, was du fürs Regelwerk brauchst und baust. Und ob du dann damit klar kommst oder nicht. Im Prinzip liegt die Auswahl eher auf "WAS kann ich WIE am Besten in so wenig wie möglich Regeln zusammenfassen". Und das kann man entsprechend via Host, Netz oder Port Alias kombinieren. Ich muss dann nicht 5 einzelne Hosts mit PortAlias machen, ich kann einfach HostAlias mit PortAlias in die gleiche Regel.

Und da man Aliase nach Typ kombinieren kann - du kannst einen Host Alias in einen anderen Host Alias packen - kann man auch Geräte per Alias definieren, dann einen "Gruppen"-Alias machen wo mehrere Geräte-Aliase drin sind und den in der Regel nutzen. Würde nur empfehlen nicht "zu tief zu schachteln", da das sonst sehr schnell unübersichtlich wird, was wo drin ist. Aber eine Ebene tief ist für die meisten Fälle kein Problem. Und dann ist auch eine Änderung später kein Problem, wenn dein Fileserver statt .15 neu ausgerollt dann die .20 hat, ändert man eben das Alias und wenn das dann in den "Gruppen"-Aliasen schon drin ist, muss man weder die noch die Regeln anfassen.

Es kommt also nur auf sinnvolle Nutzung der Aliase an. Skalieren tut das alles, "wie" hängt ganz von deinem Einsatzzweck ab.

Cheers!

Die Clients benutzen einen Windows DNS Server vom AD Controller.

Das ist ja aber kein Problem. Trag doch einfach beim Windows DNS die Sense als deinen DNS (Forwarder) ein. Macht doch eh mehr Sinn, wenn am Ende EINER im Netz das DNS nach draußen spricht und nicht jeder nen anderen Weg und andere DNS Antworten bekommt? Zudem Caching, Resolving yada yada etc. etc. also macht ja durchaus Sinn.

Und dann einfach intern via den Unbound auf der Sense Split-DNS fahren. Kein NAT refrickel, kein Basteln, geht einfach den gleichen Weg (Proxy->Server) wie extern auch. Nur dass eben ne andere IP zurück kommt und der HAproxy ggf. auch intern auf seine IP hören sollte. Gibt sogar noch einen Bonus: wenn du einen Dienst hast, der ggf. nur intern erreichbar sein soll (ohne Prompt/Passwort/etc.) kann man das via 2 Frontends sehr angenehm trennen (geht mit einem Frontend auch, aber dann eben mit ACLs und Co.)

Zudem bei NAT: Solang du nur WAN/LAN hast, ist das noch überschaubar. Sobald aber mehrere Interfaces im Spiel sind, macht NAT Reflection unnötige Regeln für alle anderen Interfaces die da sind, dabei brauchst du ggf. nur eben LAN wegen deiner Clients. Darum würde ich generisch auf Einschalten von NAT Reflection verzichten und wenn du lieber NAT statt Split-DNS und Proxy machen willst die Regel einfach selbst anlegen. Dann gibts auch keine unnötigen Regeln im Filter.

Cheers!

Hi,

auch wenns etwas her ist, würde ich das gern aufgreifen: "Keins von beidem".

Warum? Quelle einzeln oder mit mehreren (alias) heißt in vielen (fast allen) Fällen, dass irgendwas manuell an IPs rumgeraffelt wird. Entweder werden semi-statische IPs verteilt oder händisch statische vergeben, ansonsten bekommt man die Geräte nicht "zusammen" in einen Alias/Gruppe oder überhaupt mit Regel eingesammelt.

Ich werfe da in den Raum, das lieber - contra zum Kommentar in einem anderen Thread von Cedric :) - mit VLANs/Netzen zu machen. Warum nicht weniger weil overhead und komplex etc? Weil es an vielen Stellen das Setup unterminiert. Static IPs kann ich umgehen, vergebe mir einfach selbst ne andere etc. DHCP Reservierungen sind auch nicht sicher, die kann ich mir selbst vergeben, spoofe die MAC Adresse etc. etc.

Klar für zu Hause kann man das alles machen. Aber warum dann statt dessen nicht gleich die Features von OPNsense ausnutzen und sinnvolle Clientgruppen in diverse VLAN/Interfaces klemmen? Alles was bspw. "Media" macht und Streaming braucht, wird Internet brauchen mit diversen Ports etc. Alles was limitiert ist (weil man die Kids vllt. langsam ranlassen möchte) wird limitiert. Und dann zieht man die nicht einzeln manuell raus, sondern packt sie ins entsprechende Netz/VLAN rein. Da gibts dann eben Streamer, Kameras, Drucker, Server, Clients mit Internet, Clients ohne Internet, limitierte Clients, Clients hinter Portal etc. alle in ihrem eigenen Netz.

Hat man das gebaut, sind die Regeln gerade auch in Punkto IPv6 später wesentlich einfacher, weil man keine große "Quellangabe" mehr braucht. Quelle ist dann einfach das "Netz"-Alias (Clients_subnet, Server_subnet) etc. und gut. Kein versehentliches "oh ich hab dem einzelnen Client zu viel Rechte gegeben". Und vor allem kein Gefummel mehr wenn doch v6 dazu kommt. Dann will man kein DHCPv6 o.ä. machen nur um dem Client ne fixe Adresse zuzuweisen um ihn zu beschränken. Da passt dann der ganzen Wumms sofort mit Netz, SLAAC für IPv6 drauf, automatisch vergeben lassen und fertig, go, raus damit. :)

Da das ja durchaus häufiger mal gefragt wird beim Punkt "wie mach ich denn 'sichere' Regeln", wollte ich das an der Stelle mal aufgreifen!

Cheers :)

Das "custom" kann man zwar mit den aktuellen Werten füttern wird aber nicht zum Erfolg führen. Bei der Hetzner API läuft es scheinbar etwas anders, soweit ich verstanden habe muss man erst eine ID abfragen die man dann benötigt um den DNS Eintrag updaten zu können, also mindestens eine zweistufige Abfrage, das leistet der "custom" Eintrag nicht. Der custom geht auf <URI>/nic/update?.... Das kann die Hetzner API nicht interpretieren.

Evtl. kann @meyergru da was aus seinem persönlichen Fundus erzählen, er hat ja schon mit dem DNS gekämpft ;) aber soweit ich das im Hinterkopf hatte war das IMHO so, dass die IDs wenn mal angelegt nicht mehr geändert werden. Somit musst du einmal deine ID für den A/AAAA Record rausholen, aber die ändert sich nicht, die kannst du also dann in den "Custom" Eintrag reinpacken und good2go. ACME ist dann ein anderes Beast wenn da DNS-01 mit dran hängt. Autsch. Allerdings ist zumindest acme.sh eigentlich recht fix, mal DNS Provider zu ändern. Kann man aber nur hoffen.


Ich bin da aber auch mit den letzten Sachen in Punkto "Console" Umstellung, DNS, Mail und Support bei Hetzner weiter eher an dem Punkt, für DNS lieber was Anderes zu nutzen. Keine Werbung - weil kostet nichts - an der Stelle, aber wenn man die Domain via NS Einträgen woanders hin delegiert, sollte das bspw. zu deSEC zu schieben kein Thema sein. Ich hab meinen Kram mit dem ich DDNS & ACME spiele dahin gepackt, weil Verein, Fokus auf OSS, DNSSEC und Kompatibilität und ich habe mit dem Team schon ein zwei kleine Verbesserungen speziell für das Zusammenspiel mit den Sensen eingebaut.
Auch sowas wie v6 Prefix Update ist gerade in der Mache, damit man nicht mehrere v6 DNS Einträge einzeln ändern muss, sondern einmal für mehrere ein neues Prefix schicken kann - Adressbereich bleibt. Da wird viel gearbeitet und ausgebaut was Features angeht. Die machen da nicht nur DynDNS, da kannst du auch mal deine normale Domain sehr vernünftig parken.

Cheers!

Zwar sind /24 komplett übertrieben, in einzelnen VLAN sind nur wenige Geräte drin - Büronetz z.b. nur das Firmennotebook, aber ist mir egal.

Das ist auch nicht falsch, das zu tun. Genauso wie bei IPv6, wo du überall /64 anlegst, auch wenns ggf. nur ne Hand voll Geräte sind. Bei v6 hat es zwar tatsächlich Hardware/technische Gründe, aber im privaten Adressbereich macht es Sinn, das genauso zu handhaben. Prinzip der kleinsten Überraschung (POLS), dann hat man es beim Debugging leichter.

Und da ich über das Configfiles alle DCHP-Reservations und Aliase mit geändert habe, sind auch direkt alle Firewall-Regeln aktuell, weil auf Aliasen basieren.

So soll das auch sein :)

Ich mache weiterhin so, wie mein aktuelle Netz im 10.0.x.y - Bereich, wobei x = die VLAN-ID ist, nur nehme ich eben jetzt den 172.20.x.y Bereich.

Das würde bei mir eben krachen, weil ich bspw. 172.27.0/1 nutze und da kann ich schlecht VLAN ID 0/1 nehmen ;) Zudem geht man bei VLANs gern aus den Einstelligen/kleinen IDs raus, da da gerne andere Geräte mal reingrätschen. Siehe DSL mit seinem VLAN 7 Geraffel.
Darum war sowas wie 270/271 oder 2700, 2701 einfacher und gibt weniger Fläche für Probleme später.

Aber klar, du machst was für dich passt, sind alles nur Vorschläge und eine Art "best practice" was sich eben über die Zeit als sehr gelegen ergeben hat.

Cheers :)

Hatte Patrick schon gesagt. Ihr habt Recht, allerdings ist das mit DDNS-Domains oft ein Problem, weil man den DNS nicht vollkommen kontrollieren kann (z.B. nur A- und AAAA-Records eintragen).

Stimmt, wenn Peter und sein Team bei deSec/dedyn nicht genau deshalb ihren Dienst dafür getrimmt hätten ;) Darum wollte ich das nochmal kurz anhängen, sollte es jemand via Suche o.ä. finden, dass das durchaus geht und bei dedyn/deSEC auch kein Thema ist. Die legen da sehr viel Wert drauf, einen sauberen und funktionalen DNS zu haben der DNSSEC bis oben spricht. :)

Hat da vielleicht jemand schon eine Idee dazu, oder sollte man besser auf die Kollegen vom os-ddclient warten?

Hängt davon ab, was nutzt du denn aktuell um DDNS zu machen?
Ansonsten haben die meisten Plugins ja "Custom" Varianten, wo man einfach die neue API entsprechend reinwerfen kann.

Cheers

Man kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Da das noch so im Raum stand und ich das noch anhängen wollte nach dem Durchlesen des Threads hier:

Doch. Keine Ahnung wo du das hernimmst, dass das nicht erlaubt wäre. Natürlich darf ich ein Wildcard für eine Subdomain erstellen. Haben wir mehrfach im Einsatz. Bspw. für sowas wie "*.dev.domain.tld". Das wäre ja sehr bescheuert, wenn man nur Wildcards auf erster Ebene aber nicht auf höheren erstellen dürfte ;)
Und dedyn hält sich da komplett an den Standard und erlaubt das auch. Das war lediglich ein Knoten in der Konfig, aber können, tut es sowohl Dedyn/deSec als auch ACME. :)

Cheers!

Um das Problem (Subnet 172.16.126.2/26 an der OPNsense, mit Verbindung via IPsec, zu 172.19.184.3/24 auf Sophos) zu defineren, und um die Config mit Sophos einfacher zu halten.
Denn wenn ich alles in einen Tunnel mache, dann benötige ich mindestens 3 Einträge mehr; wegen den Subnetzen, die Sophos ansonsten nicht "getrennt" betrachten kann im Routing.
Und wie gesagt, wenn ich nur einen Tunnel mache (mit mehr Einträgen), dann wandert das Problem mit.

Dann sag ichs nochmal: IPsec mit EXAKT IDENTISCHER Phase 1 darf es nicht 2x geben. Du kannst das nicht trennen, weil das kaputt ist. Nur weil sich was aufbaut, heißt nicht, dass das funktioniert. Dass es nicht funktioniert siehst du ja bereits.

Ein Tunnel zwischen 2 Geräten über die exakt gleichen IPs darf nur einmal aufgebaut sein. 2x wäre nur sinnvoll, wenn der 2. bspw. an einer Seite über eine andere Schnittstelle geht (bspw. WAN1<->WAN und WAN2<->WAN auf den Geräten). Aber die gleiche P1 darf es nicht geben, sonst ist das ein Duplikat und je nachdem welcher Hersteller das ist, hüpft der dir im Quadrat und killt die Verbindung.

Die Sophos im Log sagt ein Auth Problem, die OPNsense sagt dir "decrypt" Problem im Log, weil die Pakete in der falschen Phase ankommen (encrypted vom ersten Tunnel, kommen aber nach dem Aufbau von Tunnel 2 im falschen Tunnel an weil die IDs überlagern).

Das macht keinen Sinn, das gehört alles in die gleiche P1 zwischen den gleichen Geräten. Dass die Sophos dann das Problem hat, dass das mit den "3 Einträgen mehr" dann doof gelöst ist -> willkommen bei IPsec und jeder implementiert es anders. Das ist eben leider so. Manche Spieler können Multi-Netze in einer Single Phase 2 abbilden, andere nicht, da muss man jede P2 einzeln definieren und aufbauen. Und AFAIR ist Sophos letzteres und kann das nicht, ergo muss man eben jede Source<->Destination Konstellation in P2 gießen.

Darum auch der Hinweis bei Fragen zu Netzplanung, Design, VLAN etc. immer das Netz so zu planen, dass ichs bspw. bei VPNs als eine große Einheit greifen kann um die Anzahl an P2s (IPsec) oder Routen (OVPN/WG) simpel zu halten.

Cheers :)

[KEINEN automatischen Sync]

Evtl. war eine Einstellung noch nicht auf den HA Backup übertragen,...

Wichtig da gern überlesen/ignoriert/nicht gewusst: OPNsense hat bereits seit einiger Zeit KEINEN automatischen Sync mehr zwischen den beiden Cluster-Nodes. Diesen muss man entweder explizit über einen Scheduler/Cron-Job einrichten oder man muss daran denken, manuell zu synchronisieren. Der alte Mechanismus, dass jede Änderung automatisch gesynct wird (wie nach dem Fork von pfSense) gibt es nicht mehr!

Das ist wichtig, da stolpern leider viele drüber, die sich da nicht up2date gehalten haben, was dann darin endet, dass dort dann ein völlig veralteter Standby Node mitläuft, der überhaupt nicht korrekt "übernehmen" kann, wenn es brennt.

Cheers!

Super, vielen Dank. Dann weiß ich, wo ich ansetzen muss. Dann mach ich mich mal ans Werk.

Stichwort ist Radius-based VLAN beim WiFi mit 802.1x Enterprise WPA. Dazu kann man auch den Freeradius der *sense ran ziehen und den nutzen. Da bei Enterprise WPA User/PW gebraucht wird statt PSK hängt man das VLAN im Radius einfach an den User - fertig. Gerät bekommt dann beim Einloggen mit der User/PW Kombi das VLAN wie definiert. Man hat dann eben die 2. Abhängigkeit bei WiFi, dass die Firewall mit Radius up&running sein muss, sonst gehen die Geräte nicht, aber wenn die FW nicht läuft hat man meist andere Probleme ;) Heißt aber auch: bei Update/Neustart der FW können Geräte aus dem WLAN fliegen. Daher überlegen, ob man das an der Stelle vertretbar auf der Firewall oder lieber extern haben möchte.

Cheers!

2. 172.16/12 wird u.a. von Docker et.al. für internes Networking genutzt - ich habe nie probiert, was dann passiert, wenn das LAN auch Adressen darauf verwendet.

Eigentlich egal, außer jemand hat Docker oder Container fix in spezifische Netze gemappt. Docker macht eigentlich ein Probing, ob das entsprechende Netz was es sich greifen will (random) frei ist oder nicht.

Ich würde auch eine ordentliche Netzplanung vorschlagen, aber IM 172.16-32.x.y Bereich. Für die meisten Homelab oder halbwegs normalen Firmennetze ist 172.16-32 eigentlich ideal. Ich empfehle da zwar auch 16 und 32 zu vermeiden weils immer in Dokus gern rangezogen wird, aber bspw. 172.24 etc. ist keine schlechte Idee. Mit einem /19er Bereich hat man da genug Platz für allerhand VLANs, kann sich passende VLAN IDs zusammen murmeln und wenn man im Design nicht gerade die massiven Fehler macht, ist das ganze noch topp erweiterbar.

Warum 172.? Weil 192er gern für irgendwelche SoHo Boxen/Router/Modems/blah in use ist und 10.x dann eben meist bei Hostern, ISPs, Cloud, etc. verbummelt wird. Da hat man mit 172 noch eine super Ausgangsposition, auch mal was Privates mit 192 anzubinden oder was Corpo/Cloud-mäßiges im 10er ohne dass man Kollisionen hat.
Wenn man sich dann ordentlich intern umschaut, was man sinnvoll in VLANs packen sollte (merke: kleinere Netze bevorzugt, gerade und auch wegen IPv6 auch wenns im ersten Moment doof klingt), dann hat man sehr fix nen Dutzend VLANs beisammen. Bei mehr als 60% Usage von Netzen würde ich eine um 1 größere Maske nehmen.

Sprich: Beispiel - 172.24.0.0/20 reicht mir doch dicke! -> sind 16 Netze à 24/VLANs. Dann fang ich an zu zählen... oh. Management, Server, VoIP, Drucker, Kameras, IoT Gebimsel, Medienkram, Admin-only Zeugs, Isolierte Sachen, Clients1, Clients2, Gäste, Portal... hoppla sind schon 13-14. Also >60% in use -> größere Maske

Also nochmal Grübeln und komme noch auf Clients3, WLAN1, WLAN2 -> 16 Stk. Und weil voll nehm ich die Maske eins Größer -> also 172.24.0.0/19

Wenn ich dann irgendwas mit meinem Netz machen muss was Routing angeht, bspw. via VPN, etc. hab ich alles sofort mit einer einzigen Netzmaske erschlagen. 172.24.0.0/19.

Ein kleines Beispiel für ein Homelab mit Segmentierung und Planung:
Subnet Calculator für 172.24.0.0/20 (Homelab Beispiel)

Dann noch VLANs drunter, die man schön mit 24 (2. Teil der IP), xx (3. Teil der IP) vereinfachen kann. Also bspw. 2400, 2401, 2402 jeweils zu den Netzen. Ja das klappt nur bis 99 und nicht immer. Aber wenn man schon alles neu macht, kann man das auch "handlich" machen, damit man an Hand der IP auch gleich das VLAN hat und damit einfacher debuggen :)

Cheers!
\jens

Hi,

- 2x IPsec zwischen den beiden (1x mit 3 Subnetzen, 1x mit 1 Subnetz)

was genau heißt 2x IPsec zwischen den beiden: 2x ein IPsec Tunnel mit exakt gleichen Daten? Warum? Oder was genau ist damit gemeint?

Zu den Logs: bei der OPNsense ist das etwas wenig Log, da sind keine genaueren Infos drin. Zumindest sieht man da IMHO keinen Fehler. Könnte man das Logging erhöhen, aber ich wäre erst einmal an Info zur ersten Frage interessiert. Es gehen nämlich eigentlich keine 2 Tunnel (P1 mit identischen Daten) zwischen den gleichen Endpunkten. Da können die Geräte schlicht nicht zwischen unterscheiden. Darum ist es eigentlich nicht erlaubt. Verstehe auch den Grund nicht ganz, wahrscheinlich wegen dem einen Subnetz, das sich nicht verbinden will? Das ist dann aber das Problem dieser einen Phase 2 und nicht eines, wofür man einen komplett neuen Tunnel baut?

Cheers,
\jegr

Weiß jemand, warum das so ist und ob kann man das verhindern kann?

Wenn du bei der Forwarding/NAT Regel das mit einem Source Alias wie GeoIP eingerichtet hast, dann gilt dieses Alias von intern NICHT, da die Quelle dann das interne Netz nicht mit drin hat. Sprich dein Forwarding gilt nur von außen, das kannst du via NAT Reflection nicht von intern aufrufen. Wenn es intern via SplitDNS bspw. aufgerufen wird, dann sollte es je nach Setup funktionieren (kommt auf die Weiterleitung an). Alternativ, wenn das mit NAT Reflection gehen muss, dann muss in deinem Source Alias auch das/die internen Netze, aus denen es funktionieren soll mit inkludiert sein.

Andere Alternative ist statt einfach mit grober Kelle NAT Reflection zu nutzen, das nur selektiv für intern manuell einzurichten, von Verbindungen aus, die funktionieren müssen, damit die auto NAT Reflection nicht einfach wild das auf allen Interfaces durchkonfiguriert.

Cheers!

Hi,

ist das via HTTPS oder mit Weiterleitung auf HTTPS eingebaut? Kannst du im Quelltext der Seite was sehen, ob die Komponenten zum Login überhaupt nachgeladen wird wenn das Formular nicht angezeigt wird? Evtl. gibts da einen Fehler bei der Einbettung des Logins?