le 06-04-2020 10:54 AM - dernière modification le 07-04-2020 10:24 AM par Monica Lluis
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.
** Les compliments encouragent la participation de tous nos membres et experts **
Complimentez leur réponses à vos questions pour les remercier !
le 13-04-2020 05:15 PM
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.
le 13-04-2020 05:29 PM
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:
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.
13-04-2020 05:33 PM - modifié 13-04-2020 05:33 PM
Bonjour les gars,
On dirait que cela est dû à:
Vous pouvez suivre ce blog pour ce genre de problèmes.
Cordialement,
Gustavo
le 13-04-2020 05:37 PM
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
* 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.
le 13-04-2020 05:39 PM
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
le 13-04-2020 05:46 PM
Supposons que 10.10.10.10 est l'adresse vpn et que l'adresse interne est 192.168.10.3
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.
le 13-04-2020 05:50 PM
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
le 13-04-2020 06:06 PM
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:
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.
le 13-04-2020 06:14 PM
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
le 13-04-2020 06:17 PM
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.
le 13-04-2020 06:19 PM
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.
le 13-04-2020 06:35 PM
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.
le 13-04-2020 06:42 PM
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:
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:
Mais c'est aussi possible avec SAML, pas trop documenté, mais cette vidéo vous explique tout:
Heureux de vous aider.
Gustavo
le 14-04-2020 07:21 AM
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:
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.
le 14-04-2020 07:37 AM
Salut giovanni.augusto,
Assurez-vous que vous exécutez une version avec ce correctif
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
Découvrez et enregistrez vos notes préférées. Revenez pour trouver les réponses d'experts, des guides étape par étape, des sujets récents et bien plus encore.
Êtes-vous nouveau ici? Commencez par ces conseils. Comment utiliser la communauté Guide pour les nouveaux membres
Parcourez les liens directs de la Communauté et profitez de contenus personnalisés en français