Messages

> Dann werde ich mich auch mal an Carp rantrauen. Aber da habe ich jetzt keine große Angst mehr

Angst muss man da auch keine vor haben :) Aber bei CARP zumindest ein wenig Planung und Fingerspitzengefühl und ein wenig Netzwerk-Ahnung. Da gibt es schon einige DO's und DON'Ts, die man beachten sollte, sonst fällt man da schon auf die Nase (Beispiele: VHID Vergabe, virtuelle MAC, Services auf CARP IP binden, etc.)

> Oh sicher dass das nicht geht? Wollte dann mit meinem Kali Linux System die SSD mounten...

Solange dein Kali Linux keinen FS Treiber für BSD und UFS Filesystem hat, wirst du nichts sehen. UFS und das BSD Disklabel System sind inkompatibel zu normalen MBR/GPT Partitionstabellen, da wird nichts erkannt.

Autsch, da hast du dir ja mit

error : interface opt1 not found
error : interface opt2 not found
error : interface openvpn not found
error : interface opt4 not found

wohl deine Interface Konfiguration zerbastelt. Zumindest scheint es so.
Mit deinem Adapter wirst du wohl aber nicht weit kommen, es sei denn du nutzt irgendwo einen FreeBSD Desktop. Das BSD UFS System kannst du nicht einfach unter Linux oder Windows einlesen.

Grüße

Wenn du keins vergeben hast, versuche doch einfach mal Enter? :)

> PfSense sehe ich eher als... ähm.. "altmodisch"?
Altmodisch? ;) Finde ich nicht. Gerade mit der Umstellung auf 2.3 und den Paketen jetzt, sind sie flexibler als vorher. Patch Releases wanns gebraucht wird, etwas größerer Sammlungen in Minor Releases und Steppings wie 2.4 wenn sich größere Sachen ändern sind vielleicht nicht neu und hip, aber altmodisch sicher nicht :) OK wir könnten die 2. streichen und machen einfach v3, v4, v5 etc. wie Chrome ;) das ist dann vielleicht hipper :D

> Zusammenfassend muss ich sagen, dass mir die "Security Patches" alle paar Wochen sehr gut gefallen
Dito, wie bei pfSense ebenso

> nur die Upgrades alle 6 Monate noch viel zu "erzwungen" wirken. Ich bin auf jeden Fall gespannt. :)
Jep, genau, da finde ich das noch recht überschaubare Team einfach entwicklungstechnisch überfordert bzw. gibt es einfach viele Probleme die durch beschränkte Test-Cases gar nicht entdeckt werden. Es wird eben allerlei Hardware eingesetzt und man kann nicht auf allem testen. Und so lange die Community noch klein und das Team ebenfalls (und jung), gibt es nicht so viele Rückmeldungen aus der Community was Testing angeht.

Mein Grund, warum "Pro OPNsense" ist folgender, ganz gleich der technischen Fakten:
pfSense kommt aus den USA. :) "National Security Letter" und "Gag-Order" sind uns allen ein Begriff. :)

Schöne Grüße
Oxy

Ist allerdings eine seltsame Idee. Natürlich kannst du eine Firma dazu verdonnern. Wird auch mit Google immer versucht, klappt trotzdem nicht wirklich. Noch dazu: Wofür sollen Sie einen NSL oder eine GO bekommen? Was einbauen was man nicht sieht? Im Sourcecode auf Github? Das wär schon ein wenig arg auffällig, zumal jetzt der erste 3rd Party Audit drüber lief. Und das auf der "bösen" Variante die auf der eigenen Hardware lief. Das Argument zieht für mich minimal bis gar nicht. Dann müsste ich auch instant andere Projekte beerdingen, die das Core Team oder einen Großteil Entwickler in den Staaten haben mit Firma dahinter. :)

