Archiv für Mai 2010

Probleme mit IPsec zwischen strongSwan und Lancom 7111

Gestern kam es zu anfänglich merkwürdigen Problemen bei einer IPSec net-net Verbindung zwischen strongSwan 4.2.4 und dem Lancom VPN Gateway 7111. Während der Tunnelaufbau vom Lancom Gateway aus problemlos funktionierte, ließ sich die Verbindung von der Gegenseite aus nicht initiieren. Bei jedem Versuch wurden auf dem strongSwan Gateway folgende Fehler protokolliert:

May 19 15:36:38 gw pluto[1865]: ERROR: asynchronous network error report on eth0 for message to 112.125.211.97 port 500, complainant 112.125.211.97: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
May 19 15:36:38 gw pluto[1865]: packet from 112.125.211.97:500: ignoring informational payload, type PAYLOAD_MALFORMED
May 19 15:36:38 gw pluto[1865]: ERROR: asynchronous network error report on eth0 for message to 112.125.211.97 port 500, complainant 112.125.211.97: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
May 19 15:36:38 gw pluto[1865]: packet from 112.125.211.97:500: ignoring informational payload, type INVALID_COOKIE
May 19 15:37:38 gw pluto[1865]: "net-net" #50: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
May 19 15:37:38 gw pluto[1865]: "net-net" #50: starting keying attempt 3 of at most 3
May 19 15:37:38 gw pluto[1865]: "net-net" #51: initiating Main Mode to replace #50
May 19 15:37:38 gw pluto[1865]: "net-net" #51: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
May 19 15:37:38 gw pluto[1865]: "net-net" #51: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
May 19 15:37:38 gw pluto[1865]: "net-net" #51: received Vendor ID payload [RFC 3947]
May 19 15:37:38 gw pluto[1865]: "net-net" #51: ignoring Vendor ID payload [eeefa37809e32ad4de4f6b010c26a640]
May 19 15:37:38 gw pluto[1865]: "net-net" #51: received Vendor ID payload [Dead Peer Detection]
May 19 15:37:38 gw pluto[1865]: "net-net" #51: enabling possible NAT-traversal with method 3
May 19 15:37:38 gw pluto[1865]: "net-net" #51: NAT-Traversal: Result using RFC 3947: no NAT detected
May 19 15:37:39 gw pluto[1865]: ERROR: asynchronous network error report on eth0 for message to net-net port 500, complainant 112.125.211.97: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
May 19 15:37:39 gw pluto[1865]: packet from 112.125.211.97:500: ignoring informational payload, type INVALID_PAYLOAD_TYPE

Auf dem Lancom Gateway kam es dabei zu folgender Fehlermeldung:

VPN: Error: IKE-R-IKE-key-mismatch (0x220a) for NET (123.14.60.87)

Als erstes haben wir natürlich die Einstellungen für Phase 1 und Phase 2 verglichen – auf den ersten Blick alles identisch. Auf den zweiten Blick stelle sich dann allerdings ein kleiner Unterschied heraus: Während die für die Tunneldefinition gewählte AES-Verschlüsselung auf dem Lancom 7111 fest mit 128 Bit konfiguriert war, waren die entsprechenden Parameter von strongSwan mit ike=aes-sha-modp1536 bzw. esp=aes-sha1 ohne explizite Angabe der Verschlüsselungsstärke definiert.

Offenbar akzeptiert strongSwan in diesem Fall sowohl Proposals mit 128- als auch 256 Bit, weshalb die vom Lancom Gateway initiierte Verbindung problemlos funktionierte. Dagegen scheint es für das Gerät ein Problem zu sein, wenn die Verbindung von strongSwan initiiert wird und dort die Verschlüsselungsstärke nicht explizit definiert ist. Erst nach Änderung der strongSwan Konfiguration auf ike=aes128-sha-modp1536 bzw. esp=aes128-sha1 ließ sich die Verbindung auch von dort aus fehlerfrei initiieren.

Advertisements

Automatisches Backup von Linux-Konfigurationsdateien mit ZIP und FTP

Insbesondere wer Linux als Server einsetzt, tut gut an einem regelmäßigen Backup der Konfigurationsdateien. Möglich ist das zum Beispiel mit einem Script, das die entsprechenden Dateien in ein ZIP-Archiv kopiert und anschließend auf einen FTP Server lädt. Neben einem FTP Server werden dafür lediglich die Programme zip und ftp benötigt, die unter Debian wie folgt installiert werden:

debian:~# apt-get install zip ftp

Sind die Programme installiert, lässt sich das Backup z.B. mit folgendem Script realisieren:

#!/bin/sh
#
### INFO ###
#
# Zippen der Konfiguration und Upload per FTP
# Usage: /etc/init.d/backup-config
# Author: layer9 at gmx.de
#
### INFO ###

# specify name and location of backup file 
  BACKUPFILE=/opt/backup/$HOSTNAME-backup.zip

# create function
  function backup() {

# specify and move files and directories to zip archive
  zip -u -r $BACKUPFILE /etc/ipsec.conf \
                        /etc/ipsec.secrets \
                        /etc/squid/squid.conf \
                        /root/ssl/*

# upload only if archived has changed and there were no errors
  if [ $? = 0 ];
    then
      # upload compressed backup file to ftp server
        ftp -n -i -v <<-EOF
        open ftp.hostname.de
        user maxmustermann password123
        binary
        put $BACKUPFILE /backup/$HOSTNAME-backup.zip
        quit
      # be careful: no spaces before EOF allowed!
        EOF
     else
       echo "no ftp upload due to error or unchanged archive"
  fi
 }

# call function and print output to syslog
  backup 2>&1 | logger -i -t backup-config

exit 0

Zuerst werden mit der Variable $BACKUPFILE Dateiname und Pfad der zu erzeugenden ZIP-Datei angegeben. Direkt dahinter folgen die Dateien und Verzeichnisse, die dem Archiv hinzugefügt werden sollen. Die Parameter -u und -r bewirken, dass das Archiv nur bei geänderten Quelldateien aktualisiert wird und alle Unterordner und Dateien mit einbezogen werden sollen.

Anschließend wird anhand des Exit-Status geprüft, ob es während der Kompression zu Fehlern kam. Lautet der Status „0“, sind keine Fehler aufgreteten und die Datei wird in das Verzeichnis /backup/ auf den angegebenen FTP-Server geladen. Bei allen anderen Exit Codes wird die Datei nicht hochgeladen – neben Fehlern bei der Kompression ist dies z.B. auch bei einem unveränderten Archiv der Fall. So wird die Datei auf dem FTP-Server nur dann aktualisiert, wenn sich die im Archiv enthaltenen Dateien auch tatsächlich geändert haben. Am Ende des Scripts wird die Funktion aufgerufen und die Ausgabe mittels logger an Syslog weitergeleitet.

Achtung: Vor dem EOF am Ende der Schleife darf sich kein Leerzeichen befinden (TAB funktioniert) – andernfalls kommt es zu folgender Fehlermeldung:

/etc/init.d/backup-config: line 35: syntax error: unexpected end of file

Natürlich lässt sich das Script noch weiter verfeinern, z.B. durch eine Versionierung der Backupdatei oder die Einzelprüfung der Exit Codes. In vielen Fällen wird das aber vermutlich nicht erforderlich sein; ich z.B. lasse das Script per Cronjob einmal täglich laufen und die hochgeladene Datei anschließend auf dem FTP-Server durch die tägliche Bandsicherung sichern – funktioniert prima.