Messages

Das Problem ist hier eher der Treibersupport für das unterliegende OS (FreeBSD). An der Front (WiFi) steht Linux einfach wesentlich besser mit dem Support da. Natürlich kann das CP genutzt werden, aber (any)sense als Access Point würde ich subjektiv nur in Ausnahmefällen tun. Schon allein weil dein Gateway/Firewall meist nicht unbedingt am optimalen Platz für die Abdeckung als AP steht, halte ich wie monster und andere einen externen AP für wesentlich sinnvoller. Gerade neuere Standards und bessere Abdeckung wird man so eher erreichen als ein all-in-one Device zu basteln. Es hat durchaus einen Grund, warum die FritzBox bspw. ein gutes all-in-1 Gerät ist, aber trotzdem eben alles nur ein wenig - nichts aber perfekt kann. Wer sich zu an zu vielen Kriegsschauplätzen beteiligt wird eben leider oft aufgerieben ;)

Viele Grüße

Hi Robert,

ich denke das was ich dir zu pfSense geschrieben habe, lässt sich 1:1 auch auf opnSense anwenden ;) Dazu hast du in deinen Anforderungen zu wenig wirkliche Showstopper, die auf einem System besser laufen würden :) Die Punkte die du listest, inkl. der DNS Geschichte, sollten hier relativ gleich umsetzbar sein wie auf pfSense ebenfalls. Der Rest ist deine Entscheidung.

Grüße

Aloha,

versuche es doch über deinen internen DNS:

Dienste / DNS Forwarder (oder Resolver)

und dann die Adresse fritz.box als Host-Override eintragen auf die IP, auf die die FB intern hört und die du erreichen kannst.

Grüße

Joking aside; common to most FOSS companies, OPNsense is offered on a commercial basis and for free as a community supported product. Both serve distinct audiences and are legitimately separated, no better or worse than that between something like CentOS and Red Hat Enterprise Linux.

Bart...

G'morning :)

It is indeed offered on a commercial base, but in that case, most OSS projects/products distinct that via .com vs .org. Also I don't see the opnsense.org website as a commercial website per se, but a project website. And as this links to either the wiki or the forums, it would be helpful, if there were a link back to the project site - if only to help get to the downloads faster ;)

If I may, I'd recommend an approach similar to what many project or company websites do and bring some sort of CI into play. Forums and Project site already share a similar menu bar on top. If implemented in the wiki as well (maybe fade it out when scrolling down), you could easily place links to the three subsites there and have better usability :)

Greets
Jens

Ahoi,

auch wenn ich (noch) nicht ganz in der opnSense Welt anheim bin, müsste das wie folgt funktionieren

* LAGG erstellen aus den beiden Interfaces die du bündeln willst -> lagg0 (bspw.)
* VLANs auf dem LAGG0 Interface erstellen
* Schnittstellen / Zuweisung
  - vlan x auf lagg0 hinzufügen
  - vlan y auf lagg0 hinzufügen
  - ... usw.

Das lagg0 Device selbst (also untagged) braucht nicht hinzugefügt werden, es sei denn auf dem Interface ist mit untagged Paketen zu rechnen, was man aber vermeiden sollte (wenn mehrere VLANs tagged auf einem Interface/Bond, dann auch nur tagged).

Sobald die Zuweisung gespeichert ist, kannst du jedes VLAN wie ein "normales" Interface mit eigener Konfig-Seite konfigurieren.

Bei deinem CARP Cluster muss die zweite Maschine natürlich komplett identisch aussehen und auch genauso eingerichtet werden. Die VHIDs (!) sind nicht mit VLAN o.ä. zu verwechseln, die spielen eine ganz andere Rolle. VHIDs müssen lediglich in ihrem Netzsegment (Broadcast Domain) eindeutig sein. Sprich in jedem Netzsegment (deine VLANs, das WAN etc.) darf nur ein HA-Paar mit VHID 42 (bspw.) unterwegs sein, ohne Probleme zu machen. Da die VHID mit dazu herangezogen wird die virtuelle MAC Adresse der CARP VIP zu erstellen würde es sonst Probleme auf ARP Ebene geben. Wenn du aber alle Netzsegmente kontrollierst kannst du auch entspannt bspw. für die CARP VIPs aller verschiedenen VLANs die gleiche VHID nutzen. Es darf wie gesagt nur in diesem Segment kein andere HA Setup mehr die gleiche VHID verwenden.

Grüße
Jens