VPN einrichten mit LiSS und strongSwan

Mit einem Site-to-Site VPN lassen sich die IP-Netzwerke von zwei Standorten mitander verbinden. Geräte wie Server, Netzwerkfestplatten und Telefonanlagen sind damit aus beiden vernetzten Standorten erreichbar. Zum Aufbau eines Site-to-Site VPN dürfen sich die IP-Netze der Standorte nicht überschneiden. Jeder Standort benötigt einen VPN-Router.

Dieses Tutorial beschreibt den Aufbau einer LAN-LAN-Kopplung mit einer Telco-Tech LiSS 1000 Series und einem VPN-Gateway mit strongSwan. Jeder Router benötigt eine statische WAN-IP oder einen Hostnamen (z.B. von DynDNS). Im Beipiel kommt IPSec mit ESP im Main Mode zum Einsatz.

Telco-Tech bietet mit seiner LiSS-Serie Sicherheits-Lösungen für SOHO und SMB an. Das kleinste Modell LiSS 700 eignet sich für die Netzanbindung des Heimbüros. Die LiSS 5000 verfügt über vier Gigabit Interface und eignet sich auch zum Schutz großer Netzwerke. Diese Anleitung basiert auf einer LiSS 1000 mit der Firmware 3.18.2-1902.

strongSwan ist eine IPsec-Implementierung für Linux. Für dieses Tutorial habe ich strongSwan 4.3.1 unter debian Linux (Kernel 2.6.18) genutzt.

VPN Netzwerkaufbau

In unserem Beispiel verbindet der VPN-Tunnel zwei Standorte in Berlin. Das IP-Netz 192.168.1.0/24 (LAN der LiSS) soll mit dem Netz 10.0.0.0/8 (strongSwan) verbunden werden.

VPN Parameter

Der VPN-Tunnel wird mit den folgenden Parametern aufgebaut.

Die Authentifizierung erfolgt über X.509-Zertifikate. Alle Zertifikate wurden mit OpenSSL unter debian Linux erzeugt.

VPN auf der LiSS einrichten

X.509 Zertifikate importieren

Die mittels OpenSSL generierten Zertifikate müssen in die LiSS importiert werden. Das passiert unter Einstellungen :: System :: Zertifikate.

Für den Import müssen die Zertifikate im PEM-Format vorliegen. Die Zertifikate (bzw. der Schlüssel) dürfen nicht durch ein Passwort (Pass Phrase) geschützt sein, da die LiSS ansonsten das Zertifikat nicht nutzen kann. Laut Handbuch wird das CA-Zertifikat nicht genutzt. In meinen Tests erzeugte ein fehlendes CA-Zertifikat allerdings entsprechende Meldungen im Log.

IPsec-Tunnel einrichten

Telco-Tech setzt für die Implementierung von IPsec auf Openswan. Um VPN mit der LiSS nutzen zu können, müssen Sie unter VPN :: Einstellungen den VPN-Dienst aktivieren.

Da das strongSwan-Gateway in diesem Beispiel hinter einem NAT-Router liegt, wird NAT-Traversal benötigt. Gehen Sie auf VPN :: Überblick und erstellen Sie eine neue VPN-Verbindung.

Tragen Sie den DNS-Namen des strongSwan-Gateways ein. Für den Aufbau des Tunnels nutzen wir IKE im Main Mode.

Das Default-Profil der LiSS harmoniert mit strongSwan. Um die Verschlüsselung oder den Hash-Algorithmus gezielt festzulegen, können Sie ein eigenes Profil erstellen. Die LiSS soll den Tunnel aufbauen und auch eigehende Verbindungen akzeptieren.

Tragen Sie die beiden durch den VPN-Tunnel zu verbindenden IP-Netzwerke ein.

Wählen Sie das Zertifikat für LiSS und die Gegenstelle aus.

Damit ist der VPN-Tunnel fertig konfiguriert.

VPN mit strongSwan einrichten

Die Konfiguration der IPsec-Verbindung erfolgt über die Datei ipsec.conf. Dort wird der IKE-Daemon pluto für IKE Version 1 eingerichtet.

ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

ca strongswan
        cacert=cacert.pem
        crluri=/etc/ipsec.d/crls/

config setup
        plutodebug=all
        charonstart=no

conn %default
        ikelifetime=60m
        keylife=60m
        rekeymargin=3m
        keyingtries=1

conn net-net
        left=%defaultroute
        leftid="C=DE, ST=Berlin, O=nwlab, OU=lab, CN=vpn.nwlab.net"
        leftsubnet=10.0.0.0/8
        leftcert=servercert.pem
        leftfirewall=yes
        right=liss.nwlab.net
        rightsubnet=192.168.1.0/24
        rightcert=liss.pem
        rightid="C=DE, ST=Berlin, O=nwlab, OU=lab, CN=LiSS"
        auto=add

Für unser Beispiel benötigen wir kein IKEv2, daher wird charon nicht gestartet. Die rightid muss den Angaben des Zertifikates der LiSS entsprechen.

VPN-Tunnel aufbauen

strongSwan wird mit ipsec start gestartet werden. Den Aufbau des Tunnels übernimmt das Kommando ipsec up.

