Cisco IOS: Interface-ACLs für VPNs

Jeder Router, der mit dem Internet verbunden ist, sollte mit einer eingehenden Access-Liste (ACL) auf dem externen Interface konfiguriert sein, der den Zugriff auf den Router einschränkt. In diesem Beitrag zeige ich, wie so eine ACL aussehen kann.

Anmerkung1: Die gezeigte Konfig gilt nur für IOS-Versionen 12.4+. Bei älteren IOS-Releases ist etwas mehr Konfiguration notwendig.
Anmerkung2: Dies gilt nicht für die ASA da dort so eine ACL nicht benötigt wird. Auf der ASA filtert die Interface-ACL standardmäßig nur den durch die ASA durchgehenden Traffic, aber nicht den Traffic, der zur ASA selbst gesendet wird.

Die folgenden Beispiele basieren auf der folgenden Topologie:
VPN-Interface-ACLs

Voraussetzungen:
Der Router sollte mit einer Stateful-Firewall-Konfig versehen sein, die Antwort-Pakete auf selbst generierten Traffic ohne ACEs erlaubt. Das ist Bestandteil der Baseline-Security und vereinfacht die Konfiguration. In diesen Beispiel wird das ältere CBAC verwendet, da es deutlich einfacher zu verstehen und implementieren ist, als die leistungsfähigere Zone-Based-Firewall:

ip inspect name FW ftp
ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
!
interface GigabitEthernet0/0
  ip access-group SITE-A-INTERNET-IN in
  ip inspect FW out
!
ip access-list extended SITE-A-INTERNET-IN
  deny ip any any

Basierend auf dieser Konfiguration wird die ACL mit den benötigten ACEs ergänzt.

Scenario 1: Site-to-Site VPNs mit statischen VPN-Peers
Bei diesem einfachen Beispiel wird angenommen, dass alle Peers eine statische public IP haben, die zwischen den beiden Gateways nicht genatted werden. Der in der ACL benötigte Traffic ist IP-Protocol 50 (ESP) und UDP/500 (ISAKMP). Viele Beispiele im Internet haben auch ACEs für IP/51 (AH), dies wird aber normalerweise nicht für VPNs verwendet.

Als erstes wird eine Object-Group für alle VPN-Peers erstellt (Object-Groups benötigen mindestens IOS 12.4(20)T+):

object-group network IPSEC-PEERS
  host 198.51.100.1
  host 203.0.113.1

Dann wird in der ACL der ESP- und ISAKMP-Traffic von den VPN-Peers zum Router-Interface erlaubt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die letzte Zeile ist für die VPN-Funktionalität natürlich nicht nötig, erleichtert aber das Troubleshooting.

Scenario 2: VPN-Peers hinter einem NAT-device mit statischen IPs
Wenn ein oder beide IPsec-Peers sich hinter einem NAT-Device befinden, dann verwendet IPsec NAT-Traversal, das auch mit UDP/500 anfängt, aber dann auf UDP/4500 wechselt.

Dafür werden die folgenden Einträge benötigt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp non500-isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die Einträge in der Object-Group sind weiterhin die public IPs der Router, nicht die realen IP-Adressen der Router.
Wenn alle Router hinter einem NAT-Device sind, dann wird der ACL-Eintrag für ESP (IP/50) nicht benötigt, da dann der gesamte User-Traffic über UDP/4500 gesendet wird.

Scenario 3: IPsec-Peers mit dynamischer IP-Adresse
Dies ist das typische Remote-Access-Scenario, oder aber auch verwendet, wenn z.B. Branchoffices mit günstigen Kabel- oder DSL-Anschlüssen betrieben werden, für die keine festen IPs verfügbar sind. Daraus resultiert die folgende ACL:

ip access-list extended SITE-A-INTERNET-IN
  permit esp any host 192.0.2.1
  permit udp any host 192.0.2.1 eq isakmp non500-isakmp
  ! generally allow ping from the internet if your security-policy allows that:
  permit icmp any host 192.0.2.1 echo

In diesem Scenario wird die Object-Group mit den IPsec-Peers nicht benötigt, da deren IP im Vorwege sowieso nicht bekannt sind.

Viel Spaß beim Absichern der VPNs!

Advertisements
Cisco IOS: Interface-ACLs für VPNs

Cisco ASA VPNs: Spoke-to-Spoke Traffic via Hub

