Demandez-moi N'importe Quoi - Configuration, dépannage et meilleures pratiques de AnyConnect Remote Access VPN sur ASA et FTD.

[Modérateur Cisco]

Nos experts

Dinesh Moudgil est un ingénieur du support technique High Touch (HTTS) avec l'équipe de sécurité de Cisco. Il travaille sur les technologies Cisco depuis plus de 6 ans, se concentrant sur les pare-feux Cisco Next Generation, les systèmes de prévention des intrusions, la gestion des identités et le contrôle d'accès (AAA) et les VPN. Il détient les certifications CCNP, CCDP et CCIE # 58881, ainsi que les certifications de plusieurs fournisseurs tels que ACE, PCNSE et VCP.

Pulkit Saxena travaille en tant qu'ingénieur de support technique High Touch (HTTS) dans le domaine de la sécurité avec Cisco avec près de 7 ans d'expérience dans l'industrie pour l'équipe. Il a une expérience pratique avec plusieurs pare-feux, différentes solutions VPN, AAA et IPS de nouvelle génération, ainsi que l'enseignement de plusieurs formations. Pulkit détient les certifications de divers fournisseurs, à savoir Cisco et Juniper (CCIE Security et JNCIA).

Jason Grudier est le leader technique de l'équipe VPN TAC à Raleigh, Caroline du Nord. Il travaille chez Cisco au sein de l'équipe VPN depuis six ans. Avant de rejoindre l'équipe, il était ingénieur réseau chez Labcorp. Il travaille principalement sur le dépannage et la configuration d'AnyConnect sur toutes les plateformes Cisco ainsi que les authentifications DMVPN, GETVPN, Radius, LDAP et certificats.

Gustavo Medina est Ingénieur Commercial Systèmes au sein de l'équipe de ventes des Réseaux d'Entreprise. Il a plus de 10 ans d'expérience dans la sécurité et les réseaux d'entreprise. Au cours de sa carrière, il s'est concentré sur différentes tâches, de l'escalade technique et l'adoption de partenaires à la révision des évaluations de Certification Cisco. Gustavo est titulaire d'un CCNA, CCNP CCSI et d'un CCIE en sécurité (# 51487).

Note : En posant une question sur ce forum, vous nous autorisez à être traduit dans toutes les langues disponibles dans la communauté. Nos experts pourraient ne pas être en mesure de répondre immédiatement à chaque question. N'oubliez pas que vous pouvez poursuivre également des conversations sur ce sujet dans les discussions de Sécurité.

Cet événement est gratuit et ouvert à tous les publics, y compris les partenaires commerciaux, les ingénieurs réseau et télécommunications, les étudiants et les clients de Cisco.

---

Posez vos questions ! Toutes les questions par rapport aux solutions de Sécurité seront répondues : AnyConnect, VPN, Adaptive Security Appliance ASA, Politique d'accès dynamique (Dynamic Access Policy), scan d'hôte (Host Scan), détection de réseau de confiance (Trusted Network Detection TND), sélection de passerelle optimale (Optimal Gateway Selection OGS), WFO, licenses et meilleures pratiques, entre autres.

Posez vos questions du 6 au 17 avril 2020.

Poser une Question

** Les compliments encouragent la participation de tous nos membres et experts **
Complimentez leur réponses à vos questions pour les remercier !

[jgrudier]

Il semble que la mise en cache soit activée dans le fichier preferences.xml. Pour en être sûrs, si vous allez dans ProgramData/cisco/cisco secure mobility client/profile et ouvrez le fichier profilename.xml que vous avez configuré, veuillez envoyer la partie inférieure qui commence par... Veuillez modifier cette partie car ce n'est pas bon d'avoir du public partout 😊. Si l'adresse hôte et le nom d'hôte ne sont pas identiques, modifiez-les en conséquence pour qu'ils restent identiques.

secret.cisco.com
secret.cisco.com

Deviendrait
blah.blah.com
blah.blah.com

Nous savons donc que c'est la même valeur. Si elles sont différentes, modifiez tout simplement chacune en quelque chose d'aléatoire.

Il y a aussi un champ qui permet à l'utilisateur d'entrer dans cette boîte. true
Si ce paramètre est défini sur false, les utilisateurs ne pourront pas modifier ce qui est rempli par le profil xml.
Si la mise en cache est activée et que l'utilisateur saisit le FQDN, au lieu de sélectionner le nom d'hôte (HostName) dans le profil xml; lors de la prochaine connexion, il affichera la dernière connexion et le nom d'hôte (HostName).
Dans ce dossier, vous verrez un fichier preferences.xml où vous pouvez désactiver le cache.
C:\Users\\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client

