ASA mit mehrfacher Default Route
Eine Appliance, die in einer fremden Umgebung Daten einsammelt, soll von extern angesprochen werden. Zum einen muss der Hersteller Fernwartung machen und zum anderen gibt es eine Gruppe von Stellen, die auf die gesammelten Daten zugreifen sollen. Völlig unerwartet wird das geschützte Netzwerk dieser Stellen ebenfalls mit öffentlichen IP Adressen betrieben, so dass für beide Zwecke eine Default Route benötigt wird. Das Ganze soll trotzdem nur mit einer ASA funktionieren. Eine Aufsplittung in mehrere Kontexte (ASA-Virtualisierung) scheitert am fehlenden Support für Remote-Access. Es muss also anders gehen.
Aufgabenstellung
Die Appliance arbeitet in einem anderen, größeren Netzwerk und benutzt selbst nur private IP Adressen (hier 192.0.2.x). Um alle Messstellen erreichen zu können, zeigt die Default Route dieses Gerätes in das fremde Netzwerk (hier grau).
Der Remote-Access Teil (hier grün) ist ein einfaches Setup. Um die vorab unbekannten Clients erreichen zu können, muss die Default Route ins Internet zeigen. Dieser Uplink der ASA benutzt öffentliche IPs (PA-space, hier 189.51.100.x). Die Remote-Access Clients bekommen aus einem Adresspool des lokalen Netzes IPs, so dass sie ohne weiteres Routing auf die Appliance zugreifen können. Von Seiten der Appliance aus erscheint der Client im LAN.
Die ursprüngliche Annahme war, dass die abfragenden Stellen, die über ein extra gesichertes Netzwerk zugeführt werden, ebenfalls in koordinierter Weise mit nicht-öffentlichen Adressen arbeiten würden. In diesem Fall hätte eine spezifische Route zu all diesen Netzen genügt. Allerdings haben die Planer dieses Netzes den Koordinationsaufwand gescheut und verlangen stattdessen, öffentliche IP-Adressen aus dem lokalen PA-Space zu benutzen, der auch normal über Internet erreichbar ist.
Die Gegenstellen hinter dem geschützten Netzwerk (hier rot) sind vorab ebenso wenig bekannt, wie die Fernwartungs-Clients (grün). In dem hier skizzierten Bild, soll eine solche Gegenstelle eine ganz andere öffentliche IP Adresse haben (hier 203.0.113.133). Um solche Adressen zu erreichen, müsste eine Default Route ins rote Netz gesetzt werden.
Angefasst werden darf nur die ASA, alle anderen Geräte unterliegen fremder Verfügungsgewalt.
Remote-Access
Die Konfiguration für das Remote-Access VPN gemäß Lehrbuch:
interface Ethernet0/0 nameif green security-level 0 ip address 198.51.100.25 255.255.255.192 ! interface Ethernet0/1 nameif gray security-level 100 ip address 192.0.2.5 255.255.255.0 ! route green 0.0.0.0 0.0.0.0 198.51.100.1 1 ! ip local pool vpnippool 192.0.2.101-192.0.2.102 mask 255.255.255.0 ! crypto map vpn_outside 999 ipsec-isakmp dynamic vpn_dyn crypto map vpn_outside interface green ...
Erwartungsgemäß tut das seinen Dienst:
- Der entfernte Supportmitarbeiter kann per Default Route erreicht werden.
- Der entfernte Supportmitarbeiter bekommt über das VPN eine IP aus dem inside-LAN.
- Die Appliance redet mit ihm über das lokale Netzwerk. Extra Routen werden nicht benötigt.
Einmal hin ...
Um die Stellen, die mit öffentlichen IP Adressen aus dem geschützten Netz kommen, versorgen zu können, sind einige Überlegungen notwendig.
Zuerst fällt auf, dass der Verbindungsaufbau bei unbekannten Gegenstellen nur von extern kommen kann. Die Clients werden ausschließlich eine öffentliche IP au dem Netz 198.51.100.248/29 zugreifen können. Von dem privaten Netz hinter der ASA wissen sie nichts.
Damit die Appliance nichts von den fremden Adressen merkt, braucht es eine Doppel-NAT:
interface Ethernet0/2 nameif red security-level 0 ip address 198.51.100.254 255.255.255.248 ! object network o-server host 192.0.2.4 ! nat (red,green) source dynamic any interface destination static interface o-server
Eingehende Pakete über das rote Interface von beliebiger Quelle an die Interface-IP werden so genanntet, dass die Quell-IP zur grünen Interface-Adresse und die Zieladresse, die der Appliance wird. Damit sieht die Appliance nur Anfragen aus ihrem LAN.
Um zu testen, dass diese Idee auch tut, wird ein Testaufbau erstellt:
Anstelle des roten Netzwerkes, steht ein Linux-Rechner, den man passend konfiguriert:
# ip addr add 198.51.100.254/29 dev eth_rot
# ip addr show eth_rot
1: eth_rot: <BROADCAST,MULTICAST,UP,10000>
inet 198.51.100.254/29 scope global eth_rot
valid_lft forever preferred_lft forever Zusätzlich bekommt er die fremde IP Adresse. Damit er diese auch als Quelladresse benutzt, gibt es eine spezielle extra Route:
# ip addr add 203.0.113.133/32 dev lo # ip route add 198.51.100.249/32 src 203.0.113.133 dev eth_rot
Wenn man testweise versucht eine Verbindung zur Appliance herzustellen, scheint es erst einmal zu tun.
# ssh 198.51.100.249 15:42:02 IP 203.0.113.133.35158 > 198.51.100.249.22: S 3034099253:3034099253(0) 15:42:03 IP 203.0.113.133.35158 > 198.51.100.249.22: S 3034099253:3034099253(0) 15:42:05 IP 203.0.113.133.35158 > 198.51.100.249.22: S 3034099253:3034099253(0)
Wie man sieht, geht die Anfrage mit der richtigen Absende-IP raus.
Allerdings kommt keine Antwort zurück. Aber warum?
... und zurück
Ein Blick auf die ASA zeigt, das die Datenpakete korrekt nattet und sogar Antworten bekommt.
16: 15:42:02 192.0.2.5.35158 > 192.0.2.4.22: S 3034099253:3034099253(0) win 14600 17: 15:42:02 192.0.2.4.22 > 192.0.2.5.35158: S 2009198346:2009198346(0) ack 3034099253 win 14480 18: 15:42:03 192.0.2.5.35158 > 192.0.2.4.22: S 3034099253:3034099253(0) win 14600 19: 15:42:03 192.0.2.4.22 > 192.0.2.5.35158: S 2009198346:2009198346(0) ack 3034099253 win 14480 20: 15:42:05 192.0.2.5.35158 > 192.0.2.4.22: S 3034099253:3034099253(0) win 14600 21: 15:42:05 192.0.2.4.22 > 192.0.2.5.35158: S 2009198346:2009198346(0) ack 3034099253 win 14480
Warum kommen die Datenpakete nicht wieder zurück? Weil die Default Route fehlt!
Glücklicherweise ist die ASA kein Router. Genauer gesagt die Routingentscheidung wird in zwei Schritten vorgenommen:
- Steht das ausgehende Interface nicht fest, so wird die generische Routingtabelle befragt, um das Interface zu ermitteln.
- Ist allerdings klar, auf welchem Bein ausgesendet werden muss, so wird nur der Teil der Routingtabelle betrachtet, der diesem Interface zugeordnet ist.
Eine der Konsequenzen aus diesem Ansatz erklärt die seltsame Anforderung, bei jeder statische konfigurierten Route immer das Interface mit angeben zu müssen: Um so eine schräge Logik umsetzen zu können, muss man erst mal die Angaben dafür haben.
In diesem Fall genügt es also eine weitere Default Route einzutragen, die eine höhere Metrik hat. Dies stellt sicher, dass die ASA keine zwei gleichberechtigten Routen erhält, mit denen sie nicht umgehen kann. Die Situation für die ASA bleibt also eindeutig.
(conf)# route red 0.0.0.0 0.0.0.0 198.51.100.254 2
An der Standard-Routingtabelle ändert sich damit ja nichts:
C 198.51.100.248 255.255.255.248 is directly connected, red C 198.51.100.0 255.255.255.192 is directly connected, green C 192.0.2.0 255.255.255.0 is directly connected, gray S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, green
Ganz anders ist nun aber die Situation für die Pakete dar, die aus dem (reverse)-NAT heraus fallen.
- Der NAT Eintrag enthält die Quell- und Ziel-Interfaces, sowie die IP-Adressen und Ports.
- Pakete bestehender Flows werden also nicht normal behandelt, sondern anhand des vorhandenen NAT-Eintrags.
- Damit umgehen sie sämtliches konfiguriertes Routing, ACLs etc. insbesondere die Standard-Routingtabelle.
- Da das Zielinterface fest steht, greift nur noch die Routingtabelle dieses Interfaces, also die niedrig priorisierte Default Route.
Und siehe an:
# ssh 198.51.100.249 16:38:20 IP 203.0.113.133.51310 > 198.51.100.249.22: S 3979383937:3979383937(0) 16:38:20 IP 198.51.100.249.22 > 203.0.113.133.51310: S 3186400021:3186400021(0) ack 3979383938 16:38:20 IP 203.0.113.133.51310 > 198.51.100.249.22: . ack 1 win 115 16:38:20 IP 198.51.100.249.22 > 203.0.113.133.51310: P 1:22(21) ack 1 win 114 16:38:20 IP 203.0.113.133.51310 > 198.51.100.249.22: . ack 22 win 115 16:38:20 IP 203.0.113.133.51310 > 198.51.100.249.22: P 1:21(20) ack 22 win 115 16:38:20 IP 198.51.100.249.22 > 203.0.113.133.51310: . ack 21 win 114
136: 16:38:20 192.0.2.5.51310 > 192.0.2.4.22: S 1381971035:1381971035(0) win 14600 137: 16:38:20 arp who-has 192.0.2.5 tell 192.0.2.4 138: 16:38:20 arp reply 192.0.2.5 is-at e8:b7:48:fd:89:81 139: 16:38:20 192.0.2.4.22 > 192.0.2.5.51310: S 2009198346:2009198346(0) ack 1381971036 win 14480 140: 16:38:20 192.0.2.5.51310 > 192.0.2.4.22: . ack 2009198347 win 115 141: 16:38:20 192.0.2.4.22 > 192.0.2.5.51310: P 2009198347:2009198368(21) ack 1381971036 win 114 142: 16:38:20 192.0.2.5.51310 > 192.0.2.4.22: . ack 2009198368 win 115 143: 16:38:20 192.0.2.5.51310 > 192.0.2.4.22: P 1381971036:1381971056(20) ack 2009198368 win 115 144: 16:38:20 192.0.2.4.22 > 192.0.2.5.51310: . ack 1381971056 win 114 145: 16:38:20 192.0.2.5.51310 > 192.0.2.4.22: P 1381971056:1381971848(792) ack 146: 16:38:20 192.0.2.4.22 > 192.0.2.5.51310: . ack 1381971848 win 126
Hurra!