Messages

Probiere ich heute Abend, übrigens habe alles vorbereitet wie hier steht https://www.du-consult.de/opnsense-so-konfiguriert-man-eine-deutschlandlan-pppoe-einwahl/ denke wird alles passen oder gibt's irgendwas zum korrigieren.

BTW: Das ist ein 4-5 Jahre alter Blog. Bitte Leute, hört auf irgendwelchen alten Mist als Basis für ne neue Installation ranzuziehen, nur weil da vielleicht ein Keyword drinsteht, das bei euch passt (Deutschland LAN, PPPoE keine Ahnung). Dafür gibts Doku, Wiki, Forum. Und dann kann man sich aus sowas vielleicht noch die letzte Info holen, wenn alles nicht geht. Aber nehmt nicht steinalte Blogs mit Jahrealten Versionen als Installationsanleitung "so wirds gemacht", dazu ändert sich jedes Jahr viel zu viel in der Software. Zumal in dem Blog jetzt auch wirklich so gut wie nichts drinstand, was nicht eh in der Doku oder hier im Forum gestanden hätte.

Cheers

Das habe ich auch schon Probiert und gelesen, Danke, leider erfolglos,... Ich lese nur immer öfter das es mit der i226-V Ethernet und Freebds zu tun haben soll.

Nachdem wir erst Freitag jemand in der Usergroup hatten, der ebenfalls Probleme mit Speed hatte und bei dem es eine alte N4505 Intel Box (Version vor dem N100) war und sich dann schlicht rausstellte, dass da Limiter auf dem WAN waren, die noch vom DSL eingestellt waren auf 200-240Mbps und deshalb kein Gigabit durch gingen, gehe ich hier wie @meyergru von nem anderen Problem aus. Der i226 in FreeBSD ist es auf jeden Fall nicht, der ist so weit verbreitet, da müsste es schon ein sehr sehr spezifisches Problem beim @OP sein, dass es an dem liegt. Und für den Speed muss ich auch im Normalfall nicht noch dutzende Tunables setzen. Für die letzten Quentchen vielleicht, aber wir reden hier von 100/20. Nicht von 1000/50 - da würde ich das vielleicht noch verstehen. Aber wenn ich für knappe 100 Mbps irgendwelche Tunables setzen oder Sprünge durch den brennenden Reifen machen muss, dann würde ich SEHR verwundert sein ;) Das bisschen Leistung bringt eigentlich jede alte Kiste noch aus dem Kreuz geleiert :)

Ich sehe zwar bei 100 ehrlich gesagt auch kein Buffer Problem aber vielleicht frisst der Magenta TV Kram so viel in die Bandbreite, dass es hier ne Rolle spielt. Daher mal testen und dann ggf. mal mit Shaper versuchen. Wenn du mit dem Magenta Modem Dingens unsicher bist, notfalls irgendnen kleinen Switch zwischen Sense und den Magenta Kram werfen um seltsame Interface Effekte mit der Kiste auszuschließen. Aber die meisten Modems und Kram reagieren eher sehr "MEH" auf festgesetzte Interfaces - das würde ich stark vermeiden.

Cheers :)

Ich verstehe da ehrlich gesagt gerade gar nicht wo das Problem liegt oder herkommt. Ob man im Unifi Controller jetzt alle Interfaces tagged/untagged etc. reinwirft oder nicht, ist nur Nomenklatur. Ob Trunk oder nicht Trunk. Ich kann bei meinem - ebenfalls ein Pro Max 16 PoE - problemlos ein Interface hernehmen, da 3 Ports Tagged draufwerfen OHNE untagged Definition und damit einen reinen Trunk bauen. Muss man nur richtig einstellen (native nichts, tagged die VLANs oder all oder whatever - fertig).

Ich bin durch die Beschreibung etwas verwirrt, was jetzt eigentlich wo wie angesteckt ist und wo konfiguriert ist. Ich glaube eher da liegt gerade das Problem, denn Switch, OPNsense und irgendwelche Hosts mit VMs sind jetzt keinerlei Problem weder von der Sense noch von der Unifi Seite her. Daher gehe ich stark davon aus, dass @OP hier einfach was mit der VLAN Definition vermixt hat und es deshalb nicht funktioniert.

Es wäre daher hilfreich zum Weiterhelfen:

* Wo hängt das Laptop, an welchem Port, wie ist der in Controller konfiguriert
* Woran hängt die OPNsense, wie ist der Port im Controller konfiguriert
* Wie ist die OPNsense und ihre VLAN Interfaces konfiguriert
* Wo hängt der Debian VM Kram mit dem Unifi Controller und wie ist dessen Port konfiguriert und/oder hängt der direkt an der Sense?