Finalement, est-ce que vous avez plus d'un fichier profile.xml dans le dossier profiles ?

Si c'est ainsi, cela remplira plusieurs entrées dans la boîte de connexion AnyConnect de l'utilisateur.

[Modérateur Cisco]

Merci à vous deux,

Laissez-moi essayer de vous donner plus d'informations comme vous l'avez demandé :
Il s'agit de la partie inférieure d'un exemple de profil XML :

	<ServerList>
		<HostEntry>
			<HostName>COMPANY NAME - CLIENT (COUNTRY)</HostName>
			<HostAddress>https://vpn.company.com</HostAddress>
			<UserGroup>emea_client</UserGroup>
		</HostEntry>
	</ServerList>

Nous avons donc un nom d'hôte (affiché comme nom de profil) différent de l'adresse de l'hôte.

L'expérience utilisateur est la suivante:

• Lorsqu'un utilisateur est déjà connecté dans Windows et sélectionnez le nom du profil et se connecte, tout se passe comme prévu

• Lors de l'utilisation de SBL à la place, un travailleur distant se connectait d'abord via l'écran SBL, sélectionnant le profil, mais lorsqu'il était connecté à Windows, il voyait que le FQDN et non pas le profil sélectionné.

Jusqu'à présent, même avec ce problème visuel, l'utilisateur est connecté où il doit l'être.

Le problème survient lorsque l'utilisateur est déconnecté et doit se reconnecter, pendant qu'il est connecté à Windows. Dans ce cas, l'agent verra le nom de profil normal avec un FQDN qui pointe correctement vers notre pare-feu mais ne contient pas l'URL complète du profil, et donc il ne permet pas évidemment aucune connexion.

Dans ce cas, l'erreur d'affichage pose un problème car les gens sont confus s'ils doivent choisir le nom de profil ou le FQDN incorrectement affiché dans la liste des profils :)

J'espère que cela vous donnera toutes les informations dont vous avez besoin sur notre configuration et des indices sur ce qui se passe.

Remarque : toutes ces captures d'écran ont été effacées de nos informations internes mais ont été prises à partir d'un test en direct que je viens de réaliser moi-même.

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Gustavo Medina]

Bonjour les gars,

On dirait que cela est dû à:

• https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp53403

Vous pouvez suivre ce blog pour ce genre de problèmes.

Cordialement,
Gustavo

[Modérateur Cisco]

Salut Gustavo,

Merci, ça semble être exactement ce qui se passe dans notre cas.

Sauriez-vous s'il existe une version d'AnyConnect sans ce problème là ?

Jusque ici

• la version 4.7.04056 est affectée
• la version 4.8.03036 est affectée

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Dinesh Moudgil]

Salut Giovanni,

À ce stade, le bug est dans l'état assigné et il est prévu d'être corrigé dans les versions ultérieures.

Merci,
Dinesh

[Modérateur Cisco]

Comment utiliser packet-tracer avec RA VPN vpn-filter

Supposons que 10.10.10.10 est l'adresse vpn et que l'adresse interne est 192.168.10.3

• Quelle devrait être la syntaxe pour packet-tracer ?
• L'entrée Packet-tracer input outside entraînera la correspondance avec la liste d'accès à l'interface externe ?

Cordialement,
Viral Patel

* Voici la traduction d'un message créé à l'origine par patelvc7601 en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Gustavo Medina]

Bonjour patelvc7601

Après 9.9(1), nous avons ajouté l'option décryptée à packet-tracer, il est également possible de simuler un paquet qui traverse un tunnel VPN. Le paquet simulé «déchiffré» serait comparé à un tunnel VPN existant et les politiques de tunnel associées seraient appliquées.

Pour votre exemple, la syntaxe serait:

packet-tracer input outside tcp 10.10.10.10 5050 192.168.10.3 decrypted

Le tunnel doit être établi lorsque vous exécutez la commande ci-dessus, autrement vous recevrez un avertissement.

Cordialement,
Gustavo

[Modérateur Cisco]

Rebonjour,

Désolé à l'avance pour une question qui a des références croisées avec Cisco ISE.

Dans le cas où nous devons restreindre les utilisateurs d'accès à distance en fonction du pays d'origine, je sais ce qui suit:

