¿Hereda una subred VPN el nivel de seguridad de la interfaz ASA?
Una subred VPN descifrada nunca hereda el nivel de seguridad de una interfaz. Compruebe sysopt connection permit-vpn, el filtro de grupo y el acceso de gestión por separado.
Alguien pregunta si la subred VPN de la sucursal tiene «nivel de seguridad 0 o 100» en el ASA, y la pregunta ya contiene el error. El nivel de seguridad es una propiedad de una interfaz local y se asigna de 0 a 100 en la configuración de la interfaz. Una subred remota que llega por un túnel no adquiere ninguno, se escriba como se escriba el crypto map. Por eso la pregunta no tiene respuesta numérica.
La pregunta práctica que sigue es mejor: qué política admite la sucursal hacia el servidor y cuál la mantiene lejos del propio cortafuegos. Son dos respuestas, y el procedimiento de abajo las separa.
Los niveles de seguridad pertenecen a las interfaces
Ejecute show running-config interface y verá security-level bajo cada interfaz física o interfaz VLAN, no bajo el grupo de túnel ni el crypto map. El permiso predeterminado de mayor a menor se evalúa entre esas interfaces, y por eso el número cambia el comportamiento de la inspección y de la ACL implícita en la ruta a la que pertenece.
En un flujo VPN descifrado, la entrada sigue siendo la interfaz outside donde termina el túnel, y la salida es la interfaz inside hacia el servidor. Anote ambas antes de tocar nada. Ese único paso elimina la mayor parte de la confusión, porque convierte una pregunta abstracta de confianza en un par de interfaces.
El bypass de ACL tiene una frontera con nombre
sysopt connection permit-vpn es el ajuste que la gente recuerda a medias cuando dice que el tráfico VPN ignora las ACL. Sí omite la ACL de la interfaz para el tráfico que califica como tráfico VPN, y la guía de parámetros 9.x lo acota por interfaz y dirección en lugar de declarar una excepción global.
Compruebe qué está configurado antes de razonar de memoria:
show running-config all sysoptpara ver el valor efectivo, no solo las líneas que no son predeterminadas.show running-config access-grouppara ver qué ACL se aplica a qué interfaz y dirección.show vpn-sessiondb detail l2lpara confirmar qué grupo de túnel y qué filtro usa realmente la sesión.
Desactivar ese ajuste para endurecer el acceso VPN es un cambio con gran alcance. Vuelve a someter cada flujo VPN que califica a la ACL exterior, lo que suele romper túneles que funcionaban de formas sin relación con la sucursal por la que le preguntaron.
Lea el filtro asociado a la sesión
El control real por túnel es el filtro VPN: una ACL referenciada por la política de grupo o por el nombre de usuario, aplicada después del descifrado y antes del cifrado. Un filtro a nivel de usuario anula el valor a nivel de grupo, así que dos personas del mismo grupo de túnel pueden tener un acceso efectivo distinto.
Confirme la precedencia en lugar de suponerla. show running-config group-policy <name> muestra el valor del grupo, y show running-config username <name> muestra si existe un valor por usuario. Si existen ambos, gana el valor del usuario. Después compare las entradas de esa ACL con el flujo que le interesa, en la dirección en que evalúa el filtro.
Un filtro que permite el servidor de aplicaciones no dice nada sobre la gestión. Son reglas separadas en una ruta separada.
Verifique un permiso y una denegación
Packet-tracer es la forma más rápida de ver la decisión sin esperar a que un usuario la reporte. Dele el flujo del lado descifrado y deje que nombre las etapas de ACL, NAT e inspección por las que pasa.
packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed- Lea la línea del resultado: nombra la ACL que permitió o descartó el paquete.
- Repita con el destino administrativo en la interfaz inside y confirme una denegación.
- Repita una vez más después de cualquier cambio, para que queden registrados tanto el estado anterior como el posterior.
Después verifique con tráfico real: una solicitud de aplicación correcta desde la sucursal y un intento SSH fallido hacia el ASA. Packet-tracer modela la ruta; un flujo en vivo demuestra que el modelo coincidía.
Revierta el cambio que lo hizo funcionar
Si la solución fue desactivar el bypass de ACL o ampliar un filtro, conserve la configuración anterior. Una captura show run de los objetos afectados, guardada antes del cambio, basta para restaurarlos; la configuración del ASA está orientada a líneas, así que revertir significa volver a introducir las líneas antiguas, no restaurar un archivo.
Registre el par de interfaces, el filtro efectivo, el nombre de la ACL de packet-tracer y los comandos exactos que cambió. Ese registro convierte la siguiente revisión en una comprobación de cinco minutos en lugar de otro debate sobre niveles de confianza.