Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment résoudre certains des problèmes de communication les plus courants du client Cisco AnyConnect Secure Mobility sur Firepower Threat Defense (FTD) lorsqu'il utilise SSL (Secure Socket Layer) ou IKEv2 (Internet Key Exchange version 2).
Contribution d'Angel Ortiz et Fernando Jimenez, ingénieurs du TAC Cisco.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Ce guide explique comment résoudre certains problèmes de communication courants que rencontrent les clients AnyConnect lorsque le FTD est utilisé comme passerelle de réseau privé virtuel (VPN) d'accès distant. Ces sections traitent des problèmes ci-dessous et leur apportent des solutions :
Procédez comme suit :
Étape 1. Vérifiez la configuration du tunnel partagé.
Accédez à Objets > Gestion des objets > Liste d'accès > Modifier la liste d'accès pour la transmission tunnel partagée.
Étape 2. Vérifiez la configuration de l'exemption NAT (Network Address Translation).
N'oubliez pas que nous devons configurer une règle d'exemption NAT pour éviter que le trafic ne soit traduit en adresse IP d'interface, généralement configurée pour l'accès Internet (avec traduction d'adresses de port (PAT)).
Note: Lorsque des règles d'exemption NAT sont configurées, vérifiez le no-proxy-arp et exécutez des options de recherche de route comme meilleure pratique.
Étape 3. Vérifiez la stratégie de contrôle d'accès.
Conformément à votre configuration de stratégie de contrôle d’accès, assurez-vous que le trafic provenant des clients AnyConnect est autorisé à atteindre les réseaux internes sélectionnés, comme l’illustre l’image.
Il existe deux scénarios possibles pour ce problème.
Assurez-vous que la stratégie de groupe est configurée pour la transmission tunnel partagée en tant que réseaux de tunnel spécifiés ci-dessous et NON comme Autoriser tout le trafic sur le tunnel, comme illustré dans l'image.
2. Le trafic destiné à Internet doit passer par le tunnel VPN.
Dans ce cas, la configuration de stratégie de groupe la plus courante pour la transmission tunnel partagée serait de sélectionner Autoriser tout le trafic sur le tunnel, comme illustré dans l'image.
Étape 1. Vérifiez la configuration de l'exemption NAT pour l'accessibilité du réseau interne.
N'oubliez pas que nous devons toujours configurer une règle d'exemption NAT pour avoir accès au réseau interne. Veuillez passer en revue l'étape 2 du Les clients AnyConnect ne peuvent pas accéder aux ressources internes de la section.
Étape 2. Vérifier la configuration de la reconnexion pour les traductions dynamiques.
Pour que les clients AnyConnect puissent accéder à Internet via le tunnel VPN, nous devons nous assurer que la configuration NAT de renvoi est correcte pour que le trafic soit traduit vers l'adresse IP de l'interface.
Étape 3. Vérifiez la stratégie de contrôle d'accès.
Conformément à votre configuration de stratégie de contrôle d’accès, assurez-vous que le trafic provenant des clients AnyConnect est autorisé à atteindre les ressources externes, comme l’illustre l’image.
Il existe deux scénarios possibles pour ce problème :
Quand Autoriser tout le trafic sur le tunnel est configuré pour AnyConnect signifie que tout le trafic, interne et externe, doit être transféré à la tête de réseau AnyConnect. Cela devient un problème lorsque vous avez NAT pour l’accès Internet public, puisque le trafic provient d’un client AnyConnect destiné à un autre client AnyConnect est traduit en adresse IP d’interface et par conséquent la communication échoue.
Étape 1. Vérifiez la configuration de l'exemption NAT.
Afin de résoudre ce problème, une règle d’exemption NAT manuelle doit être configurée pour permettre la communication bidirectionnelle au sein des clients AnyConnect.
Étape 2. Vérifiez la stratégie de contrôle d'accès.
Conformément à votre configuration de stratégie de contrôle d’accès, assurez-vous que le trafic en provenance des clients AnyConnect est autorisé, comme l’illustre l’image.
2. Anyconnect clients avec Réseaux de tunnel spécifiés ci-dessous configuration en place.
Avec Réseaux de tunnel spécifiés ci-dessous configuré pour les clients AnyConnect, seul le trafic spécifique est transféré vers via le tunnel VPN. Cependant, nous devons nous assurer que la tête de réseau a la configuration appropriée pour permettre la communication au sein des clients AnyConnect.
Étape 1. Vérifiez la configuration de l'exemption NAT.
Cochez Étape 1, dans la section Autoriser tout le trafic sur le tunnel.
Étape 2. Vérifiez la configuration de la transmission tunnel partagée.
Pour que les clients AnyConnect puissent communiquer entre eux, nous devons ajouter les adresses du pool VPN dans la liste de contrôle d’accès Split-Tunnel.
Note: S’il existe plusieurs pools d’adresses IP pour les clients AnyConnect et qu’une communication entre les différents pools est nécessaire, assurez-vous d’ajouter tous les pools dans la liste de contrôle d’accès de tunnellisation fractionnée et ajoutez également une règle d’exemption NAT pour les pools d’adresses IP nécessaires.
Étape 3. Vérifiez la stratégie de contrôle d'accès.
Assurez-vous que le trafic provenant des clients AnyConnect est autorisé, comme le montre l’image.
Il existe certains scénarios dans lesquels les clients AnyConnect doivent établir des appels téléphoniques et des vidéoconférences sur VPN.
Les clients AnyConnect peuvent se connecter à la tête de réseau AnyConnect sans problème. Ils peuvent atteindre des ressources internes et externes, mais les appels téléphoniques ne peuvent pas être établis.
Dans ce cas, nous devons examiner les points suivants :
Par défaut, FTD et ASA ont activé l'inspection des applications par défaut dans leur carte de stratégie globale.
Dans la plupart des cas, les téléphones VPN ne sont pas en mesure d’établir une communication fiable avec le CUCM, car l’inspection des applications activée sur la tête de réseau AnyConnect modifie le trafic voix et signal.
Pour plus d'informations sur l'application voix et vidéo dans laquelle vous pouvez appliquer l'inspection d'application, reportez-vous au document suivant :
Chapitre : Inspection des protocoles voix et vidéo
Afin de confirmer si un trafic d'application est abandonné ou modifié par la carte-politique globale, nous pouvons utiliser la commande show service-policy comme indiqué ci-dessous.
firepower#show service-policy
Global policy:
Service-policy: global_policy
Class-map: inspection_default
.
.
Inspect: sip , packet 792114, lock fail 0, drop 10670, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
.
Dans ce cas, nous pouvons voir comment l'inspection SIP supprime le trafic.
En outre, l'inspection SIP peut également traduire des adresses IP à l'intérieur de la charge utile, et non dans l'en-tête IP, cause des problèmes différents, il est donc recommandé de la désactiver lorsque nous voulons utiliser des services vocaux sur AnyConnect VPN.
Pour la désactiver, nous devons effectuer les étapes suivantes :
Étape 1. Passez en mode privilégié.
Pour plus d'informations sur l'accès à ce mode, reportez-vous au document suivant :
Chapitre : Utiliser l'interface de ligne de commande (CLI)
Étape 2. Vérifiez la carte de stratégie globale.
Exécutez la commande suivante et vérifiez si l'inspection SIP est activée.
firepower#show running-config policy-map
.
.
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
inspect icmp error
inspect esmtp
Étape 3. Désactivez l'inspection SIP.
Si l'inspection SIP est activée, désactivez la commande en cours ci-dessous à partir de l'invite de conclusion :
> configure inspection sip disable
Étape 4. Vérifiez à nouveau la carte de stratégie globale.
Assurez-vous que l'inspection SIP est désactivée à partir de la carte de stratégie globale :
firepower#show running-config policy-map
.
.
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
inspect icmp error
inspect esmtp
Comme indiqué dans la section précédente, un besoin très courant pour les clients AnyConnect est d’établir des appels téléphoniques lorsqu’ils sont connectés au VPN. Dans certains cas, l'appel peut être établi, mais les clients peuvent ne pas avoir accès à l'audio. Cela s'applique aux scénarios suivants :
Afin de résoudre ce problème, nous pouvons suivre les étapes suivantes :
Étape 1. Vérifiez la configuration de la transmission tunnel partagée.
Étape 2. Vérifiez la configuration de l'exemption NAT.
Les règles d’exemption NAT doivent être configurées pour exempter le trafic du réseau VPN AnyConnect vers le réseau des serveurs voix et pour permettre la communication bidirectionnelle au sein des clients AnyConnect.
Étape 3. Vérifiez que l'inspection SIP est désactivée.
Veuillez consulter la section précédente Les clients AnyConnect ne peuvent pas établir d'appels téléphoniques pour savoir comment désactiver l'inspection SIP.
Étape 4. Vérifiez la stratégie de contrôle d'accès.
Conformément à votre configuration de stratégie de contrôle d’accès, assurez-vous que le trafic provenant des clients AnyConnect est autorisé à atteindre les serveurs voix et les réseaux concernés, comme l’illustre l’image.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
26-Oct-2020 |
Première publication |