VPN-Roadwarrior Linux vs. LANCOM-Router

Aus Ethersex_Wiki
Wechseln zu: Navigation, Suche

Nachdem ich selbst eine VPN-Einwahl als Roadwarrior von einem Linux-Rechner aus gegenüber einem LANCOM 1621 VPN-Router bewerkstelligen musste/wollte, und ich dabei einige Male gestolpert bin, hier ein kleines Howto:

Konfiguration des Routers

Im Assistenten erstmal auf Einwahl-Zugang bereitstellen gehen:

Lancom-vpn-assistent.jpg

VPN-Verbindung über das Internet ...

Lancom-vpn-schritt1.jpg

... aber ohne dieses proprietären Advanced VPN Client aus dem Hause ICP, äh LANCOM ...

Lancom-vpn-schritt2.jpg

Die VPN-Verbindung bekommt einen Router-internen Namen (welcher ist relativ egal) ...

Lancom-vpn-schritt3.jpg

wir machen Pre-shared Key Authentifizierung, also Key festlegen (den brauchen wir auf der anderen Seite dann auch) ...

Lancom-vpn-schritt4.jpg

weiter ...

Lancom-vpn-schritt5.jpg

keine lokale Identität, wir bauen eh die Verbindung vom Roadwarrior zum Router auf, von daher muss der sich nicht ausweisen können. Die Gegenseite authentifiziert sich mit FQDN:

Lancom-vpn-schritt6.jpg

dreimal weiter (PFS Gruppe 2) ...

Lancom-vpn-schritt7.jpg Lancom-vpn-schritt8.jpg Lancom-vpn-schritt9.jpg

Die Gegenstelle braucht natürlich eine IP. Ich habe eine außerhalb der LAN-Adressen, dann fällt besser auf, dass die Kiste eingewählt ist. Aber das LAN muss natürlich den Router als Default-Gateway verwenden (sollte aber wohl eh Standard sein):

Lancom-vpn-schritt10.jpg

Nochmal zweimal weiter, dann sind wir fertig:

Lancom-vpn-schritt11.jpg Lancom-vpn-schritt12.jpg

Stolperstein VPN-Gateway == DSL-Gateway

Der Linux IPsec-Stack macht gewaltig Probleme, wenn man die VPN-Einwahl von dem Rechner durchführen möchte, der auch die DSL-Einwahl macht. Umgekehrt kann man IPsec-Pakete (ohne NAT-Traversal) aber auch nicht durch eine NAT schieben.

Hintergrund ist, dass die Pakete bevor sie in die IPsec-Schicht des Kernels wandern schon die lokale IP-Adresse von ppp0 als Absender tragen und damit nicht mehr von den VPN-Regeln erfasst werden. Bzw. wenn man die Regeln so aufstellt, dass sie erfasst werden, die VPN-Gegenseite nichts mehr damit anfangen kann, ...

Am besten löst man das dadurch, dass man sich noch mind. eine weitere IP-Adresse vom LANCOM aus zurouten lässt (am besten gleich ein /24-er Netz, das geht in der Konfiguration unter IP-Router/Routing-Tabelle bequem) und dann im LAN weitere Rechner verwendet um darauf zuzugreifen. Wenn's die gleiche Kiste sein soll, tut's ein kleines UML.

Konfiguration des Roadwarriors

Zunächst ist das Paket racoon zu installieren. Das funktioniert am schmerzfreisten.

  • REMOTEIP = öffentliche IP-Adresse des VPN-Einwahlrechners
  • REMOTENET = IP-Adresse des entfernten Netzes/Maske (z.B. 10.23.42.0/24)
  • LOCALNET = IP-Adresse des lokalen Netzes/Maske (z.B. 192.168.42.0/24)

In die /etc/racoon/racoon.conf Folgendes mit einfügen:

remote REMOTEIP {
        exchange_mode   aggressive;
        my_identifier   fqdn "sledgehammer.metafnord.de";

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address LOCALNET[any] any address REMOTENET[any] any {
        pfs_group 2;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

In der /etc/racoon/psk.txt braucht's dann noch

REMOTEIP        hierdenpskangeben

Last but not least muss noch der Kernel informiert werden, was IPsec-behandelt werden muss. Nachdem sich unsere IP-Adresse mit jeder DSL-Einwahl ändert und die Regeln davon abhängen, legen wir ein neues Skript /etc/ppp/ip-up.d/setkey an (REMOTEIP, REMOTENET und LOCALNET wieder ersetzen):

#!/bin/bash

setkey -c <<FNORD
# Flush SAD and SPD
flush;
spdflush;

# Richtlinien
spdadd LOCALNET REMOTENET any -P out ipsec
        esp/tunnel/$PPP_LOCAL-REMOTEIP/require;

spdadd REMOTENET LOCALNET any -P in ipsec
        esp/tunnel/REMOTEIP-$PPP_LOCAL/require;
FNORD