Schönes Projekt und Danke für Deine eigene Rückmeldung zur Lösung.

@Kobold: Ich sehe den Sinn für diesen ganzen ClearOS Quatsch nicht. Entweder ich schaffe alte Zöpfe ab, dann auch richtig, oder eben nicht. Warum soll ich - wenn man jetzt schon den Cisco rauswirft - auch noch irgendein altes anderes RouterOS da rumgammeln lassen. Das erschließt sich nicht. Und über irgendwelche theoretischen SANS oder sonstwelche DMZ Niederschriebe schreibe ich eigentlich nicht. Das ist schön wenn sich da mal jemand hingesetzt und das entworfen hat. Wir haben aber 2015 und die Situation ist eine andere, wie sich jemand mal überlegt hat das zu benennen. Als das festgelegt wurde (ich habe noch Firewall und Security Lektüre aus der Zeit) wurde im DMZ Segment auch noch von echten gerouteten Adressen ausgegangen. Das ist heute nicht mehr so, weil oftmals 1:1 NAT oder sonstiges zum Einsatz kommt und Kunden nur noch kleinere - wenn überhaupt - Netze bekommen. Die dann noch extra zu segmentieren oder aufzulegen verschwendet dann Adressen. Theorie ist da schön, in der Praxis seh ich das eben anders :) Und nach meiner Erinnerung hat keiner der sich auch nur im Entferntesten Security Guy schimpft, jemals "Exposed Host" und "DMZ" im gleichen Satz in den Mund genommen. Das ist schlicht eine Verunglimpfung eines Ausdrucks, denn billig-SOHO-Router Hersteller irgendwann mal eingeführt haben, um das als tolles Feature mit einem Security Ausdruck zu bewerfen. Aber mit dem Prinzip DMZ hat das nicht mal Ansatzweise zu tun (denn DMZ impliziert einen begrenzteren/abgegrenzten Security Level der kleiner als Vollzugriff/Internet aber größer als abgeschottetes LAN ist). Aus dem Grund sehe ich auch nicht ein, warum ich mit extra Kisten alles kompliziert machen sollte:       WAN / Internet             :             : DialUp-/PPPoE-/Cable-/whatever-Provider             :       .-----+-----.       |  Gateway  |  (or Router, Modem, whatever)       '-----+-----'             |         WAN | PPPoE / Ethernet             |       .-----+-----.  priv. DMZ  .------------.       |  pfSense  +-------------+ DMZ-Server |       '-----+-----' 172.16.16.1 '------------'             |         LAN | 10.0.0.1/24             |       .-----+------.       | LAN-Switch |       '-----+------'             |     ...-----+------... (Clients/Servers) Klassisches Dreibein mit DMZ Achse. Läuft. Und man muss nicht an 2-3 Kisten suchen, warum zum Geier irgendwas nicht läuft. @Marc 2x 10Gbit/s… Wozu? Ich sehe nirgends Anwendungsbereiche, wo du irgendwas mit 10GE bräuchtest. Finde ich dann doch recht unnötig. Sollte ich doch noch wiedererwartend eine andere Sache dürfen, wie genau ist die vorgehensweise wenn alle Server (auch die die nicht dreigegeben werden sollen) VMs auf zwei Windows Hyper-V Servern sind? Dann müssten die Hyper-V Server beide in die DMZ und dann ist auch das frei was nicht raus soll, oder? Nein, deshalb wären gerade Switche gut, die eben VLANs können. Ich würde sowieso die Server NIE direkt ans Netz hängen, auch nicht via 1:1 NAT, denn das fügt keinerlei Sicherheit hinzu. Gerade Exchange (OWA) hängt dann nackt am Netz und sollte mal wieder nen Patch Day versaut sein, hast du hinterher noch Streß weil der Mailserver tot ist. Deshalb kann man - bspw. in eine DMZ oder zum Teil auch direkt via pfSense - diverse Dienste einfach mit (reverse) Proxy betreiben. Für OWA/Exchange geht das m.W. unter anderem mit Squid und/oder HAProxy, die dann einfach die Daten initial annehmen und an Exchange weiterreichen. Wenn aber von außen jemand lustige Probes fährt um irgendwelche IIS Lücken zu finden, wird er am HAProxy oder Squid eben nicht weit kommen. Dito für deine anderen Atlassian Kisten. Da schreibt Atlassian ja sogar selbst, dass man Jira/Confluence und Co. am Besten nochmal mit einem Apache/NGinx vornedran Proxy'en sollte. Schon allein, weil du dann nicht auf krumme Ports zugreifen musst, aber auch um ggf. Caching und Security noch mit reinzubringen (und ggf. TLS hinzuzufügen bzw. Offloaden zu können). Darum sehe ich auch keinerlei Traffic WAN<->DMZ, DMZ<->LAN oder WAN<->LAN, der jetzt >1GBit/s wäre und da ich bezweifle, dass ihr 10GBE Dark Fiber angebunden seid ;) sehe ich da nirgends einen Grund für eine pfSense mit 10G Interface. VLANs würden sich positiv bemerkbar machen, denn du könntest damit ggf. Maschinen auf dem HyperV hochfahren und deren Interface an einem extra VLAN betreiben, das auf der pfSense eben wie eine DMZ aufliegt. Damit wäre der Hypervisor selbst nicht exponiert, und nur die VM würde dann ggf. mit einer anderen Maschine im normalen LAN reden. Diese Kommunikationsbeziehungen am Besten festhalten (aufschreiben, Netzplan) und dann die Regel genauso festzurren. Dann ist auch nicht mehr erlaubt als es sein muss und damit alles OK -> mehr Filtern geht dann nur auf Applikationsebene und das ist immer ne andere Baustelle. Von der bisherigen Erzählung würde ich aber Frank zustimmen: ein C2758er Atom Server mit 8 Kerner Atom und 8GB RAM sollte da DICKE reichen. Wir haben auch 2 solche Kisten vor unserem Office (CARP Cluster wegen Ausfallsicherheit), sind 1HE Supermicro Superserver und funktionieren super und sind wirklich sehr fix und für den Job durchaus ausreichend, Grüße Grüße