Was dabei an was hängt war gerade das größte Fragezeichen, also was hängt eigentlich genau alles an der Sense und was am Switch. Das hatte nämlich den Unterton davon, dass da Interfaces sowohl an der Sense als auch am Unifi Switch doppelt hängen ohne Bridge auf der Sense und das wird dann ziemlich chaotisch ;)

Cheers
\jens

Da anscheinend nicht ganz so klar war, dass das einfach so weiterläuft, hab ich das im Startpost nochmal editiert und auch die Alternative URL mit eingefügt, wenn mal die Weiterleitung klemmt.

@Patrick: Könnte Freitag der Caddy auf der Sense gewesen sein, der da zwischendurch mal Schluckauf hatte, der Domain-Referrer läuft auf meiner externen OPN Kiste. Wenns wieder vorkommt gern aufschreiben, dann kann ich vllt. in den Logs mal sehen, warum der einfach nicht weiterleiten will.

Aber dann kann man im 3. Oktet so schön Semantik ... *duck und wegrenn* :-)

Das mach ich mit den VLANs auch, geht trotzdem, hat man nur ein wenig mehr Planungsaufwand vorher ;)

D.h. wenn man die Möglichkeit des Login ohne 2FA aktiviert lässt, kann auch jeder andere Admin-Account diese einfach weg lassen.

Oh stimmt, bei Local wird das der Fall sein, da hast du recht. Ich war im Kopf von zweitem Provider via LDAP/Radius + TOTP ausgegangen, dann bleibt natürlich Lokal noch eine non-TOTP Option. Aber beides Lokal wird der non-TOTP natürlich alles zunichte machen. Damn, da sollte man für Local+TOTP sowas wie Group-Binding anlegen, dass man das an Hand der Gruppe ggf. erzwingen/selektieren kann.

Kollege hat zuhause auch überall /16. Er plant mit mehr als 256 IoT-Geraffel-Dingern pro VLAN. Jeder Lichtschalter, jeder Rolladen, jede Steckdose, ... großes Einfamilienhaus.

You do you, aber nope. Ich seh das aus IPv6 Sicht. VLANs als kleine Gruppen < 200 Geräte. Weil sonst mit einem falschen RA/IPv6 Call zu viele Devices auf einmal umfallen. Da kann man gern steckdosen, Licht und Rolläden machen, aber die bekommen trotzdem keine /16er :)
Vorher würde es mehr Sinn machen, die nach Typ in eigene VLANs zu packen und als IF Gruppe anzulegen und zu handeln. Aber hey, ich muss es nicht debuggen ;)

haben wir beide Systeme durch zwei DEC3852 ersetzt.

Ah also ein Cluster?

treten gravierende Routingprobleme auf

Habt ihr den alten Cluster auch noch am Start? Habt ihr die VIPs im Cluster neu konfiguriert? Andere VHID oder gleiche? Nutzt ein anderer Cluster ggf. die gleiche VHID der VIP? CARP/VRRP/HSRP und die zugehörige ID darf im gleichen Netzabschnitt nur EINMAL vergeben sein. Da hatten wir schon die tollsten Probleme, wenn die doppelt vergeben waren.

Ansonsten braucht es mehr Details, Logs etc.

Cheers

Klingt danach, als würde die Zeit ggf. nicht stimmen, dadurch ist der TOTP den die Firewall berechnet anders als der, den du mitgibst und damit falsch. Darum rät man nicht umsonst, einen Admin/Root Account zu machen mit "Brachialpasswort" (laaaange und komplex) und den im Tresor zu werfen, damit man einen Weg hat, der nicht an irgendwelchen Dependencies hängt um sich Notfalls einzuloggen.

Eventuell sind nach dem Update Crowdsec oder Zenarmor oder was anderes am Ausrasten, blockieren ggf. Verbindungen oder NTP und damit bekommst du keinen Zugriff. Das wäre zumindest eine Hypothese. Wenn du keinerlei andere Möglichkeit des Logins hast, wird das ggf. tricky.

Cheers

Es ist ein 16er Netz, also 10.20.0.0/16. Die IPs beginnnen ab 10.20.1.0/16. Nichts seltsames dabei glaub ich :)
Ich hab auch kein 24er Netz mehr.

Also ich fände /16 durchaus seltsam. Keins meiner VLANs hat ein /16, das wäre kompletter Overkill. Verstehe nach Lesen deine Interfaces und IP Ranges leider gar nicht. Mehrere VLANs aber dann /16 und irgendwas mit Sortingnetz als 3. Oktett? Klingt irgendwie nach selbstgebautem Problem mit dem IP Range und den Interfaces. Da ich dazu in keinem Post mehr Details finde, wäre da aber alles nur raten.

