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:

Anschließend startet man den IPSEC-Dienst neu und ab da schnurrt die pfSense-Box wieder wie eh und je.

Weitere Informationen im pfSense-Forum.

Update vom 28.06.2015: Ab der Version 2.2.3 von pfSense wird obige Einstellung auf 32bit-Systemen automatisch durchgeführt.

Falls das zu übertragende IP-Paket größer als die maximale Transfergröße (MTU) ist, wird dem Sender per ICMP mitgeteilt, dass eine Fragmentierung durchzuführen ist, die Daten also in kleineren Häppchen zu senden sind. Manche ISPs blockieren ICMP oder lassen nur bestimmte ICMP-Nachrichten durch, was dann dazu führt, dass der Sender nie erfährt, dass die Übertragung nicht funktioniert hat. Gleiches kann bei VPN-Verbindungen (IPSEC, OpenVPN) passieren, die mit ICMP nicht korrekt umgehen. Symptome sind dann:

  • Webbrowser stellen zwar eine Verbindung zum Webserver her, stecken dann aber beim Empfang der Webseite fest
  • sehr kleine E-Mails können versand werden, größere hingegen nicht
  • SSH arbeitet korrekt, aber SCP hängt bei der ersten Übertragung fest
    (Quelle: Man-Page iptables-extensions)

Für solche Fälle kann mit Hilfe von iptables und der Erweiterung TCPMSS die MTU der Verbindung auf die maximal zulässige Größe auf diesem Transportpfades gesetzt werden. Dadurch können alle TCP-Pakete ohne Fragmentierung übertragen werden.

Auf einem Server (nicht Router) tauscht man in obigem Kommando FORWARD gegen OUTPUT.

Anschließend muss noch ein (distributionsabhängiger) Weg gefunden werden, diese Regel nach einem Neustart des Servers automatisch zu laden.

Bild by Fabienne Serriere [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

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:

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.

Mit folgendem Kommando kann der private Schlüssel vom PKCS#8- ins PKCS#1-Format konvertiert werden:

Anschließend kann auch der Schlüssel wieder in Strongswan geladen werden.