Springe zum Inhalt

Blog

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.

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.

Nach der Installation von FusionPBX auf einem Raspberry Pi 2 entsprechend der Anleitung und dem Einrichten einer Extension über die Weboberfläche von FusionPBX kann sich das erste Gerät mit FreeSwitch verbinden. Beim ersten Anruf erhält man allerdings folgende Hinweis- und Fehlermeldungen:

Audio Codec Compare [SILK:99:24000:20:0:1]/[G722:9:8000:20:64000:1]
Audio Codec Compare [SILK:99:24000:20:0:1]/[PCMU:0:8000:20:64000:1]
Audio Codec Compare [SILK:99:24000:20:0:1]/[PCMA:8:8000:20:64000:1]
Audio Codec Compare [SILK:99:24000:20:0:1]/[GSM:3:8000:20:13200:1]
Audio Codec Compare [PCMU:0:8000:30:32000:1]/[G722:9:8000:20:64000:1]
Audio Codec Compare [PCMU:0:8000:30:32000:1]/[PCMU:0:8000:20:64000:1]
Audio Codec Compare [PCMU:0:8000:30:32000:1]/[PCMA:8:8000:20:64000:1]
Audio Codec Compare [PCMU:0:8000:30:32000:1]/[GSM:3:8000:20:13200:1]
Audio Codec Compare [PCMA:8:8000:30:32000:1]/[G722:9:8000:20:64000:1]
Audio Codec Compare [PCMA:8:8000:30:32000:1]/[PCMU:0:8000:20:64000:1]
Audio Codec Compare [PCMA:8:8000:30:32000:1]/[PCMA:8:8000:20:64000:1]
Audio Codec Compare [PCMA:8:8000:30:32000:1]/[GSM:3:8000:20:13200:1]
...
Hangup sofia/internal/1000@xxx.xxx.xxx [CS_NEW] [INCOMPATIBLE_DESTINATION]

Es konnte kein kompatibler Codec für beide Geräte (SIP-Telefon und FreeSwitch) gefunden werden.

Grund dafür ist, dass der unter Debian Wheezy (auf dem Raspbian aktuell basiert) GCC 4.6 als Standard-Compiler verwendet und GCC 4.6 auf der ARM-Plattform FreeSwitch falsch übersetzt. quentusrex hat den Fehler umfangreich analysiert und dokumentiert und bereits Bugreports erstellt.

Abhilfe schafft erst GCC 4.7. Mit folgenden Kommandos wird GCC 4.7 auf dem Raspberry Pi 2 installiert und als Default-Compiler eingerichtet. Beim letzten Kommando erscheint eine Auswahl, in der 4.7 als Default gewählt werden kann (Quelle).

$ sudo apt-get install gcc-4.7 g++-4.7
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7
$ sudo update-alternatives --config gcc

Anschließend muss natürlich FreeSwitch noch einmal kompiliert werden. Danach jedoch funktioniert die Codec-Auswahl korrekt.

Ich wollte auf einem komplett neu aufgesetzten Raspbian FusionPBX entsprechend der Anleitung installieren. Verwenden wollte ich die vorgeschlagene Konfiguration mit Nginx und Sqlite. Leider schlägt nach ein paar Stunden Kompilieren der letzte Konfigurationsschritt im Webbrowser fehl, da das Timeout in Nginx für FastCGI-Skripte (in dem Fall PHP) in der Standardeinstellung zu kurz eingestellt ist. Der kleine Raspi müht sich nach Kräften, schafft es aber nicht in der vorgegebenen Zeit. Die Einrichtung im Webbrowser schlägt mit "Gateway-Timeout" fehl. Abhilfe schafft der Eintrag

fastcgi_read_timeout 300;

in der Datei /etc/nginx/fastcgi_params. Nginx-Restart nicht vergessen. Damit die abschließende Konfiguration von FusionPBX neu gestartet wird, muss noch die Datei /var/www/fusionpbx/resources/config.php gelöscht und die Webseite auf dem Raspi neu aufgerufen werden.

2

Wer K-9 Mail benutzt (nebenbei das beliebtestet OpenSoure-Programm für E-Mails unter Android) und zur Verschlüsselung der E-Mails mit PGP OpenKeychain verwendet, wird über kurz oder lang vor folgendem Problem stehen: dem Verschlüsseln von Anhängen.

Leider unterstützt K-9 Mail bisher den Standard PGP-MIME nicht, sondern kann verschlüsselte Nachrichten nur im Format PGP-Inline verschicken. Daraus ergeben sich gleich zwei Probleme:

  1. Beim Versenden von verschlüsselten Nachrichten wird nur der Nachrichtentext verschlüsselt. Etwaige Anhänge werden unverschlüsselt verschickt.Dieses Problem kann umgangen werden, indem die Anhänge zuerst mit OpenKeychain verschlüsselt werden und diese verschlüsselten Dateien dann der E-Mail angehängt werden. Sehr unhandlich.
  2. Beim Empfang von PGP-verschlüsselten Nachrichten können nur per PGP-Inline-kodierte Nachrichten sofort in K-9 Mail angezeigt werden.PGP-MIME-kodierte Nachrichten müssen erst abgespeichert werden und können anschließend in OpenKeychain entschlüsselt werden. Ebenfalls sehr unhandlich.

Wie man in folgenden Thread nachlesen kann, sind für die Implementierung von PGP-MIME in K-9 Mail umfassende Arbeiten an der Storage-Engine notwendig. Leider hat bis heute noch niemand entsprechend Zeit für eine Implementierung gefunden, obwohl es anscheinend zu den am meisten von den Benutzern gewünschten Erweiterungen zählt (inklusive mir). Wer mag, kann einen Anreiz für die Entwickler schaffen, indem er sie finanziell unterstützt. Ein entsprechende Seite bei Bountysource ist eingerichtet und steht aktuell bei US$ 1.015.