• Firepower a un flux de géolocalisation et peut créer des règles ACP basées sur celles-ci mais pas pour le trafic se terminant au firewall (comme RA VPN l'est).
• L'utilisation de Cisco ISE comme authentification principale RADIUS peut utiliser l'attribut Tunnel-Client-Endpoint dans les règles d'authentification / autorisation, qui fournirait l'IP publique utilisée par un client qui se connecte.
• Cisco ISE n'a aucun flux de données de géolocalisation à ma connaissance.

Sur la base de ces considérations, je pensais regarder plus tard pour exporter la liste d'adresses IP de géolocalisation Firepower et créer des objets de condition dans Cisco ISE (via l'API REST), puis faire la correspondance si Tunnel-Client-Endpoint retombe dans l'objet de pays spécifique autorisé pour l'accès.

Maintenant, cela nous permet de poser les questions suivantes:

1) Les données IP de géolocalisation peuvent-elles être exportées via l'API REST depuis FMC ?

2) Est-il possible de créer en quelque sorte une condition dans ISE pour qu'une IP soit dans l'un des sous-réseaux répertoriés dans un objet? (Je crois que non)

3) Existe-t-il sur ISE ou sur Firepower de telles fonctionnalités dans la feuille de route ?

Je vous remercie !

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Dinesh Moudgil]

Salut Giovanni,

1) Vous pouvez obtenir les informations de mappage à partir des fichiers "ipv4_country_code_map" et "ipv6_country_code_map" qui se trouvent dans le répertoire "/var/sf/geodb" suivant sur le FMC

root@fmcv66:/var/sf/geodb# cat ipv4_country_code_map
et
root@fmcv66:/var/sf/geodb# cat ipv6_country_code_map

Il en résulte une sortie avec des adresses IP et les codes de pays associés. Retrouvez plus d'informations sur les codes de pays sur https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes

Si vous souhaitez connaître le code pays de FMC, vous pouvez exécuter ce perl command sur le FMC en tant que root:

root@fmcv66:/var/sf/geodb# perl -MFlyLoader -e 'my $t="country_code_continent_code_map";my @c=("country_name","country_code");my $n=0;my $s="*"x20;foreach my $row (@{SF::SFDBI::connect()->selectall_arrayref("SELECT ".join(",", @c)." from $t WHERE country_code=242")}){print "$s ".++$n.". $s\n";my $i=0; foreach (@{$row}){printf "%9s: %s\n",@c[$i++],$_}}'
******************** 1. ********************
country_name: fiji
country_code: 242
root@fmcv66:/var/sf/geodb#

Nous avons également l'API suivante pour récupérer les objets de géolocalisation:

GET geolocation

Request Type: GET

Description: récupère l'objet de géolocalisation associé à l'ID spécifié. Si aucun ID n'est spécifié, récupère la liste de tous les objets de géolocalisation.

URL: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations

URL for GET by ID: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations/{object_UUID}

Pour 2) et 3)

En aucun cas, je ne suis un expert en ISE, mais il effectue généralement une vérification basée sur une condition comme un attribut ou un groupe d'identité plutôt qu'une liste. Ne pensez pas que cela soit pris en charge pour le moment mais s'il y a un changement d'informations, je mettrai à jour le fil.

Cordialement,
Dinesh Moudgil

[Modérateur Cisco]

Merci Dinesh,

J'apprécie le support, je garderai un œil sur le fil pour votre mise à jour.

Cela peut résoudre un gros problème pour le moment, j'ai vu des fournisseurs d'authentification tiers renvoyer une condition d'échec basée sur la géolocalisation, mais à l'état actuel, toutes les solutions d'accès à distance ne peuvent pas être authentifiées pour ces fournisseurs, il serait donc convenable de les avoir en dehors de la boîte pour Firepower ou ISE.

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Modérateur Cisco]

giovanni.augusto

Notez que si vous utilisez Duo MFA (qui est pris en charge par le VPN d'accès à distance basé sur FTD) et que vous avez le plan Access or Beyond, vous pouvez appliquer des politiques Duo basées sur la géolocalisation des utilisateurs. Par exemple, vous pouvez interdire tout accès depuis l'extérieur de votre pays. Vous pouvez également le rendre plus granulaire - par exemple, faire une telle interdiction en général tout en exemptant certains utilisateurs qui voyagent ou sont basés à l'étranger.

* Voici la traduction d'un message créé à l'origine par Marvin Rhoads en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Modérateur Cisco]