Hi, in der Squid Config einfach das Häkchen bei "Transparent proxy" entfernen. Und dann bei den Kids Deine Firewall LAN IP mit Port 3128 als Proxy eintragen. Das können sie natürlich einfach wieder entfernen, daher solltest Du im LAN dann auch eine generelle Block Regel für die Rechner der Kids erstellen. Ausserdem musst Du ihnen vor der Block Regel noch Port 3128 zur Firewall LAN IP freigeben, damit sie auf den Squid kommen.

Danke für die Antworten, aber sie sind leider nicht zielführend. Mit mehr Informationen bekommen wir das sicher hin. Es geht hier um Anschlüsse mit der gleichen Leitungslänge zur Vst, die also idR in etwa die gleiche Bandbreite haben. Haben "sollten"! Nicht immer ist die Leitungslänge der einzige Faktor, der die Latenz und Bandbreite bestimmt. Es kann auch sein, dass eine Leitung eben dummerweise noch an eine alte Schnittstellenkarte angeschlossen ist im Verteiler. Das gab es schon oft genug, dass der zweite Anschluß im gleichen Haus plötzlich statt (bspw.) DSL Light plötzlich volles DSL hatte - weil eben auch in der Vst. und im DSLAM neuere Hardware angeschlossen waren. Trotzdem stimme ich hier Frank zu, es macht keinen Sinn, dass beim Verteilen auf ein drittes WAN Interface plötzlich kein Traffic mehr vorhanden ist. Dann ist was anderes faul.

Hallo! Du solltest dir dieses Thema ansehen: https://doc.pfsense.org/index.php/What_is_policy_routing Definiere eine Firewall-Regel für deinen Upload und darin ein bestimmtes Gateway. Diese Regel musst du dann oberhalb von der positionieren, die den restlichen ausgehenden Traffic erlaubt. Grüße

Und wo bekomme ich einen STUN her? Frag doch mal bei Auerswald nach oder nutze wie schon angesprochen einen freien STUN Server am Markt. Ich denke jedoch das man so etwas in der Regel umgehen kann bzw. auch aus Sicherheitspolitischer Sicht her. Einfach eine kleine PBX Appliance in die DMZ packen und gut ist es. Dazu kann man auch ruck zuck ein PC Engines APU Board nehmen und mit Askozia oder Asterisk sollte man das auch schnell umsetzen können. Auch fix und fertige Sachen wie MobyDick die gleich "ready to go" daher kommen sollten keine Probleme machen und schnell zum Erfolg führen. Einige Möglichkeiten sind kostenlos bzw. nur die Hardware muss besorgt werden, aber der STUN Server kostet immer Geld! denn hinter NAT geht sonst das nicht … Nicht ganz, man kann ja auch eine DMZ anlegen und dort einen Asterisk "Server" platzieren, den man dann nutzt. Oder einen Proxy und ich kann dann nicht richtig verhindern, dass irgendwelche Leute versuchen sich einzuloggen … Doch per Firewallregeln und oder einem DMZ Radius Server, oder Snort oder,…...

Danke für deine schnelle Antwort! Ach und ich dachte ich muss in das Feld Notification Email Adress die Adresse eintragen wohin die Benachrichtigungen gesendet werden sollen und in die anderen Felder die Mail Adresse von der aus es gesendet wird! Habe jetzt alles auf eine Mail Adresse geändert und es funktionierte! :) Danke jetzt weiß ich wo der Fehler lag. Gruß

