Problema
El objetivo es permitir el acceso completo de los usuarios de VPN a los recursos de la red interna después de la autenticación VPN correcta mediante RADIUS (en un servidor unido a un dominio de Windows) en Cisco Secure Firewall FTD.
La configuración de VPN ya está operativa; puede descargar e instalar el cliente VPN y autenticarse correctamente. El problema se centra en configurar el control de acceso necesario y las reglas NAT para permitir el acceso de recursos internos necesario a través de VPN.
Entorno
- Producto: Cisco Secure Firewall Firepower (FTD), versión 7.6.0 (aplicable a todos los FTD)
- Gestión: FirePOWER Management Center (FMC), FMC en la nube (cdFMC) o Firepower Device Manager (FDM)
- Versión del software: 7.6.0
Resolución
Estos pasos detallan la configuración necesaria para permitir que los usuarios de VPN accedan a los recursos internos (como RDP y Active Directory) en Cisco FTD. Esto incluye la creación de reglas de política de acceso, la configuración de exenciones de NAT y conexiones entre nodos NAT para el tráfico VPN, y el uso de comandos de solución de problemas para validar la configuración.
1: Agregue una entrada de lista de acceso para permitir que el conjunto de direcciones VPN acceda a los recursos internos.
access-list CSM_FW_ACL_ advanced permit ip object VPN_Pool any rule-id 268438528
access-list CSM_FW_ACL_ remark rule-id 268438528: ACCESS POLICY: Default Access Control Policy - Obligatorio
access-list CSM_FW_ACL_remark rule-id 268438528: L7 RULE: Permit_VPN_Pool
2: Agregue una regla de lista de acceso para permitir que los recursos internos envíen tráfico de retorno al grupo VPN:
access-list CSM_FW_ACL_ advanced permit ip any object VPN_Pool
Estas reglas se pueden endurecer posteriormente para restringir fuentes y destinos específicos según sea necesario.
3: Configuración de la exención de NAT o del protocolo de enlace NAT para el tráfico VPN
Existen dos enfoques comunes:
- Opción A: exención de NAT para el grupo VPN a la subred interna
nat (outside,inside) source static VPN_Pool VPN_Pool destination static Net_192.168.95.1-24 Net_192.168.95.1-24 route-lookup
- Opción B: Hairpin NAT for VPN Pool on Same Interface (no-proxy-arp)
nat (any,any) source static VPN_Pool VPN_Pool no-proxy-arp
- Opción C: NAT de horquilla dinámica para grupo VPN en interfaz externa
nat (outside,outside) interfaz dinámica VPN_Pool
El método correcto depende de si los recursos internos están en la misma interfaz física (requiere NAT de horquilla) o en interfaces diferentes (exención de NAT).
4: Utilice el comando packet-tracer para simular los flujos de tráfico del grupo VPN a los recursos internos y validar si el tráfico está permitido por la regla, NAT y ruta deseada.
packet-tracer input outside icmp 192.168.250.1 8 0 192.168.95.1
packet-tracer input outside tcp 192.168.250.1 12345 192.168.95.1 80
packet-tracer input inside icmp 192.168.95.1 8 0 192.168.250.1
packet-tracer input inside tcp 192.168.250.1 54321 192.168.95.1 443
—
Fase 5
ID: 5
Tipo: ACCESS-LIST
Resultado: PERMITIR
Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip object VPN_Pool any rule-id 268438528 access-list CSM_FW_ACL_ remark rule-id 268438528: ACCESS POLICY: Default Access Control Policy - Mandatoryaccess-list CSM_FW_ACL_ remark rule-id 268438528: L7 RULE: Permit_VPN_Pool
Información adicional: este paquete se enviará a snort para procesamiento adicional donde se alcanzará un veredicto. Regla de rendimientos de búsqueda basada en flujo directo: en id=0x40009d6ae190, priority=12, domain=permit, deny=false hits=1300, user_data=0x0000000000000000, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=240.0.0.0, mask=255.255.255.255, port=0, tag=any, ifc=any dst ip/id=240.5.0.2, mask=255.255.255.255, port=0, tag=any, ifc=any, dscp=0x0, input_ifc=any, output_ifc=any
Tiempo transcurrido: 0 ns
—
Fase 7
ID: 7
Tipo: NAT
Resultado: PERMITIR
Config: nat (outside,outside) interfaz dinámica VPN_Pool
Información adicional: Static translate 192.168.250.1/12345 to 192.168.250.1/12345 Forward Flow based lookup yields rule: in id=0x40009d6ad0a0, priority=6, domain=nat, deny=false hits=274, user_data=0x000040009963a2d0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=192.168.250.1, mask=255.255.255.255, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dscp=0x0, input_ifc=any, output_ifc=any
Tiempo transcurrido: 0 ns
Nota: La salida packet-tracer para la fase WebVPN podría mostrar un descarte para el tráfico VPN en la interfaz externa. Se espera este comportamiento para el tráfico de texto sin formato en la interfaz externa y todavía se puede utilizar para validar NAT.
Notas complementarias
- Es posible que las capturas de paquetes en la interfaz de usuario de Threat Defence solo muestren las solicitudes entrantes. Si no se observan caídas, pero el tráfico no llega al recurso interno, verifique las reglas de la lista de acceso y NAT.
- Cuando SSH no está disponible, toda la resolución de problemas se puede realizar a través de las funciones de la interfaz de usuario de Threat Defence en cdFMC, pero el uso del comando es limitado.
- Es posible que se necesiten algunas modificaciones en los dispositivos adyacentes para la conectividad de extremo a extremo. Asegúrese de que se validan según sea necesario.
Causa
La causa raíz fue una política de acceso y una configuración de NAT insuficientes para el tráfico del conjunto VPN a interno y entre interno y VPN. La configuración predeterminada no permitía una comunicación bidireccional completa desde el grupo VPN a los recursos internos y hacia atrás, ni manejaba los requisitos de NAT de horquilla para la entrada y salida del tráfico en la misma interfaz.
Contenido relacionado
Comentarios