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. ...weiterlesen "pfSense: Verbindungsabbrüche mit Atheros-WLAN-Karten"
Schlagwort: pfSense
pfSense: Update auf Version 2.3.1_5 schlägt fehl
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.
Abhilfe schafft ein Update im laufenden System. Dabei wird nicht in die chroot-Umgebung gewechselt, sondern das laufende System upgedatet:
pkg update -f pkg upgrade -f
Danach sollte die Box neu gestartet werden. Nachteil dabei ist, dass man kein Slice mit der vorhergehenden Version mehr hat. Eventuell sollte man also vorher über "Diagnostics -> NanoBSD -> Duplicate boot slice" das aktuelle (ältere) Slice sichern, um eine Fallbackvariante zur Verfügung zu haben.
pfSense und Telekom IPv6: ein Fehlschlag
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.
Zumindest eins konnte ich hier bisher feststellen: ja, ich habe einen IP-only Zugang mit Entertain und ja, ich habe keine IPv6-Sperre, wie in anderen Beiträgen berichtet, da ich einen neuen Vertrag abgeschlossen habe und ein angesteckter Plastik-Speedport auch IPv6 zugewiesen bekommt.
Zum anderen mag es daran liegen, dass wohl niemand pfSense mit IPv6 am Anschluss der Telekom verwendet. Zumal sich hier noch die Schwierigkeit mit VLAN7 und VLAN8 bei Entertain ergibt. So sind auch Beispiele für eine funktionierende Konfiguration im Netz leider nicht zu finden.
Drittens liegt der Fehlversuch wohl auch daran, dass pfSense noch den einen oder anderen Bug in Bezug auf IPv6 hat (siehe z.B. hier oder hier) und leider die Doku zu IPv6 bei pfSense auch noch dünn gesäht ist.
Und zu guter Letzt muss ich zugeben: ich bin IPv6-Newbie.
So kann das leider nichts werden. Schade.
pfSense 2.2: DNS Resolver und Source-IP
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.
Abhilfe schafft hier, beim DNS Resolver unter Outgoing Network Interfaces nur das LAN-Interface auszuwählen.
Nach bisherigen Tests werden damit Anfragen an Domains aus den Domain Overrides mit der korrekten Source-IP versehen. Alle anderen Anfragen an externe (z.B. per PPPoE oder DHCP erhaltene) DNS werden korrekt maskiert.
Weitere Informationen im pfSense-Forum.
pfSense 2.2: Kernel Crash mit IPSEC und ALIX 2D13
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:
net.inet.ipsec.directdispatch=0
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.