strongswan:~# ipsec up net-net
002 "net-net" #16: initiating Main Mode
104 "net-net" #16: STATE_MAIN_I1: initiate
003 "net-net" #16: ignoring Vendor ID payload [4f454b427a64597b774d5d40]
003 "net-net" #16: received Vendor ID payload [Dead Peer Detection]
106 "net-net" #16: STATE_MAIN_I2: sent MI2, expecting MR2
002 "net-net" #16: we have a cert and are sending it upon request
108 "net-net" #16: STATE_MAIN_I3: sent MI3, expecting MR3
002 "net-net" #16: Peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, O=nwlab, OU=lab, CN=LiSS'
002 "net-net" #16: ISAKMP SA established
004 "net-net" #16: STATE_MAIN_I4: ISAKMP SA established
002 "net-net" #17: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#16}
112 "net-net" #17: STATE_QUICK_I1: initiate
002 "net-net" #17: sent QI2, IPsec SA established {ESP=>0x2799381f <0xb84d23bc}
004 "net-net" #17: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2799381f <0xb84d23bc}

Die LiSS versucht ebenfalls den Tunnel zu aktivieren.

Fehlersuche

Bei Problemen mit dem VPN-Tunnel lohnt sich ein Blick in die Logs der beiden Router.

IPSec VPN Log der LiSS

Hier ein erfolgreicher Aufbau des Tunnels im Main Mode:

pluto[1332]: packet from 77.23.xxx.xxx:500: received Vendor ID payload [XAUTH]
pluto[1332]: packet from 77.23.xxx.xxx:500: received Vendor ID payload [Dead Peer Detection]
pluto[1332]: "strongSwan-a_1" #940: responding to Main Mode
pluto[1332]: "strongSwan-a_1" #940: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
pluto[1332]: "strongSwan-a_1" #940: STATE_MAIN_R1: sent MR1, expecting MI2
pluto[1332]: "strongSwan-a_1" #940: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
pluto[1332]: "strongSwan-a_1" #940: STATE_MAIN_R2: sent MR2, expecting MI3
pluto[1332]: "strongSwan-a_1" #940: Main mode peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, O=nwlab, OU=lab, CN=vpn.nwlab.net'
pluto[1332]: "strongSwan-a_1" #940: no crl from issuer "C=DE, ST=Berlin, L=home, O=nwlab, OU=lab, CN=vpnca, E=ca@nwlab.example.net" found (strict=no)
pluto[1332]: "strongSwan-a_1" #940: I am sending my cert
pluto[1332]: "strongSwan-a_1" #940: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
pluto[1332]: "strongSwan-a_1" #940: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
pluto[1332]: "strongSwan-a_1" #940: Dead Peer Detection (RFC 3706): enabled
pluto[1332]: "strongSwan-a_1" #941: responding to Quick Mode {msgid:8fd083fc}
pluto[1332]: "strongSwan-a_1" #941: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
pluto[1332]: "strongSwan-a_1" #941: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
pluto[1332]: "strongSwan-a_1" #941: Dead Peer Detection (RFC 3706): enabled
pluto[1332]: "strongSwan-a_1" #941: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
pluto[1332]: "strongSwan-a_1" #941: STATE_QUICK_R2: IPsec SA established {ESP/NAT=>0xb84d23bc <0x2799381f xfrm=AES_128-HMAC_SHA1 NATD=none DPD=enabled}

Auf der LiSS kann man unter VPN :: Fehlersuche den Detailgehalt der Meldungen steuern.

Log von strongSwan

vpn:~# ipsec up net-net
002 "net-net" #16: initiating Main Mode
104 "net-net" #16: STATE_MAIN_I1: initiate
003 "net-net" #16: ignoring Vendor ID payload [4f454b427a64597b774d5d40]
003 "net-net" #16: received Vendor ID payload [Dead Peer Detection]
106 "net-net" #16: STATE_MAIN_I2: sent MI2, expecting MR2
002 "net-net" #16: we have a cert and are sending it upon request
108 "net-net" #16: STATE_MAIN_I3: sent MI3, expecting MR3
002 "net-net" #16: Peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, O=nwlab, OU=lab, CN=LiSS'
002 "net-net" #16: ISAKMP SA established
004 "net-net" #16: STATE_MAIN_I4: ISAKMP SA established
002 "net-net" #17: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#16}
112 "net-net" #17: STATE_QUICK_I1: initiate
002 "net-net" #17: sent QI2, IPsec SA established {ESP=gt;0x2799381f <0xb84d23bc}
004 "net-net" #17: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=gt;0x2799381f <0xb84d23bc}

Häufigste Ursache für Probleme beim Aufbau einer IPSec-Verbindung sind Tippfehler in den IP-Adressen, Netzmasken und Proposals. Viele VPN-Gateways erlauben das Logging auf einen Syslog-Server wie den Kiwi Syslog Server. Auf einem Syslog-Server lassen sich die Meldungen mehrerer Geräte zusammenführen und so leichter auswerten.

Weiterführende Informationen zu VPN

Bei Fragen zu VPN wird Ihnen im Netzwerkforum geholfen.

• VPN Know How (mit vielen weiteren Anleitungen)
• VPN Fehlersuche