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:

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!