Archiv für Juli 2010

IPsec VPN mit strongSwan und FRITZ!Box Fon WLAN 7270 v3

Gestern musste ich eine VPN-Verbindung zwischen strongSwan (4.1.11) und einer FRITZ!Box 7270 v3 (74.04.80) einrichten. Die Einrichtung von VPN auf der FRITZ!Box ist etwas ungwöhnlich: Die Konfiguration findet nicht wie üblich über das Web Interface oder die Kommandozeile statt, sondern muss über das AVM eigene Windows-Programm „FRITZ!Fernzugang einrichten“ erstellt werden.

Nach der Installation des entsprechenden Programms wird zunächst ausgewählt, dass eine Verbindung zwischen zwei FRITZ!Box-Netzwerken eingerichtet werden soll:

Danach wird entweder die IP-Adresse oder der DynDNS-Name der FRITZ!Box angegeben:

…und das interne Netzwerk hinter der FRITZ!Box:

Im nächsten Schritt fragt der Assistent exakt dieselben Daten für die Gegenstelle ab und erzeugt zwei entsprechende Konfigurationsdateien. Bevor die Konfigurationsdatei für die FRITZ!Box importiert werden kann, müssen allerdings noch einige Einstellungen angepasst werden.

Im Fall von strongSwan auf der Gegenseite betrifft das einmal den Austausch vom IKEv1 Aggressive Mode gegen den Main Mode und das Ersetzen des vorgegebenen Pre Shared Keys. Am Ende sollte die Konfigurationsdatei wie folgt aussehen (Änderungen rot markiert):

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "193.99.144.85";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 193.99.144.85;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "layer9.dyndns.org";
                }
                remoteid {
                        ipaddr = 193.99.144.85;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "Dh9tgxD8p5HNhQedKfiDoA93";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.100.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 172.16.0.0;
                                mask = 255.255.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 172.16.0.0 255.255.0.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF

Anschließend kann die Datei auf der FRITZ!Box unter Erweiterte Einstellungen -> Internet -> Freigaben -> VPN importiert werden. Weitere Informationen zur Anpassung der Konfigurationsdateien gibt es übrigens hier und hier.

Die Tunneldefinition in der ipsec.conf von strongSwan sieht folgendermaßen aus:

conn berlin-layer9
        left=193.99.144.85
        leftsubnet=172.16.0.0/16
        #
        ike=aes128-sha-modp1024
        esp=aes128-sha1
        #
        right=layer9.dyndns.org
        rightid=@layer9.dyndns.org
        rightsubnet=192.168.100.0/24
        #
        ikelifetime=4h
        keylife=1h
        #
        authby=secret
        auto=add

Wird wie hier in der FRITZ!Box Konfigurationsdatei der DynDNS Name angegeben, muss dies unter strongSwan sowohl in der Tunnelkonfiguration mittels rightid=@layer9.dyndns.org als auch beim Eintrag des PSK in der ipsec.secrets berücksichtigt werden. Andernfalls erwartet strongSwan trotz Angabe von right=layer9.dyndns.org die IP-Adresse als Peer ID:

debian:~# ipsec up berlin-layer9

002 "berlin-layer9" #30802: initiating Main Mode
104 "berlin-layer9" #30802: STATE_MAIN_I1: initiate
003 "berlin-layer9" #30802: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
003 "berlin-layer9" #30802: received Vendor ID payload [XAUTH]
003 "berlin-layer9" #30802: received Vendor ID payload [Dead Peer Detection]
003 "berlin-layer9" #30802: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
003 "berlin-layer9" #30802: ignoring Vendor ID payload [a2226fc364500f5634ff77db3b74f41b]
002 "berlin-layer9" #30802: enabling possible NAT-traversal with method RFC 3947
106 "berlin-layer9" #30802: STATE_MAIN_I2: sent MI2, expecting MR2
003 "berlin-layer9" #30802: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
108 "berlin-layer9" #30802: STATE_MAIN_I3: sent MI3, expecting MR3
003 "berlin-layer9" #30802: ignoring informational payload, type IPSEC_INITIAL_CONTACT
002 "berlin-layer9" #30802: Peer ID is ID_FQDN: '@layer9.dyndns.org'
003 "berlin-layer9" #30802: we require peer to have ID '72.14.221.104', but peer declares '@layer9.dyndns.org'
218 "berlin-layer9" #30802: STATE_MAIN_I3: INVALID_ID_INFORMATION
002 "berlin-layer9" #30802: sending encrypted notification INVALID_ID_INFORMATION to 72.14.221.104:4500

Bleibt im Fall von DynDNS noch das Problem, dass strongSwan den DNS-Eintrag nur beim Starten oder Aktualisieren der Konfiguration neu auflöst. Offenbar kann man strongSwan aber so konfigurieren, dass die Konfiguration in gewissen Abständen automatisch aktualisiert wird (Stichwort ipsec starter –auto-update). Getestet habe ich das bis jetzt noch nicht; wir haben dem Betreiber der FRITZ!Box stattdessen eine feste IP-Adresse empfohlen.

Advertisements

HP Insight Management Agents: Installation unter Windows Server 2003 hängt

Im Rahmen der Migration einer Windows Server 2003 SP2 Installation von einem HP ProLiant DL380 G4 auf einen DL360 G5 hatte ich heute Probleme beim Installieren der HP Insight Management Agents.

Das erste Problem trat bei der Deinstallation der alten Version auf. Beim jedem Versuch, die Management Agents über die Systemsteuerung zu entfernen, passierte schlicht gar nichts. Nur im abgesicherten Modus von Windows ließ sich die Deinstallation erfolgreich durchführen.

Kniffliger war allerdings die Installation der neuen Version (8.50.0.0). Auch hier tat sich kurz nach Aufruf der Installationsroutine nichts mehr und selbst nach 15 Minuten Wartezeit hing das Setup immer noch an derselben Stelle:

Durch Zufall habe ich dann festgestellt, dass sich der SNMP Dienst von Windows gerade im Status „wird beendet“ befand. Unmittelbar nach dem manuellen Beenden des entsprechenden Prozesses lief das Setup erfolgreich bis zum Ende durch. Möglicherweise waren die Probleme mit dem SNMP-Dienst auch die Ursache für die Schwierigkeiten bei der Deinstallation.

Wie auch immer, nach einem Reboot befanden sich sowohl der SNMP Dienst von Windows als auch die entsprechenden HP-Dienste im Status „gestartet“ und alles lief ohne Probleme.