Habe heute einUpgrade auf die neue Version der PF Sense gemacht unt hatte dann massive Probleme mit allen http Seiten, den jeder Client wurde immer auf eine https Seite umgeleitet, was dan icht funktionierte Ich bezweifle sehr, dass das mit pfSense (direkt/core) zusammenhängt. pfSense hat erst einmal gar keinen Anteil daran, irgendwas umzuleiten. Wenn dem so ist, dann kann das höchstens durch irgendein 3rd party Paket wie ein Proxy o.ä. passieren oder du hast irgendwelche Browsererweiterungen aktiv (https everywhere bspw.) die Amok laufen. Ich bin ein wirklicher Leie wenn es um die PFsense geht. Habe diese geschenkt bekommen und habe mich vor lauter rumspielen aus dem WebGui im Web Access Manager rausgesperrt. Je nach Version (2.1+) gehört da einiges dazu, da die WebGUI Access Regeln extra geschützt sind und eigentlich nicht gelöscht oder verändert werden können. Es sei denn man nimmt den Haken dafür absichtlich raus und löscht dann, was schon ein wenig seltsam wäre. Habe gelesen wenn man sich per Putty verbindet kann man den Job killen sodass man wieder über die WEbGui reinkommt und alles umstellt. Das klappt aber auch nur, wenn man nach wie vor per SSH auf die Kiste drauf kommt, da aber die Protection Regel sowohl SSH als auch HTTP/HTTPS beinhaltet, wirst du damit wahrscheinlich auch kein Glück haben. meine Einstellungen rückgängig mache Das geht über die Console gar nicht, du kannst darüber nur die Konfiguration resetten und/oder temporär den kompletten Filter abschalten um dich ggf. wieder mit der WebGUI verbinden zu können. Ein gezieltes Rollback einer Änderung ist m.W. nicht ohne weiteres möglich. Welche Einstellungen snid für das massive https/http Problem verantwortlich auf der neuen Version ? Keine. Wie gesagt wäre das a) bekannt und b) gäbe es inzwischen schon einen Bugfix oder eine neue Version. Ich vermute eher einen Bug in der Art wie ein zusätzlich installierter Proxy konfiguriert ist. Es gibt u.a. für einen andere Fall solch ein Verhalten mit der Auto Redirect Regel der pfSense: https://forum.pfsense.org/index.php?topic=97567.0 Das hat aber nichts mit abgehenden Verbindungen zu tun und betrifft wie gesagt Squid. 3.) Kann ich ein downgrade auf die alte Version durchführen ? Woher bekomme ich diese ? Nein. Du kannst gern eine ältere Version neu installieren, aber ein Downgrade gibt es nicht. Ist zudem durch die Bugfixes etc. der aktuellen Versionen nicht empfohlen, da du damit wieder Bugs aufmachst. Gruß Jens

@BlueKobold: Also das hier die Performance der Hardware das Problem sein sollte denke ich nicht. Es sind 2 HP 6300 mit Samsung 850pro SSD's welche im Cluster laufen. Was schon eher möglich ist, dass es ein Versionsproblem ist von PfSense. Weiss von euch jemand per Zufall, ob es bei der neuen 2.2.4 Version immer noch Probleme mit Captive Portal und Cluster gibt?? Danke für eure Antworten.

Ich versuche es mal anders: Ich habe in unserem RZ einen Pool von offiziellen Adressen. Nennen wir die Adressen mal 1.2.3.0/24. Diese sind von Außen über die Schnittstelle "WAN" zu erreichen. Wir möchten nun einen Rechner mit der IP 1.2.3.10 einrichten, der als Honey-Pod fungiert. Hier soll die Arbeitsweise von gewissen Internetnutzern beobachtet werden. Nur ist dies mit Snort nicht möglich, da bevor es richtig interessant wird, schon die IP gesperrt ist. Also wie kann ich eine -oder Bereiche- einer Desination-IP (1.2.3.10) für alles freischalten, unabhängig von der Quell-IP? In der Suppress-Liste? Wie würde die Rule aussehen?

Ich hatte bei meiner 750 auch Probleme damit, irgendwann hing die Ausgabe ohne das ich zum flashen kam. Letztendlich hatte ich die Nase gestrichen voll, no Risk, no Fun  8). Ich habe einfach die Befehle zum flashen in die autoexec.bat geschrieben und die Kiste gestartet. Strike, kann die Kiste natürlich auch final bricken … -teddy

