Messages

Edit:

Was auch immer schief gegangen sein mag....

Beim Boot meldete sich weiterhin die 20.1. Also Update nochmals angestoßen und danach ging es.
Ich vermute, während des Updates ist irgendetwas schief gelaufen.

Hi Leute,

ich habe vor einer Stunde auf 20.7 upgedated. Seitdem funktionieren einige meiner VLan nicht mehr.
Ich komme zwar auf die Geräte (Raspberries) drauf, aber sie haben keinerlei Verbindung mehr ausserhalb ihres eigenen VLan.
Mit der vorherigen Version funktionierte noch alles.

Die Firewall rule habe ich testweise auf access to any gesetzt, aber auch damit kommen meine VLan nicht in andere VLan oder nach "draußen"

Ich konnte es zwar nun lösen, aber meine Lösung gefällt mir nicht wirklich.

Ich habe insgesamt 8  verschiedene VLan und das Gäste-VLan soll ausschliesslich auf die Internetschnittstelle zugreifen. Jetzt habe ich es derart gelöst, dass ich für jedes VLan eine Deny-Rule kreiert habe. Das GästeVLan darf zusätzlich noch auf Port 53 (DNS) des GästeVLan zugreifen. Als letzte Regel, falls nicht vorher eine Block-Rule aktiviert wird, kommt dann eine Allow to Any.
Damit läuft es nun und die anderen VLans sind vor Zugriff geschützt.
Nur darf ich für die anderen 7 VLan ebenfalls so verfahren, dass ich explizit blocken muss.

Ich hätte angenommen, mit einer Allow-Rule auszukommen; dies wäre a) Performanter und b) schneller umsetzbar.

Edit: Ein Deny auf einen 192.168.0.1/16 Alias klingt auch nach einer schönen Lösung. Das werde ich mal probieren. Danke banym

Hey Leute,

ich denke ich habe irgendwo ein Verständnis-Problem.

Folgender Aufbau:
OPNSense mit einem LAGG (2NIC) an einem Zyxel 24-Port-Switch (GS1900-24).
Auf dem LAGG sind mehrere VLan.
Zusätzlich hat die OPNSense noch einen NIC für Internet (Name "Internet"), ohne VLAn.

Ich habe zu Hause ein paar IOT-Geräte, bei denen ich nicht möchte, dass diese in meinem Netzwerk irgendwelchen Unsinn anstellen...sie sollen den Rest des Netzwerks gar nicht erst sehen. Daher habe ich diese Geräte im VLan99

Habe ich auf VLan99 nun eine Rule "Allow to Any" läuft alles, wie es soll. Baue ich nun eine Rule zusammen:
Allow Source VLan99 to "Internet Network" und nehme die "Allow to Any" raus, hat das IOT-Netzwerk keine Verbindung mehr nach draussen. Im Log sehe ich dann, dass immer die Default-Deny-Rule zum Tragen kommt.
Die "Allow to Internet" wird nicht ausgewertet....

VLan99 soll ausschliesslich mit der Internet-Schnittstelle komunizieren dürfen.

Wo habe ich meinen Denkfehler?
Da es mit der Allow-to-Any Rule funktioniert, vermute ich den Fehler in der Rule, für Kommunikation nur nach aussen.

Nunja, die Ansprüche sind halt unterschiedlich.

Ich für meinen Teil nutze das IPS; daher ist die Leistung mit aktiviertem Suricata schon ein Kriterium für mich persönlich.
Bei meiner derzeitigen Leitung reicht die APU.4 gerade noch aus. Spätestens im Winter muss sie einer leistungsstärkeren Hw weichen; ab da werde ich die APU.4 nur noch als eine interne Firewall zur inneren Netztrennung verwenden.

Meine OPNsense (19.1.3-amd64) läuft auf einem APU.4C4 Board. Im Dashboard-Graph zeigt die CPU kaum Ausschläge, die Auslastung des Arbeitsspeichers liegt ziemlich stabil bei 33%.

Willkommen im Club. Ich habe ebenfalls eine APU.4 (allerdings eine 4B4).
Einfach als Firewall läuft das Ding problemlos. Sobald allerdings Services wie Suricata, Clam oder Proxy laufen geht das Ding in die Knie.

Schau dir per SSH-Konsole mal die CPU-Auslastung per "top" an.... die geht bei der kleinen Kiste schnell durch die Decke. Der CPU-Anzeige im Dashboard traue ich da weniger... wobei ich auch dort oftmals Dauerhaft 100% Auslastung sehe.

Schalter bei dir mal den Proxy und Clam AV aus. Danach das Gerät neu booten... es sollte dann schneller arbeiten. (Ohne Reboot, scheint bei mir auch manchmal etwas zu "hängen", wenn ich Services deaktiviere)

Im Moment habe ich lediglich eine 14MBit-Internetleitung. Da geht es noch. Ende des Jahres kommt Gigabit; da werde ich andere Hardware brauchen. Die APU ist dafür einfach zu langsam (Wenn man mehr als nur die Firewallfuntktionalität haben möchte)