Hi,

Tests sollten eigentlich immer HINTER der Firewall durchgeführt werden. Die FW selbst ist nicht für Zugriff, Download etc. optimiert, sondern als Router, also schnellstmöglich Daten "drüber" zu schaufeln und nicht auf sich selbst. Darum finde ich checks, egal ob Speedtests oder iperf und Konsorten immer schwierig zu bewerten, wenn sie auf dem Gerät selbst gemacht werden. Das dürfte auch mit reinspielen, warum du da bei anderen Methoden unterschiedliche Ergebnisse bekommst - andere Optimierung. Das sagt aber per se noch nix über dein Problem mit Puffern aus.

Ich würde daher aus dem LAN und der DMZ jeweils mal Speedtests machen zu unterschiedlichen Zeiten und sehen, was da ankommt.
Persönlich hab ich als 2. Leitung auch ne Vodafone Kabelleitung, die aber von O2 vertrieben wird (ist aber VF drunter), die seit einigen Wochen auch täglich Probleme hat. Es geht in die Feiertagszeit und Kabel ist (zumindest bei uns) gnadenlos überprovisioniert und hat ständig Aussetzer und Kapazitätsengpässe. Darum würde mich das nicht wundern, wenn es überhaupt nicht an der Firewall, sondern an VF liegt, aber erst mal testen und dann noch mehr testen und dann sehen, obs daran liegt.

Cheers :)

Der Workaround ist, ausschließlich "Trap" zu verwenden, also auch in den DPD und weiteren Actions.

Workaround, OK. Aber das ist ja ne zentrale Komponente und das ist seit August offen und Ad hat trotz @ im Ticket nicht drauf reagiert. Tut sich da noch was, oder muss man das wieder als "Workaround vorhanden, muss man wissen" sich irgendwo ablegen, damit man bei Kunden das korrekt einrichtet? Das kann ja als Bugfix nicht so schwer sein zu checken, dass man auf dem Standby ist und dann "start" zu ignorieren weil "habe die VIP nicht". War vorher möglich, sollte jetzt auch so sein, oder? :)

Cheers

I have never encountered any compatibility problems with 10G DAC cables.

Sadly I have. Some switch manufacturers are pretty crazy these days with DAC compatibility. Ubiquiti is not one of them though, I got gifted 2 unused DACs from Netgear stuff someone threw away and those had no problem working within a Unifi switch and a OPNsense test hardware. But Unifi SFP(+)s are quite reasonable when it comes to pricing plus with their SFP programmer hardware it shouldn't be hard to make the necessary "changes" to a module to make it ... say more "appealing" to specific switch vendors if needed ;)

And yes, I almost had the same setup in my lab at one point, just with the older USW-8-Enterprise-PoE but the setup works. One SFP+ to the firewall one to another server (or switch - the 8-port aggregation is really cheap for that) and you're ready to play around with 10G LAN stuff.

Cheers

Dann hast du nicht gelesen was ich geschrieben habe. Ich mache für alles "LAN net", den Rest sehe ich als "Default Block" Verstöße und die fallen auf, weil es sie nicht geben dürfte. Weniger Logspam und Logs gehen nicht im Rauschen unter, weil dann NUR Sachen gegen Default Block laufen, die im Netz nichts zu suchen haben. Alle legitimen (LAN net) werden durch die eigenen Regeln geblockt. Dadurch einfacher filterbar. Das war nicht das was du schreibst, darum meine Erklärung :)

Vereinfachtes Beispiel in Grafik: Erlaube diverse ICMPs, rejecte alles interne + reservierte IPs, erlaube Rest aka Internet. Ja könnte man kombinieren, nein mache
ich nicht (sonst kann man das Loggen für die Rejects nicht einfach an/ausschalten) :) Wenn jetzt einer deiner genannten Fälle kommt: falsche Source IP weil Bot, manuell vergeben, APIPA o.ä. -> wäre sofort ersichtlich in Firewall Logs weil als default block auftauchend. Wird aber nicht mit Reject Regel verwechselt, bei der es um legitime Clients geht, die ggf. noch irgendwo hin wollen, wo sie jetzt nicht mehr dürfen, weil bspw. gerade Netztrennung noch frisch durchgeführt. Dadurch weniger Overhead/Logspam, weniger was der Admin durchsuchen muss. Und wenn ich das Log anmache wirds mit eigener ID geloggt und kann nicht mit "rogue Clients" verwechselt werden.