Ansonsten dein Argument bzgl. Position: Momentan (und das ist wirklich nicht böse gemeint) sehe ich opnSense eher im SOHO Sektor. Mir laufen die ganzen Updates und der Stabilitätsfaktor nicht rund genug. 16.7 Installation war schon nicht schön (getestet mit 1:1 pfSense daneben weil ich neugierig war), bin auf 17.1 gespannt aber meine TestVM rödelt und explodiert auch schon vor sich hin. Update auf 17.1 war in der VM extrem holprig und musste ich 3x anschieben. Da hätte ich bei unseren Firmenkunden extreme Bauchschmerzen das so einzusetzen. Ich sehe auch diese Canonical-Style Releases eher kritisch. Das hätte m.E. später gern kommen dürfen, aber momentan sieht es für mich eher so aus als würde die Manpower für solche on the spot Releases fehlen. Wiederum nur mein subjektiver Blick. Da würde ich mir dann bspw. für 17.x lieber mehr Zeit lassen wenn es noch dazu auf eine neue Basis setzt, als es rauszubringen und dann so viel hinterher fixen zu müssen (siehe Kernel Panics etc.)
Da momentan auch eher die Sachen abgedeckt werden, die bei pfSense sowieso stiefmütterlich behandelt werden (WiFi, CP, nano, i386) kommt mir ein ähnlicher Eindruck, dass es eher der SOHO/low power freundliche Cousin von pfSense wird. Was aber nichts schlechtes sein muss, auf höhere Ziele kann man dann immer noch mit mehr Power hinarbeiten, wenn man die Platform mal stabil hat, es wird ja auch noch gerade viel ausgetauscht und umgebaut.

Grüße

>Muss ich Helfer-Adressen für die VIPs anlegen ? Als IP-Alias oder sowas in der Art ?
Nein. Wenn du die VLANs richtig angelegt hast nicht.

> Du schreibst, dass ich die VLANs dann wie normale Interfaces konfigurieren kann.
Richtig,

> Momentan sehe ich das nicht, wenn ich unter "Other Types/VLAN" aufrufe.
> Da kann ich lediglich ein VLAN Tag angeben und ein Parent Interface wählen. Mehr nicht.
Dann hast du nicht gemacht, was ich geschrieben habe:
Hier legst du deine VLAN Tags an. Also die, die du auch auf dem Switch konfigurierst. Bspw. VLAN 10, 20, 30. Also legst du hier VLAN 10 auf lagg0, 20 auf lagg0 und 30 auf lagg0 an. Gibst ihnen sinnvolle Beschreibungen und gut.

> Daher vermute ich, dass ich etwas falsch gemacht habe.
Richtig.
Du hast nicht gemacht was ich geschrieben habe. Unter Interfaces > Assignments müssen die VLAN Tags jetzt als Interface hinzugefügt werden.
"New Interface" -> Pulldown -> Dort deine VLANs auswählen und jedes Mal das + dahinter buzzern bis alle VLANs in der Interface Liste stehen. Dann SAVE.
Anschließend gehst du in jedes neue VLAN Interface (OPTx) rein, schreibst ihm nen schönen Namen und vergibst wie jedem anderen Interface seine IP etc.

> Wenn ich mir HA anschauen (über Virtual IPs/Status) können meine Firewalls auch nicht festellen,
> wer gerade Master für welches Interface ist. Wahrscheinlich gerade aus diesem Grund...
HA ist jetzt noch überhaupt nicht im Spiel. Mach erstmal deine Interfaces sauber. Für CARP muss dazu jedes Interface auch gleich heißen (interne Bezeichnung, also OPTxy), sprich bitte auf jedem CARP Node die GLEICHE REIHENFOLGE einhalten beim Hinzufügen der Interfaces, damit die gleichen OPTx Interface Namen vergeben werden. Das ist wichtig!

