Messages

Sicher, nicht falsch verstehen. Aber gerade wenn ich die im größeren Stil einsetze - Nachhaltigkeit ist genau das Stichwort - muss ich auch sehen, dass weder ALIX noch APU noch supported sind. Beides EOL Plattformen ohne Ersatzteile. Allein damit argumentieren unsere Industriekunden schon, dass sie die Dinger loswerden wollen. Da brauche ich mit x64 gar nicht anfangen ;) Deshalb Software weiter für eine sterbende Randgruppe bauen, da kann ich das schon nachvollziehen. Und das Nano Image war jetzt auch nicht ganz so der Geniestreich. Er funktioniert ganz gut, aber eine Vollinstallation auf mSATA bspw. ist auch bei einer APU und APU2 immer noch angenehmer und wesentlich vernünftiger zu handhaben.

Aber klar, den Einsatzbereich wirds immer geben. War schon damals so mit pfSense und m0n0. Da gab es auch genug m0n0 Nutzer die einfach kleinere Kisten hatten und das genügt hat. :)

@Monster: Hast du vor auf der APU viel mit LTE zu machen? Ansonsten würde mich wundern, warum du das Alpha Board von pcEngines nutzen möchtest ;) Der einzige Unterschied zur APU2 (die noch lange nicht EOL geht) ist ja der Fakt, dass auf der APU3 Alpha/Test mehr SIM Slots eingebaut wurden um mehrere LTE Modems zu betreiben. Und man hat über einen PCIe Slot nachgedacht, der aber noch nicht implementiert wurde - zumindest m.W. :)

Ansonsten sind die APU2s sicher wohl das was man als günstigste Alternative zu Hause bekommen kann. Ein wenig kleiner und kompakter, dafür aber auch etwas teurer wäre da nur noch eine NCA-1010 von Lanner, die vergleichbar mit der APU2 arbeitet. Deren Nachfolger, die 1020 steht übrigens in den Startlöchern und bringt dann als SOC einen Braswell N3010er Zweikerner mit. Sollte sich dann doch etwas von der APU2/3 abheben können dadurch und ein wenig in die Lücke zu den Atom C2358/C2558 SOCs stoßen.

Ich hatte mir vor ca. 5 Jahren eine Lanner FW-7535 gekauft (viel zu teuer eigentlich aber 6 Intel Interfaces + Rackmount waren ZU verführerisch...) und die wird nun nach der langen Zeit wohl demnächst durch eine 7525 abgelöst - wieder mit 6 NICs und einem Atom C2558 drin. Der dürfte dann auch für Kabelnetze von 400MBit/s aufwärts keine Probleme bekommen :D Etwas übertrieben? Ja, für reinen Home-use schon, allerdings hab ich da tatsächlich auch mal Testnetze, Testsetups und mein eigenes Heimsetup dran, das etwas komplexer aufgebaut ist :) Daher durchaus legitim.

Grüße
Jens

Finde ich gut, da die Beiträge von JeGr gern gelesen hab!

Danke Dirk :) Das wiederum finde ich schön zu lesen. Wie gesagt haben wir (als Firma) zwar mehr mit der anderen Sense zu tun, was aber niemanden daran hindert über den Zaun zu schauen und auch beim Nachbarn mal zu helfen. Alle anderen Spielchen sind "not my paygrade" wie es so schön heißt und da halte ich mich privat einfach raus und möchte die weder hier noch dort propagiert haben :)

Was die 32Bit / Nano-Images angeht bin ich noch zwiegespalten, denn ich hätte auch nichts dagegen die sterben zu lassen gegen eine schönere Update Variante. Leider wird ZFS aber auf CF/SD wohl eher gruselig bleiben. Daher kann ich das schon nachvollziehen, wenn Heim- oder embedded User da dann sich ggf. opnSense zuwenden sollten. Allerdings gibts auch genug Plattformen, die bereits 64bit können und eine ALIX damals kostete auch nicht weniger / viel mehr als eine APU2 heute ;) Aufrüsten wäre da eigentlich sinnvoller als die Distro zu wechseln (rein zukunftsorientiert gedacht, nicht in Bezug auf welche *Sense). Gerade weil ich häufig höre, dass solche Systeme teils als AP oder VPN Client irgendwo eingesetzt werden, wäre neue HW mit AES da meist eh sinnvoll :)

Grüße
Jens

Ich versuche mich lediglich als neutraler Beobachter, auch wenn unser Fokus im Betrieb (Firma) bisher eher auf pfSense liegt. Nichts desto trotz: wie bei vielem bringt Konkurrenz auch mehr Fortschritt bei allen ;)

Wie gesagt, für das "wenige", was du als Anforderung hast, würde ich im Speziellen keinen Grund finden, das eine oder andere System zu nutzen. Beide decken ab was du brauchst und möchtest. Was du schlußendlich nutzt bleibt dir überlassen.

Grüße

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