IPSec VPN WatchGuard <=> Android (nativer Client)

Dieser Artikel beschreibt die Anbindung eines Android 6.0.1 Marshmallow mit dem Native Client per IPSec an eine WatchGuard Firebox/XTM.

Nativer Client

Die in der WatchGuard Help (Stand: 04.08.2016) angegebenen Hinweise auf die IPSec Proposals beziehen sich auf Android 4.x. Dort steht “do not use SHA2 in the Phase 1 and Phase 2 settings. SHA2 is not supported on the VPN clients on Android devices”. Mittlerweile wird jedoch SHA1 als nicht mehr ausreichend sicher eingestuft und soll eigentlich nicht mehr verwendet werden. SHA2 wird inzwischen von Android in Phase 1 und Phase 2 unterstützt. Theoretisch zumindest.
Leider funktioniert genau dieses SHA2 in Phase 2 nicht richtig. Es wird zwar eine Verbindung hergestellt, aber danach kann kein SA ausgehandelt werden, womit das Android-Device ohne Routing gar nicht mehr kommunizieren kann. Hier folgt eine genauere Betrachtung der Proposals und eine Anleitung mit funktionierenden Parametern.

Nach dem Anschalten der Debug-Logs für IKE auf der WatchGuard und durch Setzen eines nicht unterstützten Phase-2-Proposals auf der WatchGuard (hier: SHA2-AES-512) kann man alle Proposals und die Reihenfolge im Log ablesen. Die verwendeten Phase-2-Proposals des Android Clients sind (Cyanogemmod 13, Android 6.0.1, patchlevel 5. August 2016):

  1. ESP-HMAC-SHA2-256
  2. ESP-HMAC SHA1
  3. ESP-HMAC-MD5
  4. AES-128
  5. ESP authentication none
  6. ESP-3DES
  7. ESP-DES

Man erkennt, dass inzwischen mit folgenden Default Proposals gearbeitet wird:

Phase 1

  • Authentication: SHA2-256
  • Encryption: AES-256
  • Diffie-Hellman Group 2

Phase 2

  • ESP
  • Authentication: SHA2-256
  • Encryption: AES-256
  • kein PFS

Nach dem Abgleichen der Parameter kommt sofort ein Connect zustande, aber leider kein Datentransfer. Internet-Recherche bringt zutage, dass der Android-VPN-Client in Marshmallow 6.0.1 leider eine “seltsame” SHA2-Implementierung verwendet, und diese auch noch für das Default Proposal eingesetzt wird. (https://code.google.com/p/android/issues/detail?id=196939)

[...] It seems the version of SHA2-256 that Android 6.x.x is using is an older draft specification and the one implemented in many other IPsec implementations uses the official SHA2-256 implementation with the correct padding and whatever else. [...]

(04-Jun-2016):
This issue is fixed internally and fix will be available in future releases.

Stellt man das Phase 2 Proposal auf SHA1 zurück, wird das Default ESP-SHA2-256-AES-256 Proposal des Android-Clients von der WatchGuard verworfen und der Client versucht anschließend, mit dem folgenden Proposal eine Verbindung aufzubauen. Dies klappt dann schließlich auch.

Funktionierende Einstellungen:

android-ipsec-1

  • Group Name: Android – wird beim Client nochmal benötigt.

Phase 1:

  • Authentication: SHA2-256
  • Encryption: AES-256
  • Diffie-Hellman Group 2 (wird unter Advanced eingestellt):

android-ipsec-2

 

android-ipsec-3

 

Phase 2 Proposal

  • ESP
  • Authentication: SHA1
  • Encryption: AES-256
  • kein PFS

 

 

 

android-ipsec-4

 

 

 

Der komplette Traffic wird durch den Tunnel geroutet, die Resourcen Any-External und 0.0.0.0/0 werden dadurch automatisch angelegt. 

 

 

 

 

 

 

 

 

 

 

 

Einstellungen beim Android Client:

android-nativ-ipsec-client-1     android-nativ-ipsec-client-2

  • IPSec-ID ist der oben definierte Group Name (“Android”)
  • Die erweiterten Optionen können leer bleiben.

Tests

Nach dem Connect durch den Android Client sollte man über z.B. www.wieistmeineip.de testen, ob das Routing durch die Firewall sauber funktioniert. Dort sollte dann als Quell-IP die öffentliche IP der WatchGuard angezeigt werden, mit der man per VPN verbunden ist.

Leave a Reply

Your email address will not be published. Required fields are marked *