In dem Cisco Support-Forum kommt regelmäßig die Frage, wie man per VPN Spoke-zu-Spoke Kommunikation über den Hub leiten kann.
Diese Konfiguration wird hier gezeigt. Vorweg aber der Hinweis, dass bei Vorhaben wie diesen, IOS-Router oftmals die bessere Wahl sind, da sie dabei um ein vielfaches flexibler sind als die ASA.

Die Konfiguration wird anhand des folgenden Aufbaus für die ASA-Version 8.4+ gezeigt. Es beginnt mit der Hub-to-Spoke-Konfiguration, die dann später mit einer Spoke-to-Spoke-Kommunikation erweitert wird:

ASA-Hub-and-Spoke

Auf allen ASAs werden Phase1- und Phase2-Policies für IPSec benötigt. Diese sind natürlich nach dem eigenen Bedürfnis zu wählen:

crypto ikev1 policy 1
 authentication pre-share
 encryption aes 256
 hash sha
 group 5
 lifetime 86400
!
crypto ikev1 enable outside
!
crypto ipsec ikev1 transform-set ESP-AES256-SHA esp-aes-256 esp-sha-hmac

Auf allen ASAs werden die benötigten Object-Groups, ACLs, Crypto-Maps und Tunnel-Groups angelegt. Zusätzlich wird der Traffic vom NAT ausgenommen:

Spoke1:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE1-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE1-NETWORKS SPOKE1-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Spoke2:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE2-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE2-NETWORKS SPOKE2-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Hub:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
 group-object SPOKE2-NETWORKS
!
access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group HQ-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group HQ-NETWORKS object-group SPOKE2-NETWORKS
!
crypto map VPN 1 match address VPN-HQ-TO-SPOKE1
crypto map VPN 1 set peer 203.0.113.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN 2 match address VPN-HQ-TO-SPOKE2
crypto map VPN 2 set peer 198.51.100.1
crypto map VPN 2 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
tunnel-group 198.51.100.1 type ipsec-l2l
tunnel-group 198.51.100.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough

nat (any,outside) source static HQ-NETWORKS HQ-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Mit der gegebenen Konfiguration kann zwischen Spoke1 und dem Hub, als auch zwischen Spoke2 und dem Hub per VPN kommuniziert werden.

Jetzt wird die VPN-Konfig um Spoke-to-Spoke-Kommunikation erweitert. Dabei soll jeder Spoke den Traffic für die anderen Spokes durch den schon bestehenden Tunnel zum Hub senden. Der Hub sendet den Traffic dann zum jeweiligen Spoke weiter.

Spoke1:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE2-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Spoke2:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS

Die Crypto-ACLs haben jetzt permit-statements für die Kommunikation zum Hub, als auch zum anderen Spoke. Weiterhin wird auch der Spoke-to-Spoke-Traffic nicht genatted da die Spoke-Ziele der NAT-Exemption-Object-Group hinzugefügt wurden. Die Crypto-ACLs könnte man durch eine weitere Object-Group für die VPN-Ziele natürlich noch eleganter konfigurieren.

Hub:
Auf der Hub-ASA müssen zwei Änderungen vorgenommen werden.
Als erstes werden die Crypto-ACL so erweitert, dass die Crypto-ACL zum Spoke 1 auch den Traffic von Spoke2 beinhaltet und die Crypto-ACL zum Spoke2 auch den Traffic vom Spoke1 beinhaltet.

access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Als letzten Schritt wird die ASA so konfiguriert, dass Hairpinning erlaubt wird, also Traffic auf dem selben Interface die ASA verlassen kann, über das der Traffic empfangen wurde.

same-security-traffic permit intra-interface
Cisco ASA VPNs: Spoke-to-Spoke Traffic via Hub

Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard – Teil 2

In etlichen Mac-Online-Publikationen (u.a. maclife, Macbug) kann man lesen, dass der eingebaute VPN-Client nur IPSec over TCP, aber kein IPSec over UDP unterstützt.
Das ist in dieser Form aber falsch. Im Moment bin ich hinter einem NAT-Gateway und connecte mich mit dem SL-Client auf einen IOS-Router (12.4(15)T9) als IPSec-Gateway (die 89.246.26.242 ist dabei meine DSL-IP):

c2811>sh crypto session remote 89.246.26.242
Crypto session current status

Interface: Virtual-Access2
Username: karsten.iwen
Profile: vpn-ra
Group: VPN-RA
Assigned address: 10.10.10.1
Session status: UP-ACTIVE
Peer: 89.246.26.242 port 4500
  IKE SA: local a.b.c.d/4500 remote 89.246.26.242/4500 Active
  IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 host 10.10.10.1
        Active SAs: 2, origin: crypto map 