> Definiere ich dort (lagg0) gar keine Regeln ?
NEIN, das Lagg ist NUR noch dein physikalisches Trägermedium. Deine VLANs sind die, welche die Musik spielen. Das Lagg selbst (Lagg0) sollte auch überhaupt nicht zugewiesen sein (unter Interfaces > Assign). Das ist unnötig, da es selbst keinen Traffic (untagged) tragen sollte. Eine IP sollte es schon gar nicht besitzen. Wie gesagt, das Lagg ist nur noch Träger, die VLANs sind die Interfaces für Layer 2+ und werden entsprechend konfiguriert.

Grüße

@fabian: Es mag ja mit HardenedBSD ein Beitrag dazu kommen, das Grundsystem sicherer zu machen. Darum ging es aber gar nicht. Ein OpenBSD war - als ichs zuletzt angefasst habe Anfang 2004 - OOB bereits sicher und super. Für den Hauptjob einer Firewall ideal. Da mögen dann Pakete und Software und Hardware Bedenken dazu kommen, ganz klar. Trotzdem ist OpenBSD bspw. upstream für DIE Kernkomponenten beider *Sense -> PF. Und PF und CARP können unter OpenBSD eine Menge mehr als der Zögling von FreeBSD. Das wird dort auch besser, keine Frage, aber auch wenn die MT Entwicklung sicher gut und sinnvoll war, wären mir manche pf und CARP Features lieber.

Aber sicher, vieles subjektiv. Allerdings finde ich die Hardware Unterstützung jetzt nicht soo mies. Das hängt aber natürlich stark davon ab was ich will. Eine Firewall bauen? Oder eine Wollmilchsau ;) Mir wäre bspw. der Wegfall von WiFi o.ä. völlig egal, da ich der Meinung bin, dass das direkt auf meiner Firewall eigentlich nix zu suchen hat :) Aber da bin ich eben Purist und mehr im Enterprise Umfeld aktiv. Da erwartet niemand, dass man alles auf eine Kiste packt.

Grüße

Nachdem jetzt alle im Paranoia OT waren ;)

Warum nicht einfach so ne0h:

- Alias definieren: Track_Host mit IP.
- 1. Regel: any any allow Regel erstellen allerdings mit Source Host Alias <Track_Host>, Haken beim Logging rein.
- 2. Regel definieren mit Source LAN_Network (also alle AUSSER Track_Host), entweder erlauben oder verbieten, was du machen möchtest, Logging NICHT rein.

Damit solltest du auf deinem LAN erstmal nur noch Einträge im Firewall Log sehen, die der Tracking Horst auslöst ;)
Alles andere vom LAN wird erlaubt oder geblockt aber durch "no log" im Log ignoriert. Wenn noch zu viel WAN Geblubber am Start ist, dann in den Eigenschaften beim Logging noch die Default Block Logs abschalten, damit Ruhe einkehrt. Und dann solltest du problemlos nur noch deinen einzelnen Host reden sehen.

Zusätzlich: Bei sowas kann auch NTOPNG bspw. als Paket helfen, da hier die Komm-Beziehungen pro IP aufgeschlüsselt sind. Kann aber auch ggf. durch ein Flow Tool o.ä. ausgelesen werden :)

Grüße

Danke, hat mich nur interessiert. Flames per se sind nie zielführend.
Wobei ich zwar jetzt nicht sehe, dass OPNsense mit VLAN, WebProxy und OpenVPN wahnsinnig schneller/mehr OOTB Experience hat (Proxy vielleicht ein wenig...). Wüsste nicht dass das jetzt schwerer/langsamer war in pfSense aufzusetzen.

Zeitaspekt ist natürlich immer ein guter Grund, wer mit zunehmendem Alter und anderen Verpflichtungen schon Zeit sich mit allem Kleinkram rumzuschlagen ;)
Ich habs bis jetzt leider andersrum erlebt, aber vielleicht habe ich mit 17.1 mehr Glück. Nochmal alles von vorne und zusehen, wie es sich dieses Mal darstellt. Aber eine fehlschlagende Installation hatte ich jetzt vor opnSense schon lange nicht mehr ;)

