Messages

So ganz versteh ich es noch nicht, wie ich in der OPNsense die zweite WAN-Schnittstelle reinkrieg. Wo genau kommt die zweite MAC in der OPNsense rein? Hab ja derzeit nur zwei Schnittstellen WAN und LAN.

Ich versteh nichtmal wo du ne 2. WAN Schnittstelle siehst oder hinbauen willst. Irgendwie macht das Setup für mich vor Augen ohne Netzplan gerade 0-Sinn *grübel*

Du meinst, es ist nicht offensichtlich, dass "meinedomain.lan" ein Platzhalter ist? 🤯

leider nicht :/ Darum dachte ich lieber, ich "korrigier" es mal bevor sich das jemand beim Drüberlesen ins Gehirn meißelt und denkt, es wäre ne gute Idee ".lan" als TLD zu nutzen, weil das jemand so geschrieben hatte. Ich weiß, es nervt, ich fühle es :)

Und um das Raten mal zu beginnen: Hatte die alten Installation eventuell bereits die Tuneables für neuere Intel-CPUs (Alder Lake oder Nxxx) installiert, die bei der frischen Installation fehlen und Probleme bereiten - insbesondere, wenn man nicht, wie empfohlen, auf ZFS, sondern auf UFS installiert?

Auch noch ein guter Punkt. Wurde UFS oder ZFS installiert. Alles relevant!

Verstehe das Drama in der Benennung trotzdem nicht. Im Gegensatz zu manch anderer Firewall ist ja bei den Sensen das Alias an vielen Stellen trotzdem einsehbar oder über Tooltips der Inhalt erkennbar. Selbst bei großen DC Setups hab ich jetzt noch keinen Kunden gehabt der Hände über dem Kopf schlagend sich über Limitationen von Alias oder Gruppen Interfaces beschwert hat. Vor allem wenn man schonmal bei Juniper und Co da saß und wegen einer Namens/IP Änderung einer MIB ALLES bei dem die MIB eingebaut ist rückbauen musste nur damit man das Ding löschen und neu anlegen kann. In den Sensen geht man hin und ändert das Alias oder die IP und fertig.

Namenskonventionen kann man viele finden oder sich bauen. Dass man da zwingend ein Prefix/Subnet in den Namen einbauen muss halte ich für vermessen. Das klingt eher nach "soll jemand bedienen der so gar keinen Bezug zur Firewall hat und sonst nichts versteht". Und wenn das der Punkt ist, ist es vllt. doch sinnvoller, wenn man die API nutzt.

Ansonsten bin ich echt überrascht sowas zu lesen. Noch nie vorgekommen in zig Jahren in denen wir *sensen machen.

Cheers :)

Hi,

ohne irgendwelche weiteren Details oder Logs oder Fehlermeldungen wäre das lediglich munteres Probleme-raten. Das wird vermutlich eher weniger hilfreiche Antworten produzieren.

Was heißt denn z.B. auch "bleiben hängen und werden nicht abgeschlossen"? Von der neuen SSD mal einen kompletten SMART Test oder Disk Check gemacht?

Ansonsten kann ich da leider wenig helfen ohne mehr Details.

Cheers :)

Was ist denn die eingestellte Domain der OPNsense? Da solltest du nicht .local benutzen sondern z.B. meinedomain.lan oder so etwas. Unter dieser Domain werden die Hostnamen Test1 und Test2 dann ins DNS eingetragen.

Patrick, sag doch sowas nicht, das bleibt ewig online ;) und dann heißt es wieder "das hat aber jemand gesagt ich soll das so machen". Bitte nicht irgendwelche ausgedachten TLDs für internen Betrieb nehmen.

Für zu DNS/Domains sollte man entweder:

* eine echte Domain/TLD verwenden - dann klappt auch der ganze Geraffel rund um DNS, Zertifikate und Co gut und ist problemlos zu automatisieren
* wenn schon eine "ausgedachte" Domain, dann bitte entweder mit der TLD/Endung:
  - .test       was explizit dafür gedacht ist zu testen/ein Labor zu sein
  - .home.arpa  was explizit reserviert wurde für interne/home Domains
  - .internal   was seit Anfang des Jahres jetzt auch offiziell ratifiziert wurde, dass das ein geschützter Domain TLD Suffix ist, der NICHT öffentlich reserviert werden darf.