Macht am Ende jeder selbst so wie er möchte, ich habs nur erwähnen wollen, warum es IMHO Sinn macht, es so zu tun :)

Moin,

auch wenns schon etwas her ist:

Jedes vLAN Interface hat auf beiden Nodes eine Separate IP
Node1 10.x.x.251
Node2 10.x.x.252
CARP IP 10.x.x.1

Ist bei jedem Netz etwas anders da die Netze mal kleiner mal größer als /24 sind.

Ich würde bei CARP versuchen alle Netze gleich aufzusetzen. Also vllt. .1 als GW, .2/.3 als Nodes. Dann entfällt die Sucherei, welche IP in welchem Netz das jetzt ist und die Größe ist egal. Weniger fehleranfällig. Vor allem wäre das Arbeiten auf dem primary fix immer auf bspw. der .2.

Config sync getestet, und festgestellt das nicht alles übertragen wird. Einige Setting´s müssen manuell auf der Backup Node gemacht werden.
Ok nicht schön aber ist halt so.

Das ist aber korrekt. Vielleicht nicht ganz User-friendly aber Faustregel: alles was "Hardware" ist (also Interfaces, IF Gruppen, IP Konfiguration etc.) ist pro Node zu konfigurieren. Alles was Regelwerk, PF und Co. sowie diverse Services betrifft ist sync-bar. Aber besser nachschauen, ob der Service XY da nicht spezifische Einstellungen für hat oder eben nicht gesynct wird. Bei Zusatzpaketen ist das zB nicht immer der Fall.

Jetzt ist mir beim weiteren einrichten und nach 3 Monaten betrieb aufgefallen.
Wenn die Backup Node übernimmt, wird die Session Tabelle nicht mehr auf die Master Node übertragen.
Sie schaltet einfach zurück.
Und die Master Node blockt dann erst mal jeglichen Taffic da sie keine Sitzung dazu kennt.

Sync nicht korrekt konfiguriert? Auf dem Backup Node nicht den "General Settings" part ausgefüllt? Ohne wird kein State Sync zurück gemacht.

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

Eventuell Verbanne ich die Subnet Routing Funktion ganz von der Firewall auf eine VM irgendwo

Das wäre tatsächlich bei einem Cluster praktischer. Nicht nur wegen der NAT Thematik, sondern auch wegen der Regelerstellung. Bei zwei Nodes auf Firewalls die aktiv sind, wäre es sonst fürs Routing sehr verwirrend, über welchen Node die IPs gehen und von der aktiven FW und Routing Node dann auf die passive kommen - ohne die Tailscale eigene IP zu nutzen - wäre dann ähnlich wie bei OpenVPN/WG Einwahl problematisch und bräuchte wieder einen NAT Workaround.
Darum wäre es vermutlich die geschickteste Idee die zusätzlich noch den Nutzen hätte, dass die Regeln einfacher und geschickter definiert werden können wenn man ein extra VLAN mit ein/zwei Tailscale Nodes dahinter macht (betrifft 1:1 auch das Netbird Setup BTW, funktioniert dort ja sehr ähnlich).

Als ich jetzt die Obigen HA Tests wieder gemacht hatte. War das verhalten extrem anders

Frage vorab: Hast du denn den Config Sync aktiv bzw. als Cronjob eingerichtet? Ansonsten WICHTIG: OPNsense macht KEINEN aktiven sofortigen Sync mehr. Seit längerem. Ich fände es zwar nach wie vor schön, wenn sie das als Option wieder einbauen würden, aber der Config Sync findet IMHO aktuell NICHT automatisch statt. Du brauchst also entweder nen zyklischen Cronjob der das übernimmt oder du musst manuell nach Änderungen wieder syncen, sonst passiert da nichts.

Dass dann im Betrieb die Firewalls auseinander driften in der Config und dann bei einem Failover sich vllt. sehr schräg verhalten ist leider dann kein Wunder. Das hat auch schon viele Kunden von uns getroffen, die von der Beschreibung "Sync" her einfach nicht erwarten, dass das was "Manuelles" ist oder man das nochmal extra als Cron einrichten muss, sondern dass Änderungen eben sofort gesynct und übertragen werden.

Ansonsten ist CARP/HA immer ein wenig komplex und durch die Beschreibung weiß ich jetzt spontan auch noch nicht alles, was schief gehen könnte, daher waren das nur die Punkte, die ich denke man recht schnell sehen kann. Ansonsten bräuchte man da mehr Details oder - wenn du eh schon drüber nachdenkst was anderes einzusetzen - wäre es vielleicht sinnvoll, das im Sinne von Support-Einkauf sich komplett anzusehen.

Cheers
\jegr