IPsec mit OpenSwan
In diesem Artikel wird beschrieben, wie eine VPN Infrastruktur mit OpenSwan aufgebaut werden kann. Im Teil 1 wird erstmal nur beschrieben, wie der Trivialfall aussieht, in den weiteren Teilen werden dann beschrieben, wie man GRE Tunnel über IPsec aufbaut und wie auch Windows XP Clients mit Bordmitteln so konfiguriert werden können, dass sie mit einem OpenSwan VPN Gateway Kontakt aufnehmen können.
ipsec.conf
Die globale Konfiguration sieht in einem Produktionssystem wie folgt aus:
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
uniqueids=no
interfaces="ipsec0=eth0 %defaultroute"
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
# plutodebug="control parsing"
plutodebug=none
Debug sollte im Produktivbetrieb immer aus sein, sonst wird OpenSwan sehr langsam und /var/log sehr schnell voll.
In dem folgenden Beispiel eine IPsec Verbindung mit preshared Secret konfiguriert:
conn PreSharedSecret
type=tunnel
keyingtries=0
authby=secret
# Soll die Verbindung automatisch starten, dann statt "add" einfach "start" setzen
auto=add
# Left security gateway, subnet behind it, next hop toward right.
leftid=192.168.0.1
left=192.168.0.1
leftsubnet=10.0.0.0/24
leftnexthop=%defaultroute
# Right security gateway, subnet behind it, next hop toward left.
rightid=192.168.1.1
right=192.168.1.1
rightsubnet=10.0.1.0/24
esp=aes-md5
ike=aes-md5
- Hier werden die Netze 10.0.0.0/24 und 10.0.1.0/24 über IPsec miteinander verbunden.
- Die IPsec Gateways haben dabei die Interface IP Adressen 192.168.0.1 und 192.168.1.1 auf der anderen Seite.
- Die Verschlüsselung erfolgt mit aes und die Hashwerte werden mit md5 gebildet. Als Hashverfahren sollte md5 nicht mehr verwendet werden, da hier inzwischen Schwachstellen bewiesen wurden.
- Es wird ein preshared Secret (also ein Passwort) zur Authentifizierung verwendet. Dieses ist für diese Verbindung in der Datei ipsec.secrets festzulegen
In dem folgenden Beispiel eine IPsec Verbindung mit X.509 konfiguriert:
conn X509
type=tunnel
keyingtries=0
authby=rsasig
# Soll die Verbindung automatisch starten, dann statt "add" einfach "start" setzen
auto=add
# Left security gateway, subnet behind it, next hop toward right.
leftid=192.168.0.1
left=192.168.0.1
leftid="/C=de/ST=Hessen/O=pug.org/OU=tux/CN=BigBoss/emailAddress=bigboss@example.com"
leftsubnet=10.0.0.0/24
leftnexthop=%defaultroute
# Right security gateway, subnet behind it, next hop toward left.
rightid=192.168.1.1
right=192.168.1.1
rightid="C=*, ST=*, O=pug.org, OU=*, CN=*, E=*"
rightsubnet=10.0.1.0/24
esp=aes-md5
ike=aes-md5
OpenSwan durchsucht beim Start die Verzeichnisse unter ipsec.d nach Zertifikaten. Unter cacerts müssen CA Zertifikate gespeichert werden. Unter certs sind Clientzertifikate zu speichern. Das o.g. VPN Gateway ist selbst auch Client. Unter private muss das zugehörige Keyfile zu dem unter leftid genannten Zertifikat liegen. In der ipsec.secrets muss das Passwort zum Keyfile gespeichert sein:
: RSA vpn-gate.pem "DasIstEinSchlechtesPasswort"
Der Eintrag unter rightid besagt, dass alle Zertifikate akzeptiert werden, die von der CA pug.org signiert wurden. Ansonsten gelten die Einstellungen aus der Konfig für preshared Keys.
Der Vorteil lieht erstmal darin, dass keine Passwörter mehr ausgetauscht werden müssen und dass man unter crls auch Revocationlisten hinterlegen kann, in der einzelne Zertifikate für ungültig erklärt werden können.
ipsec.secrets
Die Syntax ist <remote ip> <local ip>: PSK "<Passwort>" oder
- RSA <X.509 Keyfile> <Passphrase>
192.168.1.1 192.168.0.1: PSK "DasIstEinSehrSchlechtesPasswort"
Fehlt der passende Eintrag, dann ist im Logfile ein Eintrag "cannot load secret" zu finden.
Gegenstelle
Die Konfiguration der Gegenstelle sieht exakt genauso aus, nur in der ipsec.secrets sind die beiden IP-Adressen zu vertauschen.
Verbindung aktivieren
Ist die Config auf beiden Seiten nun erstellt, kann man die Verbindung starten:
vpn-gw# ipsec auto --up PreSharedSecret
104 "PreSharedSecret" #1: STATE_MAIN_I1: initiate
003 "PreSharedSecret" #1: received Vendor ID payload [Dead Peer Detection]
106 "PreSharedSecret" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "PreSharedSecret" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "PreSharedSecret" #1: STATE_MAIN_I4: ISAKMP SA established
117 "PreSharedSecret" #2: STATE_QUICK_I1: initiate
004 "PreSharedSecret" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe50538de <0xb21151a4}
Hier sieht man, dass die Verbindung korrekt aufgebaut wurde. Ein Ping von Gateway zu Gateway funktioniert nicht, also keine Panik. Am besten Ping von Client aus Netz1 zu Client in Netz2 versuchen. Das muss dan gehen. Mit tcpdump kann man sich dann davon überzeugen, dass nur ESP Pakete übertragen werden.