Gut es gibt noch .example und Co, aber das ist nicht für halbwegs produktive Home/Lab/Spielumgebungen gedacht.

Du zitierst die Theorie der RFC und hast damit teils auch recht geht aber an dem vorbei was ich als Problem bezeichne.
In der sollte natürlich der DNS genommen werden der schneller antwortet. WILL ich aber nicht. Ich will das der Lancache die erste anfrage bekommt und sollte der nicht erreichbar sein soll die Anfrage an die OpnSense gehen.
Fakt ist das es mit ISC tadelos funktioniert hat die reihenfolge festzulegen!
Und das die Windows Clients das ALLE in meinem Netz auch so übernommen haben. DAS IST FAKT.
Es geht also nur mit KEA NICHT.

Das stimmt so leider nicht. Das mag jetzt aktuell genau für dein Windows der Fall sein. Die Auslieferung von 2 DNS Servern ist aber trotzdem Client-abhängig, wie die Auflösungs-Reihenfolge ist. Windows macht SEHR oft genau das was du denkst - es nimmt den ersten DNS und ansonten den zweiten wenn der zu lange braucht. Das ist aber Windows jetzt. Alte Windosen oder andere Systeme handeln NICHT zwingend so, denn was die tun liegt an der Art und dem Typ der DNS Konfig, die sie nutzen. Linux damals anders als Linux heute, SYSVINIT anders als SystemD und selbst bei heutigen Systemen kann man es anpassen oder anders einstellen bzw. ein Windows-Update und dann ist es plötzlich eben nicht mehr "nacheinander", sondern parallel wie es viel andere Systeme auch handeln. Du kannst dich eben genau NICHT darauf verlassen, dass die 2 DNSe in einer spezifischen Reihenfolge abgearbeitet werden, darum geht man auch immer davon aus, dass beide gleichberechtigt sind und entsprechend abgefragt werden können. Wenn man das nicht möchte, wird nur ein DNS gepusht - dann aber eben mit Risiko dass der dann tot sein kann, wenn was schief läuft.

Die einzige Art das gezielt und definiert zu 100% sicherzustellen ist es über DNS Loadbalancing zu realisieren, bei der der entsprechende LB dann prüft, welche DNSe verfügbar sind und diese dann in gezielter Reihenfolge befragt. Alles andere ist einfach ein "ja passt schon, kann klappen oder eben auch nicht". Was du als Fakt ansiehst, ist lediglich Zufall.

Cheers :)

Die Antwort hängt davon ab:

* was die Remote Seite für eine IPsec Konfiguration hat: VTI oder normale Phase 2 Logik?
* was die Remote Seite für Remote Netz konfiguriert hat. Das bestimmt, was du selbst eintragen kannst.

Wenn es wie ich vermute ein normales P2 ist und Remote das /28 konfiguriert hat als erlaubt, wäre es kein großes Problem ein NAT mit .184.0/24 via .100.97/32 zu bauen, das klappt dann aber natürlich nur ausgehend auf die andere Seite rüber, weil dann ja alles wie auf dem WAN über ne einzelne IP geNATtet wird. Wenn bestimmte Geräte aber von Remote erreichbar sein müssen, wirds kniffliger.

Dann wird aber auf jeden Fall zusätzliche Security Policies für IPsec gebraucht, sonst würde der IPsec nur traffic von der /32 aufsammeln, du willst ja aber, dass der 184er/24 eingesammelt und via VPN verschickt wird. Daher muss das Ursprungsnetz als zusätzliche Policy rein und in die eigentliche Phase das "vorgegaukelte" /32 als lokal. Und dann natürlich noch nen NAT was ausgehend den Kram via IPsec auf die /32 umsetzt.

Aber das ist wie gesagt abhängig, was wirklich eingestellt ist.

Cheers :)

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!