Merci Marvin,

Est-ce que cela fonctionnerait en cas d'utilisation du proxy DUO avec ISE, ou cela fonctionne avec DUO avec l'authentification SAML directement à partir du FTD ?

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Gustavo Medina]

Bonjour les gars,

ISE ne fournit pas nativement un tel service, mais vous pouvez l'intégrer avec un MSM (Meraki Systems Manager devrait marcher) pour fournir ce service. À partir du FTD lui-même, vous pouvez configurer une ACL de plan de contrôle pour bloquer les blocs indésirables. Vous pouvez obtenir ces informations auprès de FMC comme l'a souligné Dinesh Moudgil, à partir du package géographique lui-même sur cisco.com, d'une source tierce ou en utilisant ANSIBLE que je préférerais:

• https://developer.cisco.com/site/ftd-ansible/#!country/country

Certainement des options auxquelles Marvin Rhoads fait référence, l'option DUO serait ma méthode préférée. Vous pouvez le faire avec le proxy DUO comme indiqué ici:

• https://duo.com/docs/ciscoise-radius
• https://duo.com/docs/cisco#cisco-ise-using-radius

Mais c'est aussi possible avec SAML, pas trop documenté, mais cette vidéo vous explique tout:

• https://youtu.be/W6bE2GTU0Is

Heureux de vous aider.
Gustavo

https://youtu.be/W6bE2GTU0Is

[Modérateur Cisco]

Dinesh Moudgil, Gustavo Medina et Marvin Rhoads,
Merci pour vos suggestions.

Marvin Rhoads : J'explorerai l'option DUO dès que j'aurai du temps libre (!) Et je le ferai éventuellement fonctionner en parallèle avec un autre fournisseur SFI que nous utilisons. Savez-vous si la géolocalisation fonctionne avec la licence gratuite pour les tests ?

Gustavo Medina et Dinesh Moudgil : J'aime toutes les options proposées, la plus immédiate pour moi ressemble maintenant à l'utilisation d'un ACL de plan de contrôle dans FTD avec géolocalisation et j'ai des questions sur cette option:

• L'ACL control-plane peut être utilisé via flexconfig ? Pour autant que je sache et il y a eu des problèmes dans le passé, je suppose qu'ils ont été résolus et que Cisco prend-il en charge une telle configuration.
• Dans le cas d'ACL control-plane dans FTD, puis-je utiliser directement l'objet de géolocalisation de SI ou dois-je créer et mettre à jour un objet "LINA" à utiliser avec flexconfig ?
• Avec ce scénario, puis-je appliquer cette ACL à un seul groupe de tunnels ? Pour autant que je sache, cela s'appliquera à tous les accès distants entrants pour ce pare-feu, donc cela signifie que nous restreindrions toute personne s'y connectant, ou pas ?

Si l'option 3 est un oui (restriction à tous les utilisateurs se connectant à un FW), la nouvelle fonctionnalité VRF-lite de FTD 6.6 serait-elle utile et créerait-elle plusieurs interfaces et attacherait-elle le ACL control-plane à ce "restricted outside" spécifique ?

En écrivant ces questions, j'en reviens à penser que l'ACL control-plane semble moins évolutif que la géolocalisation au niveau de l'authentification, mais j'aimerais avoir votre avis à ce sujet.

Merci

* Voici la traduction d'un message créé à l'origine par giovanni.augusto en anglais. Il a été traduit par la Communauté Cisco pour partager toutes les solutions dans les différentes langues.

[Gustavo Medina]

Salut giovanni.augusto,

Assurez-vous que vous exécutez une version avec ce correctif

• https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn78593

Vous aurez besoin d'utiliser un objet LINA.

C'est une règle générale. Non spécifique par groupe de tunnels (tunnel-group).
Cela devrait fonctionner, j'ai déjà testé l'application de policies à des VRF spécifiques et cela fonctionne, mais je ne l'ai pas testé sur ce scénario de plan de contrôle en particulier. Si cela ne marche pas, nous devrons déposer un bug. La multi-instance devrait également fonctionner.

Je préfère utiliser DUO pour ces règles basées sur la géolocalisation, car ce sera plus facile à gérer, mais ce n'est certainement pas votre seule option. Une autre alternative ce serait de séparer les fonctions et d'avoir un ASA dédié pour vos connexions VPN RA derrière le FTD, où vous pourriez appliquer des règles basées sur la géolocalisation pour ce trafic direct.

Cordialement,
Gustavo