• LAYER 8 Moderator

    Moin!

    Da ich ja schon recht lange im Homelab und als Test VMs mit der upcoming 2.5 rumspiele, sind mir jetzt akut gerade einige schöne Änderungen aufgefallen, die ein wenig unter dem Radar liefen, daher wollte ich hier mal ein paar Punkte auflisten (ich editiere die dann mal später weiter), die definitiv positiv herausstechen und weswegen ich auch momentan auf 2.5snaps bleiben werde :)

    • System / General
      • kleinstes Gimmick, aber ich finde es sehr schön, die Aufmerksamkeit dahin zu lenken: Der Defaultname der pfSense ist nicht mehr pfsense.localdomain, sondern nun pfsense.home.arpa. Das entspricht RFC8375 und ist einfach guter Stil. Zudem vermeidet es das Drama um den .home TLD dessen Status immer noch wacklig ist (und bei dem ICANN Drama vllt doch irgendwann public wird) und es vermeidet .local was eben von mDNS genutzt wird und immer Problem(ch)e(n) macht.
      • Disable DNS Forwarder: Die Option wurde umbenannt und ergänzt und heißt nun DNS Resolution Behavior und wurde ein Dropdown. Man hat nun die Möglichkeit, localhost zu verwenden mit Fallback auf die angegebenen DNS Server weiter oben (Standard), kann NUR localhost auswählen oder im Gegenteil dazu NUR externe Server die angegeben sind verwenden (die alte Option). Somit kann man nun hier unter System/General DNS Server angeben um ggf. diese als DoT Server im DNS Resolver zu nutzen (dortige Optionen gibts ja schon länger für DoT Unterstützung). Was bislang aber nicht ging: wenn ich Server eingetragen habe um diese für DoT zu nutzen, wurde diese automatisch auch immer für die lokale DNS Auflösung mitbenutzt. Jetzt kann ich über diese Option das Verhalten abschalten, dass pfSense selbst bspw. immer den lokalen DNS Resolver nutzt ohne direkt mit DNSen zu sprechen, aber der lokale Resolver wiederum die angegebenen Server via DoT anspricht. Somit also immer DoT gesprochen wird. Andersrum kann ich ohne DoT nun sagen: Lokales System nutzt bitte diese externen DNSe OHNE den Resolver, damit keine Fehlkonfig des Resolvers den Systembetrieb blockiert, alles andere bitte den Resolver nutzen, da bspw. pfBlockerNG integriert ist.
    • System / Advanced
      • Tab: Admin Access
        • SSL/TLS Certificate: Neuer Hilfetext, der definiert, dass Zertifikate die nicht für Webserver TLS verwendbar sind, hier nicht angezeigt werden (somit keine Konfusion, warum client TLS Certs nicht angezeigt werden) ;)
      • Tab: Networking
        • hn ALTQ support: Neue Option für Typ "hn" Netzwerkkarten.
      • Tab: Notification
        YEAH! Ganz ehrlich, darüber freue ich mich mit am Meisten 😁
        • Neu: General Settings: Neue Rubrik, die eine neue Funktion steuert. Zertifikatsablauf. Es wird geprüft ob irgendwelche Zertifikate im Store der pfSense ablaufen oder abgelaufen sind und versendet tägliche Notifications darüber. Super um gewarnt zu werden bevor/ob das UI oder irgendwelche Server Zertifikate ablaufen. Man kann den Check aktivieren via Checkbox und den Zeitraum einstellen, ab dem gewarnt wird (27d ist default).
        • Growl YES! Die nutzlosen GROWL Notifications (die IMHO nur auf Macs überhaupt funktionierten) sind raus. Hat kein Mensch gebraucht, waren nutzlos, gab es schönere Sachen die die ganze Zeit ignoriert wurden. ABER: Genau das ist jetzt der Punkt, denn:
        • NEU: Pushover: F***ing AYE. Pushover ist mit an Bord. Jetzt kann man sich via Pushover Service statt (nur) Mails auch Notifications direkt auf iOS oder Android pushen lassen mittels Pushover. Eine der flexibelsten Services was Notifications angeht. Für "Hochsicherheitsanwendungen" vielleicht ungeschickt, aber Pushover kann in sehr vielen Anwendungen bereits genutzt werden und dank API kann sich jeder selbst da auch viele schöne eigene Anwendungen und Co bauen. Ich hab damit bspw. ein SMS-2-Pushover Gateway gebastelt um die leidigen Dienste, die immer noch 2FA via SMS machen zu umgehen und Monitoring zu machen mit SMS als Fallback :)
        • Neu: Telegram: Ja ich weiß, hat in letzter Zeit etwas gelitten im Ruf wegen der ganzen Bekloppten, die sich darüber gerade organisieren um zu Protestieren. Reden wir nicht drüber, ist mühselig. ABER - und das ist der Hook - im Gegensatz zu den ganzen anderen Messengern die sich so positionieren, hat Telegram eben doch noch einen ganz guten Track Record und hat zusätzlich eine offene und freie API für Bots und Message-Groups/-Chains. Man kann hier also einen eigenen Telegram Bot erstellen, dessen Daten in der Sense eingeben und den Bot quasi Statusmeldungen via den Bot in eine Statusgruppe posten lassen. Die Gruppe kann man dann absichern, dass dort eben nur der eigene User/Account drin steckt etc.
          Klar, Signal oder Threema wären noch schöner, aber Signal hat keine API und nur einen sehr crude Linux CLI und Threema verlangt für API, Bots o.ä. Geld. Fällt also aus. Und wer nicht noch einen neuen Dienst (wie Pushover) ins Spiel bringen will, nimmt dann ggf. eben lieber Telegram. Einfacher als Mail ist es allemal :)

    Generell: In vielen Dialogen ist nun in Textfeldern in grau bereits der Default Wert angezeigt der hier anliegt. Das ist allgemein eine schöne Hilfe wenn man nicht sicher ist, was als Default gilt.

    • Interface Assignment
      • neuer Tab: VxLAN Generell erst vor kurzem da eingeschlagen. VxLAN sind nicht gerade einfach zu erklären und ich muss mich da auch noch ziemlich einlesen. Aber super, dass der Upstream Support von VxLANs jetzt schon in den Snapshots ist. ➡ https://wiki.freebsd.org/vxlan
      • GRE: Können jetzt sauber DualStack konfiguriert werden
    • Captive Portal: Hat jetzt für HA Betrieb für den 2. Node eine "BackSync" Option, damit im Falle eines Failovers die verbundenen User/Server etc. vom 2. Node auf den wiederhergestellten 1. Node re-repliziert werden.
    • DynDNS: Mehr Services aufgenommen
    • NTP: Kann jetzt disabled werden (wenn bspw. in einer VM der Host den Timesync übernimmt)
    • UPnP & NATPnP: Soll jetzt angeblich besser funktionieren und auch einen Fix für multiple Konsolen via PnP haben für Leute die Probleme haben
    • IPSec:
      • Erst gar nicht bemerkt, das Remote Gateway kann nun nicht nur als IP angegeben werden, sondern auch der Remote IKE Port und NAT-T Port können angegeben werden. Ich wüsste zwar nicht, welche Appliance die Ports verändert kann, aber interessant.
      • Zusätzlich kann die Remote Gateway IP jetzt auch 0.0.0.0 oder :: sein für "alle IPs". Dann muss allerdings weiter unten die Option "Responder Only" gesetzt sein, damit sich die andere Seite verbinden kann. Die Verbindung geht dann nur noch "einseitig". Ist aber relevant wenn man sich für dynamische IPs öffnen will.
      • Auch einige andere kleine Optionen haben sich verändert und angepasst. Als Advanced Option gibt es nun auch "Gateway duplicates". Habe ich noch nicht nachgelesen, Hilfe liest sich aber so, dass man damit mehere Phase 1 Setups mit gleichem Gateway konfigurieren kann. pfSense routet dann nicht mehr via P1/P2 Konfiguration, sondern via Default Gateway. Liest sich für mich wie das Setup/die Vorbereitung von Multi-WAN mit IPsec. Also wie bei OVPN dann IPsec auf mehrere WANs hören lassen mit gleicher Gegenstelle und die Gegenstelle macht dann ggf. round robin via DNS oder mittels anderer Methode um sich neu zu verbinden. Weiß noch nichts genaues aber sieht interessant aus.
    • OpenVPN:
      • Server: Viele Anpassungen an den neuen Standard von OpenVPN 2.5. Gerade was das Thema "Cipher Liste" bzw. ehem. NCP geht, der jetzt default enforced wurde von OpenVPN Upstream. Da waren einige Anpassungen auch am Client Export fällig.

    Natürlich gibts noch ein paar andere Sachen, die weniger auffallen aber sehr angenehm sind. Sowas wie "Logfiles sind jetzt Textfiles nach normalem RSyslog Standard und werden ganz normal GZ/BZipped und rotiert". Dadurch hat man dann ggf. längere Log Retention und die Files werden auch wesentlich schneller angezeigt. Alleine das ist schon extrem angenehm.

    Was auch positiv aufgefallen ist: Das DHCP6 / RA Handling scheint sich geändert und verbessert zu haben. Eine neu installierte 2.5er pfSense die ich zum Testen direkt an meine DSL Fritzbox gepatcht hatte, hat von dieser sofort(!) nach bootup eine IPv4, eine IPv6 Adresse auf dem WAN und ebenfalls ein IPv6 Prefix auf dem LAN (via Track Interface, WAN) gehabt. Somit war in der Standardeinstellung hinter einer Fritzbox als vorgeschalteter Router (mit entsprechender Einstellund dort - IA_PD etc.) sofort IPv6 Verkehr möglich. Das klappt wesentlich besser als noch in der 2.4.x bisher.

    Das waren so die großen Punkte die mir aufgefallen sind :)

    Cheers
    \jens