ASA-VPN-Clients beziehen Adressen aus dem falschen DHCP-Pool

Lesen Sie dhcp-server und dhcp-network-scope auf der ASA als zwei verschiedene Felder, setzen Sie den Scope auf eine routingfähige Adresse außerhalb des Pools und prüfen Sie dann die Route.

AnyConnect-Clients erscheinen im falschen Subnetz, oder der DHCP-Server gibt überhaupt nichts heraus, während die Gruppenrichtlinie auf den ersten Blick korrekt aussieht. Auf einer ASA gibt es zwei Felder an zwei Stellen, die beide klingen wie „woher die Adressen kommen“, und das falsche zu setzen erzeugt genau das. Das Verbindungsprofil benennt den DHCP-Server; die Gruppenrichtlinie benennt ein Subnetz, aus dem dieser Server auswählen soll. Keines von beiden erzeugt einen Pool.

Drei Objekte, drei Fragen

Trennen Sie zuerst das Zuordnungsmodell vom Pool, denn die beiden Modelle teilen keine Konfiguration. Wenn die ASA Adressen selbst verteilt, definieren Sie einen lokalen Pool und richten die Gruppenrichtlinie darauf. Wenn ein externer DHCP-Server sie verteilt, benennt das Verbindungsprofil diesen Server, und die Gruppenrichtlinie liefert einen Scope-Hinweis. Beides zu vermischen ist der übliche Grund, warum eine Adresse nie erscheint.

IntentObjects involved
ASA allocates from its own poolip local pool plus the group policy's address-pool
External DHCP allocatesdhcp-server on the tunnel group, dhcp-network-scope on the group policy

Lesen Sie die wirksamen Werte, bevor Sie einen ändern

Eine ausgelassene Zeile ist nicht dasselbe wie ein explizites none. Die laufende Konfiguration zeigt, was Sie eingegeben haben; show run all group-policy zeigt, worauf die Richtlinie tatsächlich aufgelöst wird, einschließlich geerbter Standardwerte. Prüfen Sie beides, bevor Sie entscheiden, dass der Scope falsch ist, denn eine Gruppenrichtlinie, die von einer Standardrichtlinie erbt, kann einen Wert liefern, der in der kurzen Auflistung nie erscheint.

show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
 dhcp-network-scope ?

? lohnt sich auf Ihrer installierten Version zu lesen, da akzeptierte Werte und ihr Hilfetext sich zwischen Versionen unterscheiden. Die Cisco ASA 9.24 Referenz zur Gruppenrichtlinie dokumentiert das Attribut als routingfähige Adresse im gewünschten Subnetz, außerhalb des Zuordnungspools, wobei eine Interface-Adresse bevorzugt wird. Es ist nicht der Poolbereich und nicht die Netzwerknummer.

Setzen Sie den Scope auf eine Adresse, nicht auf einen Bereich

Angenommen, der Pool, den der Server verwenden soll, ist 10.50.30.50 bis 10.50.30.200 in einem /24, und das ASA-Interface in diesem Segment ist 10.50.30.1. Der Scope-Wert ist 10.50.30.1. 10.50.30.0 zu schreiben schlägt fehl, weil das die Netzwerknummer ist, und den Bereich zu schreiben schlägt fehl, weil das Attribut eine Adresse annimmt. Ist die gewählte Adresse keine Interface-Adresse, braucht sie eine statische Route, damit die Antwort des DHCP-Servers sie erreichen kann.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Dieses Fragment tut nur eines. Es konfiguriert den DHCP-Server nicht, legt dort keinen Pool an und macht aus einem teilweisen Remote-Access-Profil kein funktionierendes. Das hier dokumentierte Verhalten gilt nur für IPv4; erwarten Sie nicht, dass es DHCPv6 oder Präfixdelegation steuert.

Ändern Sie es mit einem Rollback-Punkt

Erstellen Sie zuerst einen Snapshot, damit das Rollback ein Befehl ist und kein Wiederaufbau. Speichern Sie die relevante Konfiguration vor dem Bearbeiten in eine Datei, und wissen Sie, was no in Ihrer Version wiederherstellt: Es setzt das Attribut auf seinen Standard- oder geerbten Wert zurück, der none sein kann statt der Richtlinie darüber.

copy running-config flash:pre-dhcp-scope.cfg
conf t
 group-policy RemoteStaff attributes
  no dhcp-network-scope
  dhcp-network-scope 10.50.30.1
 end
write memory

Das Attribut zu entfernen ist zugleich ein Diagnoseschritt. Ohne definierten Scope sucht der DHCP-Server in seinen eigenen Pools nach einer nicht zugewiesenen Adresse, sodass der Client an einer unerwarteten Stelle landen kann, aber immerhin eine Verbindung bekommt. Dieses Ergebnis sagt Ihnen, dass der Anforderungspfad funktioniert und die Poolauswahl das ist, was scheitert.

Prüfen Sie Adresse, Route und Berechtigungen

Lesen Sie die Zuweisung aus der Sitzungstabelle statt aus dem Dialog des Clients und bestätigen Sie dann, dass die Adresse zurück zum Tunnel routingfähig ist und die Filter der Gruppenrichtlinie den erwarteten Datenverkehr zulassen. Eine Zuordnungsentscheidung ist keine Routingentscheidung, und ein Client, der eine Adresse aus dem richtigen Pool erhält, kann trotzdem bei jeder Anforderung scheitern.

show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source inside

Zeigt die Sitzung die beabsichtigte Adresse, aber der Datenverkehr stirbt, ist der Scope als Verdächtiger erledigt. Schauen Sie auf die Rückroute, auf Split-Tunnel- oder Filtereinstellungen der Gruppenrichtlinie und darauf, ob der DHCP-Scope in einem Segment liegt, in das die ASA tatsächlich routet.

Ähnliche Artikel