Deutlich ist zu erkennen, dass hier das standardkonforme IPSec over UDP (NAT-Traversal) verwendet wird. Ob das Cisco-proprietäre IPSec over UDP unterstützt wird kann ich nicht sagen. Aber wer das einsetzt lebt vermutlich sowieso noch im Jahr 1999 und glaubt immer noch, dass sich ATM nächstes Jahr durchsetzt … 😉

Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard – Teil 2

Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard

Das Update auf Mac OS X Snow Leopard wurde heute geliefert und die Installation war nach entspannten 45 Minuten ohne weitere Benutzereingriffe erledigt.
Auf den ersten Blick gab es eigentlich keine sichtbaren Änderungen, aber das war auch das was ich erwartet habe.
Mein erster Test galt dem eingebauten VPN-Client, der unter 10.6 neben dem schon vorher unterstützten PPTP und L2TPoverIPSec nun auch nativ das Cisco IPSec-VPN unterstützt. Das ist vor allem deshalb interessant, da Cisco den IPSec-Client nicht weiterentwickelt und deren Präferenz der AnyConnect-Client ist, der z.Zt. aber nur SSL-VPNs unterstützt.

Die Konfiguration ist recht einfach:

In den Netzwerk-Eigenschaften eine neue Verbindung anlegen Cisco VPN auswählen, VPN-Server-Adresse, Username konfigurieren und unter den Identifizierungseinstellungen die Gruppe mit PSK bzw. das Zertifikat konfigurieren:
CiscoVPN1
CiscoVPN2

Nachdem man das VPN verbunden hat bekommt man in der Menüleiste auf Wunsch ein Icon eingeblendet:
CiscoVPN3

Ein paar Einschränkungen gegenüber dem Cisco VPN-Client sind mir aber aufgefallen:

  • Es gibt keine Möglichkeit Backup-Server einzutragen.
  • Auch mehrere Adressen im Feld “Serveradresse” gehen nicht.

  • Keine eingebauten Statistiken
  • Keine Mutual Group-Authentication
  • Wenn die VPN-Gegenstelle eine Cisco ASA ist, dann ist diese Authentifizierung eine recht einfache Methode, um Man-in-the-Middle-feste VPNs hinzubekommen, was mit PSKs und digitalen Zertifikaten alleine etwas aufwendiger ist. Diese Einschränkung ist IMHO die wichtigste, die gegen den eingebauten Client spricht. Zumindest meine bevorzugte VPN-Art ist immer noch IPSec gegen die ASA wenn es um Remote-Access geht.

Glücklicherweise läuft der original Cisco-VPN-Client auch noch unter Snow Leopard, so dass man noch nicht auf den eingebauten Client wechseln muss.

Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard

Generieren von Crypto-Keys

routerEin Artikel in Cisco IOS Hints and Tricks beschreibt einen Fehler, den vermutlich viele Leute schon begangen haben (ja, ich natürlich auch): Bei Problemen mit der SSH-Verbindung wurde zu schnell ein “crypto key generate rsa” eingegeben, um neue RSA-Keys zu erzeugen. Leider hat man vergessen, daran zu denken, daß die zertifikatbasierten VPNs von den Schlüsseln abhängen.

Glücklicherweise kennt das IOS seit Version 12.2(8)T die Möglichkeit, jedem Key-Paar ein Label mitzugeben und diese damit für verschiedene Einsatzzwecke zu unterscheiden.
Dabei wird der Befehl crypto key generate rsa mit dem Parameter label versehen:

crypto key generate rsa modulus 2048 label MYLABEL

Dieses Key-Paar kann dann in einem PKI-Trustpoint benutzt werden:

crypto pki trustpoint MYCA
 enrollment ...
 rsakeypair MYLABEL

Wenn später ein unvorsichtiges “crypto key generate” eingegeben wird, kann das den für die VPN-Zertifikate verwendeten Keys nichts anhaben.

Ein weiterer Vorteil ist, daß beim nächsten Wechsel der Zertifikate auch die Keys neu generiert werden können, ohne daß sich der SSH-Fingerprint ändert.

Update: Mit ISRs hat das bisher immer gut funktioniert. Heute ging die Methode mit 1700er Routern und einem 12.4(15)T8 allerdings schief. Also aufpassen!

Generieren von Crypto-Keys