Und bei OpenBSD muss ich immer noch sagen: schade, dass keine *sense oder derlei sich traut, OpenBSD als Projekt drunter zu nutzen.

Gruß

Ahoi und Grüße!

Da ich momentan beides nutze, frage ich mich: was funktioniert denn so viel viel besser als vorher!? Für die meisten normalen Anwendungsfälle hatte ich bislang kaum großartige Unterschiede, was keinesfalls schlecht ist, aber auch nicht diesen Überschwang hervorrufen dürfte ;)

@monster:
Doch ich finde das Argument zieht ganz gut. Die meisten bekommen heute nämlich keine Fritzbox mehr, es sei denn von Drittanbietern. Aber die Anbieter selbst haben meist ihre eigenen Gurken am Start, vor allem nachdem nun Routerfreiheit angesagt ist. Easybox oder sonstige Krankheiten sind da an der Tagesordnung. Und da ist der Vergleich mit der überall auftauchenden Fritte schon ganz OK. Zudem ist das "für ein paar Euros" ja nun auch Augenwischerei, die wird entweder Querfinanziert oder der Preis wird angerechnet. So oder so, wird man dafür seine 200 Tacken los, ob das gut verpackt ist, ist ein anderes Thema ;)

Das Leistungs-Argument zieht dafür für mich nicht. Die APU2 hat m.E. keine übermäßige Leistung, vor allem wenn man sich ein wenig mehr mit Paketen wie pfBlocker und Proxy oder IDS beschäftigt. Dann ist das Leistung die ich brauche, nicht übermäßige. Und das dann ggf. auch für "nur" 16-25MBit/s. Ab 50-100 wirds dann eh schon sportlich. Leider hab ich auf die Schnelle nichts gefunden, was im Black Dwarf eigentlich verbaut ist, hätte mich jetzt interessiert, was man für den Preis bekommt. Ich glaube das war ein Via Nano? Da mag ich vielleicht auch (zu?) hohe Ansprüche haben, aber ich hab 2004 schon mit Via Eden und Nachfolgern rumgehampelt und fand sie im Alltag immer einfach zu träge und langsam. Vor allem wenn mal wirklich Last aufs Netz kam. Mag dem Nano jetzt unrecht tun, aber der T40E und auch der GX-412TC (APU/APU2) sind keine Speed-Weltwunder. Klar ist das vielleicht für DSL ausreichend, wenn ich aber innen noch 1-3 Beinchen Gigabit habe (und etwas mehr dem Gerät abverlange an Paketen), dann kommt mir das gefühlt zu lahm vor.

Aber ist nur meine Meinung und ich sehe 150-200€ für eine "Home-Firewall" durchaus als soliden Wert an, gemessen an dem was man für den Preis sonst so bekommt. :)

Klar, eine APU2 ist in jeder Hinsicht leistungsfähiger. Kostet aber eben auch mal ~ 200€ (SSD+Wifi). Gebraucht sind die APU-Boards bisher kaum zu haben. Dazu haben die APU2 keinen VGA-Ausgang.

Richtig, ~200€ kommt schon hin. ABER - und das lese ich ständig - meistens sollen die *Sensen ja vorhandene Geräte ablösen oder statt bspw. eine Fritzbox ins Netz kommen. Jetzt schauen wir mal realistisch, was eine FB kostet -> da sind wir bei den großen auch schnell bei 170-210€. Und in dem Preissegment bewegt sich auch die APU2. Völlig OK in meinen Augen. Zudem hält die meistens länger als ne FB, kann mehr (und das ggf. auch richtig) und man ist flexibler.
Natürlich ist günstiger nie verkehrt, aber deshalb finde ich das an manchen Stellen etwas aufkeimende "Jammern" über 200€ schon weit hergeholt. Und wenn ich mir dann den Vergleich erlauben darf (wieder: nichts gegen die günstigeren Boards oder Kisten) aber ordentliche Hardware kostet eben ein wenig mehr, kann dann aber auch was. Wenn ich nen 2€ Schloß mit nem ordentlichen Klopper für 20€ vergleiche, weiß ich auch warum das mehr kostet ;) (OK der war schlecht, aber ein wenig passt es schon :D)

