Problème
L'objectif est d'activer l'accès complet des utilisateurs VPN aux ressources réseau internes après une authentification VPN réussie à l'aide de RADIUS (sur un serveur joint à un domaine Windows) sur Cisco Secure Firewall FTD.
La configuration du VPN est déjà opérationnelle ; vous pouvez télécharger et installer le client VPN et vous authentifier avec succès. Le problème se concentre sur la configuration du contrôle d'accès et des règles NAT nécessaires pour permettre l'accès aux ressources internes nécessaires sur le VPN.
Environnement
- Produit : Cisco Secure Firewall Firepower (FTD), version 7.6.0 (applicable à tous les FTD)
- Gestion : Firepower Management Center (FMC), FMC cloud (cdFMC) ou Firepower Device Manager (FDM)
- Version du logiciel : 7.6.0
Résolution
Ces étapes détaillent la configuration requise pour permettre aux utilisateurs VPN d'accéder aux ressources internes (telles que RDP et Active Directory) sur Cisco FTD. Cela inclut la création de règles de stratégie d'accès, la configuration des exemptions NAT et de la NAT hairpin pour le trafic VPN, et l'utilisation de commandes de dépannage pour valider la configuration.
1 : Ajoutez une entrée de liste d'accès pour permettre au pool d'adresses VPN d'accéder aux ressources internes.
access-list CSM_FW_ACL_ advanced permit ip object VPN_Pool any rule-id 268438528
access-list CSM_FW_ACL_ remark rule-id 268438528 : POLITIQUE D'ACCÈS : Politique de contrôle d'accès par défaut - Obligatoire
access-list CSM_FW_ACL_ remark rule-id 268438528 : L7 RULE : Permit_VPN_Pool
2 : Ajoutez une règle de liste d'accès pour permettre aux ressources internes d'envoyer le trafic de retour au pool VPN :
access-list CSM_FW_ACL_ advanced permit ip any object VPN_Pool
Ces règles peuvent ensuite être renforcées pour restreindre des sources et des destinations spécifiques, le cas échéant.
3 : Configurer l'exemption NAT ou la NAT en épingle à cheveux pour le trafic VPN
Il existe deux approches communes :
- Option A : exemption NAT pour le pool VPN vers le sous-réseau interne
nat (externe, interne) source static VPN_Pool VPN_Pool destination static Net_192.168.95.1-24 Net_192.168.95.1-24 route-lookup
- Option B : NAT en épingle à cheveux pour pool VPN sur la même interface (no-proxy-arp)
nat (any, any) source static VPN_Pool VPN_Pool no-proxy-arp
- Option C : NAT en épingle à cheveux dynamique pour pool VPN sur interface externe
nat (externe, externe) dynamic VPN_Pool interface
La méthode correcte dépend du fait que les ressources internes se trouvent sur la même interface physique (nécessitant la NAT hairpin) ou sur des interfaces différentes (exemption NAT).
4 : Utilisez la commande packet-tracer pour simuler les flux de trafic du pool VPN vers les ressources internes et valider si le trafic est autorisé par la règle, la NAT et la route prévues.
entrée packet-tracer en dehors d'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
entrée packet-tracer dans icmp 192.168.95.1 8 0 192.168.250.1
entrée packet-tracer dans tcp 192.168.250.1 54321 192.168.95.1 443
—
Phase 5
ID : 5
Type : ACCESS-LIST
Résultat : ALLOW
Config : access-group CSM_FW_ACL_ globalaccess-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
Informations supplémentaires : ce paquet sera envoyé à snort pour un traitement supplémentaire où un verdict sera atteint. La recherche basée sur le flux de transfert génère la règle suivante : in 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
Temps écoulé : 0 ns
—
Phase 7
ID : 7
Type : NAT
Résultat : ALLOW
Config : nat (externe, externe) dynamic VPN_Pool interface
Informations complémentaires : 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
Temps écoulé : 0 ns
Remarque : la sortie du traceur de paquets pour la phase WebVPN peut indiquer une baisse du trafic VPN sur l'interface externe. Ce comportement est attendu pour le trafic en texte clair sur l'interface externe et peut toujours être utilisé pour valider la NAT.
Notes supplémentaires:
- Il est possible que les captures de paquets dans l'interface de défense contre les menaces n'affichent que les demandes entrantes. Si aucune suppression n'est observée, mais que le trafic n'atteint pas la ressource interne, vérifiez les règles NAT et de liste d'accès.
- Lorsque SSH n'est pas disponible, tous les dépannages peuvent être effectués via les fonctions de l'interface utilisateur de Threat Defense dans cdFMC, mais l'utilisation des commandes est limitée.
- Il est possible que certaines modifications soient nécessaires sur des périphériques adjacents pour la connectivité de bout en bout. Assurez-vous que ces modifications sont validées si nécessaire.
Motif
La cause principale était une stratégie d'accès et une configuration NAT insuffisantes pour le trafic VPN vers interne et interne vers pool VPN. La configuration par défaut ne permettait pas une communication bidirectionnelle complète du pool VPN vers les ressources internes et inversement, ni ne gérait les exigences NAT en épingle à cheveux pour l'entrée et la sortie du trafic sur la même interface.
Autres informations utiles
Commentaires