Wenn die CPE mit einer ASA ...
VPNs dienen der geschützten Kommunikation, entsprechend einfach sollte ihre Einrichtung sein. Unglücklicherweise ist aber schon die Festlegung, was genau schützenswert ist, Ergebnis einer komplexen Abstimmung. Deswegen werden zunehmend VPNs global aufgemacht und nur bei Bedarf genutzt. Ein striktes Gerät, wie die ASA, mag das gar nicht. Ein Endkundengerät lieb es …
IPSec klassisch
Der klassische Ansatz ist es, für jedes Paar von geschützten Netzen einen Tunnel anzulegen, der je nach Bedarf aufgebaut und abgebaut werden kann. Diese Tunnel nennt man Security Association, sie definieren sich über die IP-Adressen der beteiligten Netze.
Durch die dynamischen Tunnel muss jedes beteiligte Gerät wissen, welche Paare von Netzen zu schützen sind und notfalls einen Tunnelaufbau initiieren. Es ist unzulässig, Pakete unverschlüsselt zu übertragen, wenn die Policy Verschlüsselung vorschreibt.
Man kann eine solche Policy also auch so verstehen, das es eine ACL gibt, die festlegt, welcher Datenverkehr verschlüsselt ist oder nicht. Konsequenterweise enthalten die Tunnel dann auch Protokoll und Portnummern, wenn nicht rein auf IP Ebene selektiert wird.
Umgekehrt wird die Policy-ACL auch bei eingehendem Verkehr angewendet. Was laut Policy verschlüsselt zu sein hat, muss verschlüsselt ankommen. Pakete, die am VPN vorbei eintrudeln, werden kommentarlos verworfen.
Das offenkundige Problem mit dem Ansatz ist der Koordinierungsaufwand:
- Beide Seiten müssen sich über die exakten Policy-ACLs klar sein.
- Änderungen sind nur beidseitig und gleichzeitig möglich.
IPSec simplified
Die offenkundige Verbesserung besteht darin, dem Tunnel nicht mehr mit den IP-Adressen zu verknüpfen. Stattdessen wird ein generischer Tunnel aufgebaut, der beliebige Datenpakete verschlüsselt transportieren kann.
Jede Seite legt für sich fest, welche Ziele durch den Tunnel und welche unverschlüsselt übertragen werden sollen.
Da man die Entwicklung eines neuen Protokolls scheute, wird ein klassischer IPSec Tunnel genutzt, der jedoch maximal breit arbeitet: Beliebige Quell- und Ziel-Adressen passen in den Tunnel.
Selbstverständlich kann man nun nicht mehr mit (Policy-)ACLs arbeiten, denn dann müsste sämtlicher Datenverkehr zwangsweise in den Tunnel geschoben werden. Stattdessen verzichtet man komplett auf die ACLs und routet die Ziel-Adressen entweder in den Tunnel oder ins Internet.
Auf diese Weise können Tunnel nach Bedarf auf jeder Seite einzeln konfiguriert werden: Es gibt einen existenten Tunnel und da wirft man rein, was wichtig scheint. Die Gegenseite muss nicht mehr informiert werden.
Eine Konsequenz aus dem Verzicht auf die ACLs, ja auf den Verzicht auf Abstimmung, ist, dass das empfangende Gerät nicht mehr feststellen kann, ob das ankommende Paket verschlüsselt hätte sein sollen oder nicht. Bei Fehlkonfigurationen kann ein Teil des Traffics unverschlüsselt laufen.
Die Vorteile liegen auf der Hand:
- Einfaches Setup (nur Gegenstelle und Schlüssel notwendig)
- Verschlüsselung nach Bedarf (des Senders) beliebig erweiterbar
- Bei Fehlkonfiguration bleibt die Funktion bestehen, nur die Sicherheit ist weg.
Mischbetrieb
Der vereinfachte Ansatz ist gerade im Endkundenbereich beliebt, weil sich der Kunde so schnell seine Lan-Kopplung zusammen klicken kann. Der striktere Ansatz ist eher im Firmenumfeld zu finden, wo man traditionell nur mit abgestimmten Konfigurationen zu tun hat.
In meinem Fall habe ich nun ein Endkundengerät (CPE), das ausschließlich nach der vereinfachten Methode arbeitet, und eine ASA, die ausschließlich nach der traditionellen Methode konfiguriert werden will.
Aufgrund der Policy-ACL würde eine ASA keinen unverschlüsselten Traffic annehmen, wenn der durch den Tunnel kommen müsste. Das will ich nicht aufgeben.
An der CPE sind die Wechselmöglichkeiten zu beschränkt, um überhaupt einen anderen Typ von Verbindung hinzubekommen. Also konzentriere ich mich auf das eigentliche Problem: Den VPN Tunnel und die dazu passende Policy-ACL.
Da die CPE den Tunnel vorgibt, muss er offensichtlich ein 0.0.0.0/0.0.0.0 Tunnel werden. Das führt zur sofortigen Funktionsunfähigkeit der ASA.
Schaut man genauer auf die ACLs, so stellt man fest, dass diese mehrfach benutzt werden:
- Jedes Paket, dass von der ACL erlaubt wird, kommt in den Tunnel oder muss daraus kommen.
- Jedes Paket, dass von der ACL abgelehnt wird, darf nicht in den Tunnel oder daraus kommen.
- Die Tunnel-Konfiguration ergibt sich aus den Permit-Regeln der ACL.
Der Trick besteht also darin, allen Traffic abzulehnen, der nicht in den Tunnel soll, um anschließend alles zuzulassen.
access-list vpn deny ip object-group og-not-local any access-list vpn deny ip any object-group og-not-remote access-list vpn permit ip any any
Die Objektgruppen, die den Kehrwert der eigentlich zulässigen Netze bilden, sind am einfachsten aus zwei Bereichen zu bauen, die bis an das gewünschte Netz ran gehen.
object-group network og-not-local network-object object o-not-local-higher network-object object o-not-local-lower object network o-not-local-lower range 0.0.0.0 198.51.99.255 object network o-not-local-higher range 198.51.101.0 255.255.255.255
In gleicher Weise werden die inversen Bereiche für das Remote-Netz definiert.
Es kann nun noch vorkommen, dass die ASA sich zickig hat beim annehmen des Verbindungsaufbaus. Dann genügt es die Basisadressen der Netze zu erlauben.
access-list vpn line 1 perm ip host 0.0.0.0 host 0.0.0.0
Tut.