Los clientes VPN del ASA obtienen direcciones del pool DHCP incorrecto

Los clientes AnyConnect aparecen en la subred equivocada, o el servidor DHCP se niega a entregar nada en absoluto, mientras que la política de grupo parece correcta a primera vista. En un ASA hay dos campos en dos lugares que ambos suenan como «de dónde vienen las direcciones», y configurar el equivocado produce exactamente esto. El perfil de conexión nombra el servidor DHCP; la política de grupo nombra una subred de la que ese servidor debe elegir. Ninguno de los dos crea un pool.

Tres objetos, tres preguntas

Separe primero el modelo de asignación del pool, porque los dos modelos no comparten configuración. Si el ASA reparte las direcciones él mismo, se define un pool local y se apunta la política de grupo hacia él. Si las reparte un servidor DHCP externo, el perfil de conexión nombra ese servidor y la política de grupo aporta una pista de scope. Mezclar los dos es la razón habitual por la que una dirección nunca aparece.

Lea los valores efectivos antes de cambiar uno

Una línea omitida no es lo mismo que un none explícito. La configuración en ejecución muestra lo que escribió; show run all group-policy muestra a qué se resuelve realmente la política, incluidos los valores predeterminados heredados. Compruebe ambos antes de decidir que el scope es incorrecto, porque una política de grupo que hereda de una política predeterminada puede aportar un valor que nunca aparece en el listado corto.

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 ?

? conviene leerlo en la versión instalada, porque los valores aceptados y su texto de ayuda difieren entre versiones. La referencia de Cisco ASA 9.24 para la política de grupo documenta el atributo como una dirección enrutable en la subred deseada, fuera del pool de asignación, con preferencia por una dirección de interfaz. No es el rango del pool y no es el número de red.

Fije el scope en una dirección, no en un rango

Suponga que el pool que quiere que use el servidor es 10.50.30.50 hasta 10.50.30.200 en una /24, y que la interfaz del ASA en ese segmento es 10.50.30.1. El valor del scope es 10.50.30.1. Escribir 10.50.30.0 falla porque es el número de red, y escribir el rango falla porque el atributo toma una sola dirección. Si la dirección que elige no es una dirección de interfaz, necesita una ruta estática para que la respuesta del servidor DHCP pueda llegar a ella.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Este fragmento hace solo una cosa. No configura el servidor DHCP, no crea un pool allí ni convierte un perfil de acceso remoto parcial en uno funcional. El comportamiento documentado aquí es solo IPv4; no espere que dirija DHCPv6 ni delegación de prefijos.

Cámbielo con un punto de reversión

Haga primero una instantánea, para que la reversión sea un comando y no una reconstrucción. Guarde la configuración relevante en un archivo antes de editar y sepa qué no restaura en su versión: devuelve el atributo a su valor predeterminado o heredado, que puede ser none en lugar de la política que tiene encima.

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

Quitar el atributo también es un paso de diagnóstico. Sin un scope definido, el servidor DHCP busca en sus propios pools una dirección no asignada, así que el cliente puede aterrizar en un lugar inesperado pero al menos se conecta. Ese resultado indica que la ruta de la petición funciona y que lo que falla es la selección del pool.

Verifique la dirección, la ruta y los permisos

Lea la asignación de la tabla de sesiones y no del diálogo del cliente, luego confirme que la dirección es enrutable de vuelta al túnel y que los filtros de la política de grupo permiten el tráfico que espera. Una decisión de asignación no es una decisión de enrutamiento, y un cliente que recibe una dirección del pool correcto todavía puede fallar en cada petición.

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 sesión muestra la dirección que pretendía pero el tráfico muere, el scope queda descartado como sospechoso. Mire la ruta de retorno, los ajustes de split-tunnel o de filtros de la política de grupo, y si el scope DHCP está en un segmento al que el ASA realmente enruta.