@fabian:

Wozu sollte eine Firwall einen VGA-Ausgang haben

Weil es durchaus Leute gibt, die an eine FirEwall auch Monitor und Tastatur zu Diagnosezwecken anschließen möchten.
Weil nicht jede Hardware bspw. eine Remote Console hat (IPMI o.ä.) um auf die Console zu schauen, wenn es Probleme beim Booten gibt.
Weil es genügend Leute gibt, die solche Kisten vor Ort bei Kunden installieren und dort dann mitunter keinen Zugriff auf serielle Consolen haben (oder zumindest nicht dauerhaft).
Weil mancher bspw. ein Livelog auf der Console mitlaufen haben möchte, ohne dass man sich remote in das Gerät einloggt.

Die Gründe sind legitim und vielfältig. Und gerade wenn man z.B. auch mal was in einem Rack verbauen will, hat man auch oft sowas wie einen KVM Switch o.ä., an die man solche Geräte logischerweise gern anschließen würde. Das ist u.a. mit ein Grund, warum trotz fehlender Möglichkeit für ein Rackmount, die NCA-1010 von Lanner gern bestellt wird -> sie hat auf Wunsch HDMI Output oder eben die übliche serielle Konsole. Je nach Einsatzzweck ist das eben Gold wert :)

(Oder du verwendest statt 127.0.0.1 die IP-Adresse deines LAN Interface, dann wäre der Dienst auch über die interne IP erreichbar.)

Da könnte ich mich irren, aber das gibt evtl. Probleme je nach ausgewähltem Verfahren fürs Balancing wenn die entsprechenden Hosts geroutet, genattet oder anders erreichbar sein sollten, denn dann wäre es ggf. eine andere Absendeadresse oder asymmetrisches Routing. Irgendeinen Fall hatten wir da mal, aber ich komme leider nicht mehr drauf. Das Binden an localhost sieht mir da fehlerunanfälliger aus.

Grüße

Nix da! Alte Hardware ist wie guter Wein. Die reift. Hab noch zwei 14 Jahre alte Dell Precisions laufen. Und ansonsten auch noch Oldtimer zwischen 11 und 8 Jahren. Alles kein Problem. Für Heimanwendung allemal. :-D

Ahoi chemlud :)

Bei mancher Hardware mag das so sein. Die Dell Precisions sind aber wohl auch nicht gerade low-end Workstations gewesen, oder? ;) Klar, ich habe hier auch noch meinen alten Firmenlaptop - mittlerweile 5 Jahre alt und wird bald 6. Aber der hatte auch keinen unterirdischen Atom verbaut, sondern einen der ersten Core i5er (oder wars noch ein Core2Duo?). Der Punkt ist: mid- oder high-range Hardware ist auch nach Jahren noch mit solchen Jobs nicht überarbeitet. Die ersten Atom Serien waren aber - und das hat Intel ja selbst zugegeben - eher ein Flop und viel zu langsam, so dass sie sich fast den Namen Atom verbrannt haben. War ja lange die Frage ob die C2000er überhaupt Atom genannt werden sollte, weil die 4-stelligen Atoms mit den 3-stelligen nichts mehr gemein hatte.

Ansonsten halte ich generell (subjektiv) WLAN via USB für keine tolle Lösung. Das schreit eher nach Problemen als Lösungen.

Aber Prioitäten ändern sich ganz schnell, wenn man die richtige Frau im Leben trifft! :D

Die ändern sich auch wenn man den ganzen Kram alles bezahlen muss und die Stromrechnung sieht :D
Davon abgesehen - war ein AP an der Decke via PoE nicht frauenkompatibel? :)

Grüße