Messages

Wenn ich im Hetzner Robot für die zweite IP eine MAC erstelle, müsste ich doch in der OPNSense VM eine zweite WAN-Schnittstelle haben, um dort die MAC eintragen zu können? Da stehe ich grade auf dem Schlauch, wie man beide MAC-Adressen hinterlegt, wenn die OPNsense nur eine WAN-Schnittstelle hat. Der Traffic beider IPs geht doch über's Gateway?

Was ist denn genau das Ziel? Proxmox hat erste Wan IP, du bestellst ne zweite und die soll direkt auf der OPNsense VM landen? Dann ist es genau wie @meyergru und Patrick sagen. Da muss dann ne separate MAC für die zweite IP definiert werden, die zweite MAC stellt man in Proxmox an der OPNsense VM ein und zack sollte die VM (testweise) per DHCP die IP bekommen ohne Probleme. Würde die aber natürlich dann statisch konfigurieren. Bei nem Dedi steht man normalerweise mit der zweiten IP im gleichen /24er wie der Dedi vorher auch und hat daher das gleiche GW. Ist zumindest bei meinem so, da funktioniert das bestens.

Verstehe da gerade die Logik nicht in der Sense beide IPs zu haben? Vielleicht magst du das kurz erklären, was das wird?

Cheers :)

Leider konnten wir die Download-Latenz aufgrund der Natur von 5G nicht dauerhaft unter 10ms halten. Ein großes Danke an Seimus für die Hilfe dabei, den Sweet Spot zu finden! :D"

Ja Latenz wird bei LTE/5G oft unterschätzt. Ich hatte auch einige Kunden, die meinten es wäre vllt. eine gute Alternative als Hauptleitung (schnell), weil sonst nur langsames kleines DSL verfügbar war. Lief aber meistens eher semi gut. Latenz zu hoch und gerade in Hotspot Locations war dann zur Mittagszeit bspw. "Schulschluß" dann plötzlich keine Bandbreite mehr da. Da das GW aber nicht down geht, sondern nur die Bandbreite und Latenz runtersacken, klappt da auch nicht wirklich gut ein Umschalten auf die andere Leitung. Darum auch meine Empfehlung 5G/LTE nur als absoluten Fallback zu nehmen wenn nichts anderes mehr klappt. Zu unzuverlässig. :)

Aber super dass ihr das besser hinbekommen habt!

Cheers!

Ich habe hier noch zwei USB-Netzwerkadapter (1x 2,5G und 1x 5Gbit RJ45). Damit könnte ich die igc-Ports testweise umgehen, um zu sehen, ob der Fehler eventuell am Treiber der Intel-Ports liegt. Oder um den oben erwähnten Test durchzuführen.

Äh nein. USB NICs sind prädestiniert dafür mieserabel zu funktionieren und machen mehr Ärger als irgendwas. Da würde ich für irgendwas halbwegs produktives WEIT die Finger davon lassen :)

def1 kann man entweder vom Server pushen oder auf dem Client einstellen. Bei OpenVPN geht beides. Du musst den "alles in den Tunnel" Kram nicht zwingend auf Serverseite einstellen. "Standard" würde das wahrscheinlich tun aber durch Änderung der default route. Irgendjemand hat aber vergessen in der Liste def1 mit aufzunehmen. Genau wie die restlichen Cipher in der Liste fehlen und nur die default cipher enthalten sind, warum man aktuell keine alten VPN Verbindungen auf Instanzen machen kann :(

Du kannst aber def1 problemlos auf der Gegenseite konfigurieren. Wenn das nicht geht, kannst du alternativ entweder im Server konfigurieren oder für deinen Tunnel-Peer einen Client Spezific Override anlegen (braucht man bei TLS Tunnel eh) und dort bei "Local Network" 0.0.0.0/1 und 128.0.0.0/1 anlegen. Das ist das, was def1 tun würde. Statt 0.0.0.0/0 (default route) umzurouten, wird statt dessen das Netz in 2 Hälften gesplittet (/1) und das geroutet. Hat den Vorteil, dass der Client seine Default Route nicht verliert und da genauere Routen die ungenauen stechen, haben die 2 neuen Vorrang und routen alles über den Tunnel.

Cheers

Weil evtl je nach deinem Setup:

* ZFS da ist und ZFS für /var/log ggf. inline compression nutzt und df deshalb was anderes reported als faktisch der Fall ist?
* Weil das Disk Widget im Screenshot sich nur auf die physikalische Platte/SSD bezieht und nicht auf ein tmpfs mount? (kann man im Widget ja einstellen was angezeigt wird)
* Weil das evtl einfach nur im RAM rumeiert (RAM Disk aktiviert?)

Da bräuchte man ein paar Infos mehr.

Cheers :)

Block
in
Quelle: any
Port: any
Ziel  invertiert RFC1918
Port: any

Hö? Was tut das? Alles was nicht lokale Netze sind verbieten? Das wäre dann ja "fast" Internet, das macht ja keinen Sinn, wenn man danach wieder Internet erlauben will und es vorher aber verboten hat? Was soll das invertieren?

Zudem: Alles was auf LAN Seite geblockt wird würde ich SEHR empfehlen mit "Reject" zu machen, nicht mit Block, damit eine sofortige Ablehnung kommt und keine Minute oder zwei auf nen Timeout gewartet werden muss. Das verzögert Clients massiv, wenn die gegen sowas laufen.

Und: Source Any würde ich auf internen Netzen nie machen, sondern immer das entsprechende Subnet auf dem ich bin. Also in dem Fall "LAN subnet".

Meine Frage ist daher mit welcher eleganten Lösung ich dem Client möglich machen kann, trotz Rebind Schutz Kontakt zu KIM+ aufzunehmen (siehe Bild). Und warum funktioniert nicht das Löschen des Netzwerkes CGNAT (100.64.0.0/10) aus der Einstellung von unbound wo die Rebind Schutznetzwerke definiert sind?

Weil vielleicht gar nicht der Rebind Schutz das Problem ist? Schau mal in die DNS logs oder erhöhe den Log Output von Unbound um zu sehen WAS das Problem ist und gehe nicht einfach davon aus, dass es der Rebind Schutz sein muss. Das wäre ja nur dann aktiv, wenn man sowohl eine Antwort mit public IP als auch eine mit privater/geschützter bekommt und nicht einfach NUR wenn es ne interne IP wäre. Sonst würde bspw. Unbound ja auch zur Firewall IP selbst null Auskunft geben.

Ich würde raten, dass es ggf. eher daran liegt, dass Unbound kein sauberes Bein hat mit dem er zum Telematik Kram telefonieren soll. Du könntest daher mal als "Workaround" in den unbound Einstellungen das "ausgehende Interface" auf LAN stellen. Klingt kontraproduktiv, aber das zwingt Unbound eigentlich, als abgehende Adresse ne interne IP zu nutzen, die ggf. in deinem IPsec Tunnel erfasst ist und geroutet wird anstatt sich auf das VTI Netz zu binden und ggf. das dafür zu nutzen. Klappt meistens bei reinen Phase2 IPsecs sehr gut um das zu umgehen. Evtl. genügt das schon.

Cheers

[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 :)