Um ein paar seltsame Ideen auszuräumen: die bisherige TinyCA bat die Funktion, bei der Erstellung eines Zertifikates das Zertifikat mit einem Passwort zu versehen, welches man beim Importieren angeben musste. Nochmals: ein Zertifikat hat NIE ein Passwort, es gibt immer nur den privaten Schlüssel, der ein Passwort hat. Bei deinem bisherigen Format (pkcs12) ist lediglich der Schlüssel in der gleichen Datei wie das Zertifikat als Paket gespeichert. Das ändert aber nichts an der Aussage. Wir wollen aber keine OpenVPN Zertifikate benutzen. Es sollen reine ipsec Verbindungen sein. Es gibt keine "OpenVPN" Zertifikate. Es gibt lediglich TLS/SSL Zertifikate nach x.509 (https://de.wikipedia.org/wiki/X.509). Dass diese Zertifikate heute für relativ viele Einsatzgebiete genutzt werden, ändert nichts daran, dass im Grundprinzip als Datei betrachtet alles das Gleiche ist. Ob das nun ein Zertifikat für einen Webserver, IPSec, OpenVPN etc. ist, spielt dabei keine Rolle. Lediglich wird für manche das gelieferte Format eine Rolle spielen (.pem, .p12, etc. -> https://de.wikipedia.org/wiki/X.509#Dateinamenserweiterungen_f.C3.BCr_Zertifikate) Das Einzige, was tatsächlich Zertifikate unterschiedlich macht, sind die gesetzten Flags, was es für ein Zertifikat ist (CA, Server, Client). Aber auch hier ist es lediglich diesen Bits geschuldet, für was das Zert genutzt werden kann. Alles andere ist völlig gleich. Ich weiß jetzt nicht WOFÜR es bei deinem Einsatzgebiet ein nochmals mit Passwort geschützter Key sein muss, kenne aber selbst KEINE VPN Appliance, die unbedingt für IPSEC ein Zertifikat mit passwortgeschütztem Key benötigt. Es würde auch keinen Sinn machen, denn die Anwendung/Appliance müsste jedes Mal beim Neustart o.ä. den Key neu in den Speicher laden, dabei entschlüsseln etc. und dabei ist im Normalfall kein User anwesend, der den eintippen kann. Somit würde man das Passwort auf dem gleichen Device hinterlegen, was den Key an der Stelle wieder vollkommen unnütz macht. Deshalb werden u.a. auch bspw. Webserver nicht mit einem TLS Key/Zert gesichert, der noch ein Passwort hat, da ansonsten bei jedem Webserver Neustart der Key eingegeben werden müsste. Und wenn nicht, müsste der Key im Klartext auf der Maschine vorhanden sein was wieder das Passwort als 2. Faktor unnütz macht. Deshalb als Denkanstoß einfach mal nachsehen, OB das überhaupt sein muss oder ob es einfach nur "bisher so war". Es ist ansonsten auch kein Problem, wie schon geschrieben, dem Schlüssel im Nachhinein ein Passwort zu verpassen, für die meisten Einsatzgebiete aber einfach unnötig. Wenn es nur um den sicheren Transfer des Schlüssels geht, ist ein PW geschütztes ZIP wie Virago meint garantiert ebenso sicher. Und einmal eingespielt in der Anwendung, Appliance oder dem Keystore wird der Schlüssel in den allermeisten Fällen eh nie wieder genutzt. Grüße

mit Extrahardware meinte ich halt nur "Router auf eigener Hardware", keine VM im hp ;)

Hallo ich bin selber neu hier und kann dir bei deinen Kernfragen (pfSense) nicht helfen, aber evtl. bei der Multimediageschichte. Ich habe seit Jahren folgendes Setup: ein Fileserver zum darauf arbeiten und Medien ablegen (ein NAS geht auch bzw. ein NAS-selbstbau). ein NAS als Backup vom ersten, 1x in der Woche automatische Backup mit rsync. ein WindowsPC mit MediaPortal fürs TV und Filmvergügen, das MyFilms Plugin ist XBMC überlegen. drei XBMC/Kodi Clients für TV-Nebenstellen (als einfacher Kodi-Client reicht der neue RasPi2 vollkommen aus, der alte war etwas zu lahm. Alte PCs sind gut für OpenElec und auf dem Mac gibts auch eine Kodi-Version) Wichtig für den Mischbetrieb ist das Anlegen von nfo-Files, damit kann Kodi, MediaPortal und diverse Katalogsoftware etwas anfangen. Auf jeden Fall würde ich nicht versuchen die zentrale Medienablage auch zum Player zu machen. Dieser Server/NAS wird laufend nach mehr Festplatten schreien und muss 24h laufen um für alle Benutzer (falls du nicht alleine lebst) und TV-Aufnahmen Sinn zu machen. Das heißt er wird Krach machen, Staub verwirbeln und mag es nicht dauernd ein- und ausgeschaltet zu werden (dauert auch zu lange).

Danke, war im falschen Beitrag!