Springe zum Inhalt

Noch bis zum 14.06.2015 läuft bei Conrad eine Aktion, bei der Vorschläge für ein 3D-druckfähiges Raspberry Pi 2 Case eingereicht werden können. Es werden die drei kreativsten Vorschläge ausgewählt und die Gewinner erhalten ihr Gehäuse ausgedruckt aus dem 3D-Drucker. Anschließend wird noch ein Hauptgewinner ermittelt, der zusätzlich ein von Conrad zusammengestelltes "Raspberry Pi 2 Model B Advanced-Set 1 GB" erhält.

Mehr Informationen und den Modalitäten sind auf einer eigens für diese Aktion eingerichtete Webseite zu erfahren.

1

Die Kombination aus FusionPBX und FreeSwitch stellt eine einfach zu installierende "Voice over IP"-Telefonanlage bereit, die für Privatanwender als auch für anspruchsvolle Lösungen interessant und einsatzfähig ist.

Nach der Installation und dem Durchführen der ersten Schritte sind Telefonate im internen Netz möglich. Bei ausgehenden Anrufen legt einem allerdings die Telekom einige Steine in den Weg. Die Telekom-VoIP-Server akzeptieren nicht irgendwelche Absenderadressen wie z.B. die intern gesetzte Extension. Ohne Anpassung werden Anrufe dann nur mit einem Statuscode "407 Forbidden" quittiert.

Ausgehende Anrufe

Für ein Gateway zur Telekom muss immer die korrekte Telekom-Telefonnummer als Absender in den SIP-Nachrichten mitgeteilt werden. In FusionPBX kann die korrekte Nummer unter Dialplan -> Outbound Routes eingestellt werden. Vor der Aktion bridge müssen folgende Aktionen eingefügt werden:

FusionPBX Outgoing Routes Settings

Für effective_caller_id_number und effective_caller_id_name muss die vollständige Telefonnummer inklusive Vorwahl angegeben werden. Damit erhalten alle ausgehenden Anrufe über dieses Gateway die von der Telekom geforderte Rufnummer.

Eingehende Anrufe

Da man mit einem Telekom-VoIP-Anschluss grundsätzlich drei Telefonnumern erhält (analog ISDN), ist es naheliegend, in FusionPBX drei Gateways mit je einer Rufnummer einzurichten. FusionPBX verwendet allerdings zur weiteren Verarbeitung des eingehende Anrufs den Usernamen, welcher bei allen Telekom-Rufnummern gleich ist. Eine Behandlung des Anrufs pro Rufnummer ist dadurch nicht möglich.

Abhilfe schafft der Eintrag der eigenen Telefonnummer pro Gateway. In FusionPBX erreicht man das mit folgenden Einstellungen beim entsprechenden Gateway unter Accounts -> Gateways:

FusionPBX Gateway Telekom Settings

  • Gateway: frei wählbarer Name des Gateways
  • Username: Telekom E-Mail-Adresse, z.B. mustermann@t-online.de
  • Password: das für Webzugriff im Telekom-Kundencenter eingestellte Kennwort
  • From User: eigene Telefonnummer inklusive Vorwahl
  • Proxy und Realm: tel.t-online.de
  • Extension: eigene Telefonnummer inklusive Vorwahl

Mit den obigen Einstellungen sind Anrufe nach Extern möglich, da sie entsprechend den Telekom-Anforderungen gesendet werden. Ebenso ist eine Unterscheidung der eingehenden Anrufe nach den eingestellten Rufnummern möglich.

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.