Erfahrungen mit IPSec

Geschrieben von Beat Rubischon am Freitag, 25. November 2005, 21:03 aus dem when-rfcs-becomes-a-joke dept. In den letzten Wochen hatte ich in mehreren Fällen mit IPSec zu tun. Ich versuche einmal meine Erfahrungen zusammenzutragen - vielleicht hilft mir der Wust an Informationen einmal selbst, vielleicht hilft es jemandem anderen. Erst einmal zur Frage, was IPSec denn überhaupt ist: Die Vorstellung darüber hat sich mit der Zeit gewandelt. Während initial die Idee bestand, einfach die Verbindung zwischen zwei Computern zu schützen (der sogenannte Trasport Mode), ist daraus ein echtes VPN für die Verbindung zwischen Netzen oder einem Netz und einem mobilen Computer geworden (der sogenannte Tunnel Mode oder L2TP/IPSec). Da die Standards sich langsamer entwickelten als die Implementationen folgten, haben wir verschiedene Vorstellungen von IPSec, welche untereinander inkompatibel sind. Nicht nur zwischen Herstellern, sondern auch zwischen verschiedenen Produktelinien desselben Herstellers können unüberwindbare Probleme entstehen. IPSec wurde für eine perfekte Welt entwickelt, in der jeder Computer eine öffentliche IP hat. NAT ist für IPSec ein Problem, das erst vor kurzem seinen Einzug in die Standards gefunden hat. Das Stichwort hier lautet NAT-T - NAT Traversal. Selbstverständlich mussten die Hersteller von IPSec Stacks schon im Voraus etwas implementieren - sonst hätten sie kaum noch etwas verkaufen können - und so unterscheiden sich die einzelnen Produkte zum Teil bis zur Inkompatibilität. Ueber die Hintergründe von IPSec verweise ich gerne auf den Illustrated Guide to IPsec. An der ETH ist VPN schon seit einer längeren Zeit ein Thema. Die Informatikdienste betreiben einen (oder mehrere?) Cisco 3000 VPN Konzentratoren und geben dazu kostenlos den passenden Cisco VPN Client für Windows, MacOS X und Linux ab. Besonders beliebt ist das Ding nicht - aber man hat mit VPNC wenigstens einen Weg, unter Linux mit einem OpenSource Produkt eine Verbindung hinzubekommen. Etwas Dokumentation meinerseits brachte manchem Studi Erleichterung. Mein erster Kontakt mit IPSec auf der Serverseite war vor etwa eineinviertel Jahren. Ich setzte einen L2TP/IPSec Server unter Linux auf. Verbindungen mit WinXP und Win98 mit dem dazugehörenden Client verliefen problemlos. Ist ja ganz einfach dachte ich ganz naiv. Dann kam mir die Idee, meinen Cisco zu einem L2TP/IPSec Server zu konfigurieren - allerdings ohne Erfolg. Einerseits bricht das IOS jegliche Verbindungsversuche ab, die AES verlangen (der Cryptochip auf dem Board des 836ers kann nur 3DES), andererseits ist es nicht möglich, shared Secrets für Wildcard Adressen anzugeben. Der nächste Anlauf war die Verbindung eines OpenSWAN Servers mit meinem Cisco 836. Das hat geklappt und nach viel Debugging sind gar beide Seiten in der Lage, die Verbindung zu initiiren. Ein kürzliches Upgrade von OpenSWAN brachte erneut Aerger und ich musste auf der OpenSWAN Seite die zu verwendenden Algorithmen fix angeben: /etc/ipsec.conf conn NULLXIB         authby=secret         left=129.132.80.2         leftsubnet=129.132.86.192/27         right=212.25.16.173         rightsubnet=212.25.17.160/28         esp=3des-md5,3des-sha1         keylife=24h         auto=start /etc/ipsec.secrets 129.132.80.2 212.25.16.173: PSK "XXXXXXXXXXXXXX" Die Konfiguration auf der IOS-Seite sieht wie folgt aus: ! crypto isakmp policy 10  encr 3des  hash md5  authentication pre-share  group 5 ! crypto isakmp key 6 YYYYYYYYYYYYYYYY address 129.132.80.2 ! crypto isakmp keepalive 3600 ! crypto ipsec transform-set ts1 esp-3des esp-md5-hmac ! crypto map phys 10 ipsec-isakmp  description VPN 0x1b.ch - phys.ethz.ch  set peer 129.132.80.2  set transform-set ts1  set pfs group5  match address phys ! ip access-list extended phys  remark VPN 0x1b.ch - phys.ethz.ch  permit ip 212.25.17.160 0.0.0.15 129.132.86.192 0.0.0.31 ! interface Dialer1  ...  crypto map phys Gruselig ;-) (Für die Netzmaskenberechnungen habe ich mir einen Spick gemacht.) Dann kam der nächste Härtefall. Ein Admin in einer Professur stellte ein paar wichtige Maschinen hinter einen ZyXEL ZyWALL und wollte von "draussen" her darauf verbinden. Mit ein paar Zeichnungen half ich ihm - ohne genau zu wissen, wie man eine ZyWALL überhaupt konfiguriert. Nach etwas Biegen und Würgen funktionierte dies auch. Dann kamen aber die Benutzer und stellten die interessante Frage: Kann ich sowohl das ETH-VPN als auch die Verbindung zur ZyWALL offen haben? Da beide Clients dieselben Ports und Protokolle benutzen, bleibt dem User nichts anderes übrig als den einen Client komplett zu stoppen und den anderen zu starten - unter WinXP eine Arbeit, die nur der Admin im Serivcepanel machen kann. Ich leitete die Anfrage letztendlich gar in die LUGS Mailingliste weiter und bekam einen Tipp: TheGreenBow. Gestern nutze ich etwas tote Zeit und versuchte den Client - etwas vom Besten, was mir bisher unter Windows begegnet ist. Aber eine Verbindung zu einem Cisco 3000? Fehlanzeige. Viel Googeln später war ich etwas schlauer: Cisco hat beim 3000er einen genialen Wurf gemacht. Ein simples Webgui konfiguriert den Konzentrator und erstellt gleichzeitig die Konfigfiles für die Clients. Die ideale "Lösung" für Leute, die sich nicht mit der Technik beschäftigen wollen. Handkehrum ist das Teil an den Standards vorbeiprogrammiert, benutzt eigene Erweiterungen zu IPSec und hat letztendlich sogar Protokollfehler wie falsche Paketlängen und ähnlichem. Es ist daher schlicht nicht möglich, mit derselben Software sowohl eine "normale" IPSec Verbindung zu fahren als auch eine Verbindung zu einem 3000er zu haben. Umgekehrt kann der Cisco-Client auch nicht dazu verwendet werden, zu einem anderen VPN-Server Verbindung aufzunehmen. Die OpenSWAN-Leute haben eine Zeit lang Protokollanalysen gemacht, aber noch in der Phase 1 aufgegeben. Eine ganz andere Baustelle: Um eine Alternative zum offiziellen VPN zu haben, entwarf ich ein eigenes, basierend auf L2TP/IPSec. Die Tatsache, dass man dafür keinen separaten Client erwerben muss, sondern den integrierten im OS (Windows und MacOS X) benutzen kann, macht den Mehraufwand Linux-Seitig durchaus wett. Jacco's Anleitung ist brauchbar und gibt einen Server, der prima funktioniert - für Windows. MacOS X macht Aerger. Warum eigentlich? Nun, Apple hat beim NAT-T einen mittlerweile nicht mehr eingesetzten Standardentwurf verwendet. Mehr noch, sie haben bei der Aushandelung, ob eine Verbindung genatet ist oder nicht, zwei Hashes vertauscht. Die OpenSWAN Leute haben mittlerweile einen Teil reverse engeneered - sie erkennen MacOS X. Aber funktionieren tut's nicht, weder mit noch ohne NAT. Folgender Diff entfernt in der aktuellen Version von OpenSWAN die MacOS X relevanten Modifikationen, so kann ein Mac wenigstens von einer public IP her verbinden. --- openswan-2.4.3/programs/pluto/vendor.c.orig 2005-11-17 17:25:17.000000000 +0100 +++ openswan-2.4.3/programs/pluto/vendor.c 2005-11-17 17:25:17.000000000 +0100 @@ -411,7 +411,8 @@         case VID_NATT_IETF_02:         case VID_NATT_IETF_02_N:         case VID_NATT_IETF_03: -       case VID_NATT_DRAFT_IETF_IPSEC_NAT_T_IKE: +           /* Does not work */ +           /* case VID_NATT_DRAFT_IETF_IPSEC_NAT_T_IKE: */         case VID_NATT_RFC:         vid_usefull = 1;              if(!nat_traversal_support_port_floating) { Laut Mailingliste soll der CVS Checkout vom letzten Juni funktioniert haben. Aktuell tut es nicht mehr. Wurde hier etwas in OpenSWAN kaputtoptimiert? Fassen wir kurz zusammen: IPSec wäre ein einfacher, sicherer Standard. Jeder Hersteller stellt sich etwas anderes darunter vor. Microsoft hat mit L2TP/IPSec etwas geschaffen, das unheimlich komplex ist, aber an und für sich tut. Cisco hat mit dem 3000er VPN Konzentrator ein Gerät geschaffen, das mit nichts anderem als dem Cisco VPN Client kompatibel ist. Apple hat im MacOS X einen Bug, der alle Verbindungen zu VPN Servern ausser dem MacOS X Server verhindert. Wenn wir auf alle VPN-Konzentratoren zugreifen wollen, die es gibt, brauchen wir 3 Clients: Einen nativen IPSec Stack Einen L2TP/IPSec Client Den Cisco VPN Client Je nach System sind das drei separate Softwareprodukte bzw. die Kombination von verschiedensten Softwarebausteinen. Viele kosten Geld und keiner ist perfekt. Es darf nur einer gleichzeitig aktiv sein. Mittlerweile verstehe ich, warum es Cipe, VTun und OpenVPN gibt und diese derart erfolgreich sind... Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.