Les clients VPN de l’ASA reçoivent des adresses du mauvais pool DHCP

Lisez dhcp-server et dhcp-network-scope de l’ASA comme deux champs distincts, réglez le scope sur une adresse routable hors du pool, puis vérifiez la route.

Les clients AnyConnect apparaissent sur le mauvais sous-réseau, ou le serveur DHCP refuse de délivrer quoi que ce soit, alors que la stratégie de groupe semble correcte au premier coup d’œil. Sur un ASA, deux champs situés à deux endroits sonnent tous deux comme « d’où viennent les adresses », et régler le mauvais produit exactement cela. Le profil de connexion nomme le serveur DHCP ; la stratégie de groupe nomme un sous-réseau dans lequel ce serveur doit choisir. Aucun des deux ne crée de pool.

Trois objets, trois questions

Séparez d’abord le modèle d’allocation du pool, car les deux modèles ne partagent pas la configuration. Si l’ASA distribue lui-même les adresses, vous définissez un pool local et pointez la stratégie de groupe dessus. Si un serveur DHCP externe les distribue, le profil de connexion nomme ce serveur et la stratégie de groupe fournit un indice de scope. Mélanger les deux est la raison habituelle pour laquelle une adresse n’apparaît jamais.

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

Lisez les valeurs effectives avant d’en changer une

Une ligne omise n’est pas la même chose qu’un none explicite. La configuration en cours montre ce que vous avez saisi ; show run all group-policy montre ce à quoi la stratégie se résout réellement, y compris les valeurs par défaut héritées. Vérifiez les deux avant de décider que le scope est faux, car une stratégie de groupe qui hérite d’une stratégie par défaut peut fournir une valeur qui n’apparaît jamais dans la liste courte.

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 ?

? vaut la peine d’être lu sur votre version installée, car les valeurs acceptées et leur texte d’aide diffèrent d’une version à l’autre. La référence Cisco ASA 9.24 pour la stratégie de groupe documente l’attribut comme une adresse routable sur le sous-réseau voulu, en dehors du pool d’allocation, avec une préférence pour une adresse d’interface. Ce n’est pas la plage du pool, et ce n’est pas le numéro de réseau.

Réglez le scope sur une adresse, pas sur une plage

Supposons que le pool que vous voulez voir utiliser par le serveur soit 10.50.30.50 à 10.50.30.200 sur un /24, et que l’interface de l’ASA sur ce segment soit 10.50.30.1. La valeur du scope est 10.50.30.1. Écrire 10.50.30.0 échoue parce que c’est le numéro de réseau, et écrire la plage échoue parce que l’attribut prend une seule adresse. Si l’adresse que vous choisissez n’est pas une adresse d’interface, elle a besoin d’une route statique pour que la réponse du serveur DHCP puisse l’atteindre.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Ce fragment ne fait qu’une seule chose. Il ne configure pas le serveur DHCP, n’y crée pas de pool et ne transforme pas un profil d’accès distant partiel en profil fonctionnel. Le comportement documenté ici est uniquement IPv4 ; ne comptez pas sur lui pour piloter DHCPv6 ou la délégation de préfixe.

Modifiez-le avec un point de retour

Faites d’abord un instantané, pour que le retour soit une commande et non une reconstruction. Enregistrez la configuration concernée dans un fichier avant de modifier, et sachez ce que no restaure sur votre version : il remet l’attribut à sa valeur par défaut ou héritée, qui peut être none plutôt que la stratégie au-dessus.

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

Retirer l’attribut est aussi une étape de diagnostic. Sans scope défini, le serveur DHCP cherche dans ses propres pools une adresse non attribuée, si bien que le client peut atterrir ailleurs que prévu mais se connecte au moins. Ce résultat indique que le chemin de la requête fonctionne et que c’est la sélection du pool qui échoue.

Vérifiez l’adresse, la route et les autorisations

Lisez l’attribution dans la table des sessions plutôt que dans la boîte de dialogue du client, puis confirmez que l’adresse est routable vers le tunnel et que les filtres de la stratégie de groupe autorisent le trafic attendu. Une décision d’allocation n’est pas une décision de routage, et un client qui reçoit une adresse du bon pool peut encore échouer à chaque requête.

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

Si la session affiche l’adresse voulue mais que le trafic meurt, le scope est écarté comme suspect. Regardez la route de retour, les réglages de split-tunnel ou de filtres de la stratégie de groupe, et si le scope DHCP se trouve sur un segment vers lequel l’ASA route réellement.

Articles similaires