PfSense

Lange Zeit schien das WLAN hier hervorragend zu funktionieren. Im Netz waren nur ein paar Smartphones und Tablets eingebucht. Kurze Verbindungsabbrüche fallen bei diesen Geräten wenig auf, da sie es schon vom Mobilfunknetz aus verstehen, mit kurzen Unterbrechungen klar zu kommen. Ganz anders sieht das mit Geräten aus, die eine konstante Kommunikation benötigen, wie z.B. Drucker oder Scanner.

Speziell auf NanoBSD, der auf ALIX-Boards eingesetzten pfSense-Variante schlägt das Update auf die Version 2.3.1_5 über die Verwaltungswebseite und auch über die Shell fehlt. Nach dem Duplizieren des Slice scheint der Updateprozess zu hängen, es dauert sehr lange, bis einfach nur ein “Failed” ausgegeben wird.

Der Updateprozess startet das Update im Slice als chroot-Umgebung. Durch einen Bug ist dort manchmal unter NanoBSD keine resolv.conf vorhanden, welche zum Auflösen von Hostnamen erforderlich ist. Downloads können dann nicht ausgeführt werden. Der Fehler ist mittlerweile bekannt.

Obwohl ich wirklich nicht schnell aufgebe, so ist der mehrere Tage lange Versuch, hier pfSense mit IPv6 der Telekom zu konfigurieren, gescheitert.

Das mag zum einen daran liegen, dass die Telekom aber auch so gar keine Hilfe zur Verfügung stellt, wie die korrekten Parameter für eine IPv6-Konfiguration lauten. Auf verschiedenen IT-News-Seiten, darunter auch Heise, werden in alten Artikeln Prefixe kommuniziert, mal /56, mal /64, welche am IP-Anschluss der Telekom zugewiesen werden. Noch nicht einmal klar ist, ob die Telekom SLAAC oder DHCPv6 spricht.

Mit der Version 2.2.1 von pfSense wurde der alte DNS Forwarder durch den DNS Resolver Unbound ersetzt. Nach dem Update konnte nahtlos umgeschaltet werden, bei Neuinstallationen wird der DNS Resolver als Default eingestellt.

Probleme gibt es allerdings, wenn im alten DNS Forwarder Source-IPs für feste Domain-Weiterleitungen eingetragen sind. Diese werden benötigt, wenn z.B. eine Firmendomain von einem über IPSEC erreichbaren Firmen-DNS aufgelöst werden soll. Der neue DNS Resolver bietet solch eine Einstellung nicht. Ohne besondere Einstellungen werden die DNS-Requests zwar an den richtigen entfernten DNS addressiert, aber über das Default-Gateway und nicht über den IPSEC-Tunnel abgesendet.

Seit der Version 2.2.1 von pfSense lief mein ALIX-Router nicht mehr stabil. Das Problem trat auf, wenn von Remote durch einen IPSEC-Tunnel die pfSense-Box angesprochen wurde, z.B. die Verwaltungsoberfläche aufgerufen wurde. Resultat war ein sofortiger Kernel-Crash.

Anscheinend tritt das Problem nur unter NanoBSD und dann auch nur auf 32bit-Systemen auf. Genau so ein System ist mein ALIX 2D13 Board.

Die pfSense-Entwickler haben einen Woraround gefunden. Unter System -> Advanced -> System Tunables trägt man folgendes ein:

Wer einen eigenen Router einsetzt, muss diverse Stolpersteine bei der Konfiguration zum Empfang von IPTV überwinden. Im Folgenden wird beschrieben, wie ein Rouer mit pfSense mit der Version 2.1.5 für IPTV der Telekom (Entertain) konfiguriert werden kann.

Die Datenübertragung am Telekom-Internetanschluß wird getrennt in IPTV und andere Internetdaten (Surfen, E-Mail, usw.). Technisch geschieht dies durch die Verwendung unterschiedlicher VLANs. Zugang zu “normalem” Internetverkehr erfolgt mit der VLAN-ID 7 und die Übertragung der IPTV-Daten erfolgt über ein Netz mit der VLAN-ID 8.

Seit pfSense 2.0 ist ein Zertifikatmanager in die Weboberfläche integriert, mit dem sich Zertifikate, z.B. für IPSEC, erzeugen und signieren lassen.

Bei der Verwendung der mit pfSense erstellten Zertifikate in Strongswan in Versionen kleiner als 4.6.2 kann der private Key nicht geladen werden. Folgende Fehlermeldung erscheint:

charon: 00[LIB] L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 8 builders

Ursache ist, dass Strongswan bis Version 4.6.2 nur private Keys im PKCS#1-Format lesen kann. Die aus pfSense exportierten privaten Keys liegen aber im PKCS#8-Format vor.

Schon lange hatte ich den Wunsch, mir einen eigenen Router zu basteln. Mein bisheriger Router bekommt leider vom Hersteller keine Updates mehr. Schon IPv6 ist mit meinem alten Router nicht möglich. Was also tun? Einen ausgemusterten Rechner als Router hinstellen? Zu laut, zu groß, zu viel Stromverbrauch. Was also tun? Ein embedded System musste also her. Meine Wahl fiel auf das ALIX 2D13 Board mit einer 4 GB CF-Karte. Auch das OS war schnell gefunden: genau für diese Hardwarekonstellation gibt es vorgefertigte pfSense-Images (ein angepasstes FreeBSD), welches alle meine Vorgaben erfüllte. Bei der Hardware kamen noch eine WLAN-Karte nebst der notwendigen Antennen und Verbindungskabel dazu. Für die Kommunikation über die serielle Schnittstelle (für den Fall der Fälle) war noch ein Serial-to-USB-Adapterkabel notwendig.