Monat: September 2011

VPN-Unterstützung für Android-Endgeräte – Konfiguration der Klienten

Die letzten Tage habe ich mit der Integration von VPN für Android-Geräte verbracht. An dieser Stelle entschuldige ich mich vorab für mehrere Verbindungsabbrüche bei den Nutzern, die den IPSec-Klienten verwenden, denn durch die Umstellung der Verschlüsselungskonfiguration musste ich mehrmals morgens die IPSec-Verbindungen trennen.

Einige der Android-Smartphones von Samsung haben schon vor einigen Monaten VPN-Unterstützung in Form des AnyConnect-Klienten erhalten. Dieser verwendet als Protokoll SSL-VPN und sollte somit die wenigsten Probleme mit Firewalls etc. haben, da die Kommunikation nur über den Port 443 (TCP und UDP) und alle Sessions nur vom Klienten aufgebaut werden. Ich empfehle daher, diesen weiterhin zu verwenden, wo dieser verfügbar ist.

Um die restlichen Android-Endgeräte ua. auch  Tablets mit VPN zu versorgen, musste ein völlig anderer Typ von VPN aktiviert werden, L2TP-IPSec.  Dabei wird zuerst eine IPSec-Verbindung aufgebaut, in der wiederum ein L2TP-Tunnel erstellt wird.

Wie dies auf den Endgeräten konfiguriert wird habe ich exemplarisch unter http://rrzk.uni-koeln.de/vpnandroid.html dokumentiert. Da die Hersteller teilweise die Bezeichnungen und Menüstruktur verändern, können diese unter Umständen abweichen.

Bei der Verschlüsselung habe ich mich für mehr Sicherheit und damit für AES gegenüber 3DES entschieden. In der Literatur wird AES oft als ressourcenlastiger bezeichnet, was gerade bei den leistungsschwächeren Mobilgeräten in einem höheren Energiebedarf und somit einer kürzeren Batterielaufzeit resultieren könnte. Dazu habe ich aber keine Informationen gefunden und kann die Problematik daher nicht bewerten.

Ich bin gespannt, wie hoch die Nutzung von VPN über Android sein wird. Leider dauert es ja oft, bis sich die Nachricht über die neue Unterstützung von Endgeräten herumspricht.

 

Anleitung zur Einrichtung von L2TP-IPSec unter Android: http://rrzk.uni-koeln.de/vpnandroid.html

Enabling VPN for Android devices – configuration of Cisco ASA

With the new ASA versions 8.3.2.12 or 8.4.1 Cisco announced the support for native VPN on Android devices. Implementing the configuration changes in an existing and running environment can be quite tricky.

For the Android devices the ASA has to offer a L2TP/IPSec tunnel. The IPSec tunnel has to be in transport mode. Since normally the IPSec tunnels are configured in tunnel mode you will encounter the problems of having a mixture of tunnel and transport mode.

The document https://supportforums.cisco.com/docs/DOC-17798 gives a good example on how to configure the tunnel in a new environment.

If you already have an existing crypto-map or dynamic-map for the other IPSec clients and try to add a second one with a higher or lower priority you will end up with an IPSec phase 2 that fails with the error message “All IPSec SA proposals found unacceptable!” for clients using the map with the lower priority.

You can solve this problem only through implementing the two modes via two transform-sets using one single dynamic map.

Example:

crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec ikev1 transform-set l2tptransform-set esp-aes esp-md5-hmac

crypto ipsec ikev1 transform-set l2tptransform-set mode transport

crypto dynamic-map public_dyn_map 30 set ikev1 transform-set ESP-AES-256-SHA l2tptransform-set

The order of the transform-sets in the dynamic-map defines their priority with the highest from the left.

Have in mind that changing the dynamic-map results in disconnection of all IPSec sessions.

OpenAFS 1.7.1 und die Windows-Firewall

Seit heute gibt es die neue OpenAFS-Version 1.7.1, die insbesondere für neuere Windows-Versionen dringend empfohlen ist. Allerdings gab es direkt nach der Installation noch ein paar Probleme:

Man muss leider noch von Hand die Windows-Firewall passend konfigurieren, wenn man als Netzwerkumgebung *nicht* public/öffentlich konfiguriert hat:

Systemsteuerung->
System und Sicherheit->
Windows Firewall->
Ein Programm oder Feature durch die Windows-Firewall zulassen

Dort muss für „AFS CacheManager Callback (UDP)“ das Häkchen bei „Heim/Arbeit (Privat)“ gesetzt sein.

Wenn der lokale Username und das Passwort nicht mit dem im AFS übereinstimmen, muss man sich außerdem auf anderem Weg ein Token besorgen. Dazu öffnet man die Eingabeaufforderung und gibt dort

klog username

an, wobei „username“ durch den Usernamen im AFS zu ersetzen ist.

Schöner neuer Kernel

Linus Torvalds erfreut uns in diesen Tagen mit dem Kernel 3.x, der bei nahezu allen Desktop-Linuxen inzwischen in den Repos bereitsteht. Das Upgrade hat für mich und meinen Dell-Laptop zwei ärgerliche Probleme mitgebracht, die ich inzwischen zumindest halbwegs lösen konnte. Da an der Uni wohl noch ein paar andere darüber stolpern werden, hier meine Hinweise:

  1. OpenAFS: Seit Kernel 2.6.39 wird der AFS-Client 1.4.x nicht mehr unterstützt, man ist zum Update auf 1.6.x gezwungen. Dieser lag bis vor wenigen Tagen noch in einer Pre-Version vor, inzwischen ist er als stable markiert. Die Doku ist nach wie vor ein Traum, sodass mir spontan niemand erklären konnte, warum ich plötzlich auf keine RRZK-Volumes mehr zugreifen konnte. Nach langem Testen konnte ich das Ganze nun auf Firewall-Probleme zurückführen. Weitere Eingrenzung war mir noch nicht möglich, da selbst bei eingetragener Freigabe der erste Zugriff nach laaaanger Zeit in einem Timeout endet. Erst ab dem zweiten Zugriff geht’s dann wieder flott.
  2. Suspend: Nach dem Update auf Kernel 3.0 krachte mein Laptop (Dell Latitude E4300) bei jeglichen Suspend-Versuchen zusammen. Auch hier musste ich lange suchen, um den Schuldigen zu finden. Schließlich konnte ich das „mac80211“-Modul, welches für WLAN zuständig ist,  als Ursache identifizieren. Da scheint sich ein Bug eingeschlichen zu haben (siehe auch diesen Hinweis), den man entweder wie im Link angegeben patchen oder weiträumig umgehen kann. Dazu genügt das Anlegen der Datei 
    /etc/pm/config.d/unload_modules

    mit dem Inhalt

    SUSPEND_MODULES="$SUSPEND_MODULES mac80211"

    Zumindest Suspend-to-RAM (a.k.a. „Bereitschaft“) klappt danach bei mir problemlos, Suspend-to-Disk (a.k.a. „Ruhezustand“) klappt zwar zunächst ebenfalls, das Aufwachen endet jedoch leider in einem normalen Systemstart. Da ich s2disk jedoch eh fast nie verwende, verfolge ich das nicht weiter. Kommentare mit der Lösung sind natürlich dennoch erwünscht. 😉