Cisco ASA : Configuration basée sur des politiques

Cette rubrique décrit une configuration basée sur des politiques pour un routeur Cisco ASA qui exécute un logiciel version 8.5 à 9.7.0.

Important

Oracle fournit des instructions de configuration pour un ensemble testé de fournisseurs et d'appareils. Utilisez la configuration appropriée pour votre fournisseur et votre version de logiciel.

Si la version de l'appareil ou du logiciel utilisée par Oracle pour vérifier la configuration ne correspond pas exactement à votre appareil ou à votre logiciel, vous pouvez tout de même créer la configuration nécessaire sur votre appareil. Consultez la documentation de votre fournisseur et apportez les ajustements nécessaires.

Si le fabricant de votre appareil ne figure pas dans la liste des fournisseurs et des appareils vérifiés, ou si vous êtes déjà familiarisé avec la configuration de votre appareil pour IPSec, consultez la liste des paramètres IPSec pris en charge et la documentation relative à votre fournisseur pour obtenir de l'aide.

Rappel : Oracle fournit différentes configurations en fonction du logiciel ASA :

  • 9.7.1 ou plus récente : Configuration basée sur des routes
  • 8.5 à 9.7.0 : Configuration basée sur des politiques (cette rubrique)
  • Antérieure à 8.5 : Non prise en charge par les instructions de configuration d'Oracle. Envisagez une mise à niveau vers une version plus récente.
Important

Oracle recommande d'utiliser une configuration basée sur des routes pour éviter les problèmes d'interopérabilité et pour obtenir la redondance des tunnels avec un seul appareil Cisco ASA.

Cisco ASA ne prend pas en charge la configuration basée sur des routes pour les versions du logiciel antérieures à 9.7.1. Pour de meilleurs résultats, si votre appareil le permet, Oracle vous recommande de procéder à une mise à niveau vers une version de logiciel qui prend en charge la configuration basée sur des routes.

Avec une configuration basée sur des politiques, vous ne pouvez configurer qu'un seul tunnel entre votre Cisco ASA et votre passerelle de routage dynamique (DRG).

Oracle Cloud Infrastructure offre un RPV site à site, une connexion IPSec sécurisée entre votre réseau sur place et un réseau en nuage virtuel (VCN).

Le diagramme suivant présente une connexion IPSec de base à Oracle Cloud Infrastructure avec des tunnels redondants. Les adresses IP de ce diagramme servent uniquement d'exemples et ne doivent pas être utilisées telles quelles.

Cette image résume la disposition générale de vos réseau sur place, tunnels IPSec de RPV site à site et réseau VCN.
Important

Oracle fournit des instructions de configuration pour un ensemble testé de fournisseurs et d'appareils. Utilisez la configuration appropriée pour votre fournisseur et votre version de logiciel.

Si la version de l'appareil ou du logiciel utilisée par Oracle pour vérifier la configuration ne correspond pas exactement à votre appareil ou à votre logiciel, vous pouvez tout de même créer la configuration nécessaire sur votre appareil. Consultez la documentation de votre fournisseur et apportez les ajustements nécessaires.

Si le fabricant de votre appareil ne figure pas dans la liste des fournisseurs et des appareils vérifiés, ou si vous êtes déjà familiarisé avec la configuration de votre appareil pour IPSec, consultez la liste des paramètres IPSec pris en charge et la documentation relative à votre fournisseur pour obtenir de l'aide.

Meilleures pratiques

Cette section décrit les meilleures pratiques et les points à considérer pour utiliser un RPV site à site.

Spécifique à Cisco ASA : Filtres RPV

Les filtres RPV permettent de filtrer le trafic avant qu'il entre ou après qu'il quitte un tunnel. Utilisez les filtres RPV s'il vous faut une granularité supplémentaire pour filtrer différents types de trafic ou flux sources/de destination. Pour plus d'informations, voir la documentation relative aux filtres RPV de Cisco.

La configuration des filtres RPV n'est pas incluse dans le modèle de configuration qui s'affiche dans la section Configuration du CPE. Pour utiliser des filtres RPV, ajoutez manuellement les éléments de configuration suivants.

  • Access control list (ACL) (Liste de contrôle d'accès) : Créez une LCA que le filtre RPV peut utiliser pour limiter le trafic autorisé à passer par les tunnels. Si un filtre RPV se sert déjà d'une LCA, n'utilisez pas cette dernière pour un groupe d'accès à l'interface.

    access-list ${vpnFilterAclName} extended permit ip ${VcnCidrNetwork} ${VcnCidrNetmask} ${onPremCidrNetwork} ${onPremCidrNetmask}
  • Group policy (Politique de groupe) : Appliquer le filtre RPV à votre politique de groupe.

    group-policy oracle-vcn-vpn-policy attributes
     vpn-filter value ${vpnFilterAclName}
  • Tunnel group (Groupe de tunnels) : Appliquer la politique de groupe à votre groupe de tunnels.

    tunnel-group ${oracleHeadend1} general-attributes
     default-group-policy oracle-vcn-vpn-policy

Trafic intéressant

Oracle recommande de garder le trafic intéressant en cours d'exécution par les tunnels IPSec à tout moment si votre équipement local d'abonné prend en charge cette option. Cisco ASA exige que vous configuriez la surveillance du CNS, ce qui maintient le trafic intéressant exécuté par les tunnels IPSec. Dans de nombreux cas, lorsque Cisco ASA agit en tant qu'initiateur, la phase 2 ne se produit pas tant qu'il n'y a pas de trafic intéressant, ce qui provoque l'arrêt de l'AS, que ce soit lors de l'élévation du tunnel ou après une nouvelle clé d'association de sécurité. Pour éviter de telles situations, un trafic continu intéressant ou des fonctionnalités telles que le contrat de niveau de service IP peuvent être utilisés. Pour plus d'informations, voir la section "Configuration du contrat de niveau de service IP" dans le modèle de configuration basée sur des politiques Cisco ASA.

Configurer tous les tunnels pour chaque connexion IPSec

Oracle déploie deux têtes de réseau IPSec pour chacune des connexions afin d'offrir une haute disponibilité pour les charges de travail critiques. Côté Oracle, ces deux têtes de réseau se trouvent sur différents routeurs à des fins de redondance. Oracle recommande de configurer tous les tunnels disponibles pour une redondance maximale. Il s'agit d'une partie essentielle de la philosophie "Design for Failure" (conçu pour résister aux pannes).

Disposer de CPE redondants dans vos emplacements de réseau sur place

Chacun de vos sites qui se connecte avec IPSec à Oracle Cloud Infrastructure doit disposer d'appareils en périphérie de réseau redondants (également appelés équipements locaux d'abonné (CPE)). Vous ajoutez chaque équipement local d'abonné à la console Oracle et créez une connexion IPSec distincte entre votre passerelle de routage dynamique (DRG) et chaque CPE. Pour chaque connexion PSec, Oracle provisionne deux tunnels pour des têtes de réseau IPSec géographiquement redondantes. Pour plus d'informations, voir Guide sur la redondance de connectivité (PDF).

Considérations relatives au protocole de routage

Lorsque vous créez une connexion IPSec de RPV site à site, elle possède deux tunnels IPSec redondants. Oracle vous encourage à configurer votre équipement local d'abonné pour utiliser les deux tunnels (si votre CPE le prend en charge). Auparavant, Oracle créait des connexions IPSec qui possédaient jusqu'à quatre tunnels IPSec.

Les trois types de routage suivants sont disponibles, et vous en choisissez un séparément pour chaque tunnel du RPV site à site :

  • Routage dynamique BGP : Les routes disponibles sont apprises de manière dynamique au moyen de BGP. La passerelle DRG apprend dynamiquement les routes de votre réseau sur place. Côté Oracle, la passerelle DRG annonce les sous-réseaux du VCN.
  • Routage statique : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
  • Routage basé sur des politiques : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.

Pour plus d'informations sur le routage avec RPV site à site, notamment des recommandations Oracle sur la manipulation de l'algorithme de sélection du meilleur chemin BGP, voir Routage pour RPV site à site.

Autres configurations importantes de l'équipement local d'abonné

Assurez-vous que les listes d'accès sur votre équipement local d'abonné sont configurées correctement pour ne pas bloquer le trafic nécessaire depuis ou vers Oracle Cloud Infrastructure.

Si plusieurs tunnels fonctionnent simultanément, le routage peut être asymétrique. Pour permettre le routage asymétrique, assurez-vous que votre équipement local d'abonné est configuré pour gérer le trafic provenant de votre VCN sur n'importe quel tunnel. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP. Pour plus de détails sur la configuration appropriée, communiquez avec le soutien technique du fournisseur de votre CPE. Pour configurer un routage symétrique, consultez Routage pour RPV site à site.

Spécifique à Cisco ASA : Restrictions et limites

Cette section décrit les caractéristiques et les restrictions importantes qui sont spécifiques à Cisco ASA.

Voir Limites de service pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite.

Détection de MTU de tunnel et de chemin

Vous disposez de deux options pour traiter la détection de MTU de tunnel et de chemin avec Cisco ASA :

Option 1 : Ajustement de la valeur MSS de TCP

L'unité maximale de transmission (taille de paquet) à travers le tunnel IPSec est inférieure à 1500 octets. Vous pouvez fragmenter les paquets trop volumineux pour qu'ils franchissent le tunnel. Ou vous pouvez signaler aux hôtes qui communiquent à travers le tunnel qu'ils doivent envoyer des paquets plus petits.

Vous pouvez configurer l'appareil Cisco ASA et modifier la taille de segment maximale (MSS) des nouveaux flux TCP passant par le tunnel. L'appareil ASA examine les paquets TCP où l'indicateur SYN est défini et remplace la valeur MSS par la valeur configurée. Cette configuration peut aider de nouveaux flux TCP à éviter l'utilisation de la détection d'unité de transmission maximale de chemin (PMTUD).

Utilisez la commande suivante pour modifier la valeur MSS. Cette commande ne fait pas partie de l'exemple de configuration dans la section Configuration de l'équipement local d'abonné de cette rubrique. Appliquez manuellement la commande d'ajustement de la valeur MSS de TCP, au besoin.

sysopt connection tcpmss 1387

Option 2 : Effacer/Définir le bit Ne pas fragmenter (DF)

La détection de MTU de chemin nécessite que tous les paquets TCP ait le bit Ne pas fragmenter (DF) activé. Si le bit DF est activé et qu'un paquet est trop volumineux pour passer par le tunnel, l'appareil ASA supprime le paquet à son arrivée. L'appareil ASA renvoie un paquet ICMP à l'expéditeur en indiquant que le paquet reçu était trop volumineux pour le tunnel. L'ASA propose trois options pour gérer le bit DF. Sélectionnez l'une des options et appliquez-la à la configuration :

  • Activer le bit DF (recommandé) : Le bit DF est défini dans l'en-tête IP des paquets. L'ASA peut toujours fragmenter le paquet si celui reçu à l origine n'a pas le bit DF.

    crypto ipsec df-bit set-df ${outsideInterface}
  • Désactiver le bit DF : Le bit DF est désactivé dans l'en-tête IP du paquet. Permet la fragmentation du paquet et son envoi à l'hôte final dans Oracle Cloud Infrastructure pour être réassemblé.

    crypto ipsec df-bit clear-df ${outsideInterface}
  • Ignorer (copier) le bit DF : L'ASA examine les informations de l'en-tête IP du paquet initial et copie le paramètre de bit DF.

    crypto ipsec df-bit copy-df ${outsideInterface}

Entrée du trafic RPV par un tunnel et sortie par un autre autorisées

Si le trafic RPV entre dans une interface qui a le même niveau de sécurité qu'une autre vers le saut suivant du paquet, vous devez permettre ce trafic. Par défaut, les paquets qui transitent entre des interfaces avec le même niveau de sécurité dans l'ASA sont abandonnés.

Ajoutez la commande suivante manuellement si vous devez autoriser le trafic entre des interfaces avec le même niveau de sécurité. Cette commande ne fait pas partie de l'exemple de configuration dans la section Configuration de l'équipement local d'abonné.

same-security-traffic permit inter-interface

Restrictions et limites générales

Cette section décrit les caractéristiques et les limites générales d'un RPV site à site.

Voir Limites de service pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite.

Routage asymétrique

Oracle utilise un routage asymétrique sur les multiples tunnels qui composent la connexion IPSec. Configurez vos pare-feux en conséquence. Dans le cas contraire, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de manière fiable.

Lorsque vous utilisez plusieurs tunnels vers Oracle Cloud Infrastructure, Oracle vous recommande de configurer votre routage de façon à guider le trafic de manière déterministe à travers le tunnel privilégié. Pour utiliser un tunnel IPSec principal et un autre de secours, configurez des routes plus spécifiques pour le tunnel principal (BGP) et des routes moins spécifiques (route sommaire ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous annoncez la même route (par exemple, une route par défaut) par tous les tunnels, le trafic de retour de votre réseau VCN à votre réseau sur place est dirigé vers n'importe lequel des tunnels disponibles. En effet, Oracle utilise un routage asymétrique.

Pour des recommandations de routage Oracle spécifiques sur la manière de forcer un routage symétrique, voir Routage pour RPV site à site.

Connexion IPSec basée sur des routes ou sur des politiques

Le protocole IPSec utilise des associations de sécurité (AS) pour déterminer comment chiffrer les paquets. Au sein de chaque association, pour définir comment chiffrer ou déchiffrer un paquet, il vous faut paramétrer des domaines de chiffrement pour mapper les adresses IP source et cible d'un paquet, ainsi que le type de protocole, sur une entrée de la base de données des associations de sécurité.

Note

Il est possible que d'autres fournisseurs ou que la documentation sectorielle utilisent le terme ID mandataire, index de paramètre de sécurité (SPI) ou sélecteur de trafic pour désigner les associations de sécurité ou les domaines de chiffrement.

Il existe deux méthodes générales pour mettre en oeuvre les tunnels IPSec :

  • Tunnels basés sur des routes : Également appelés tunnels basés sur les sauts suivants. Une consultation de la table de routage est effectuée sur l'adresse IP de destination d'un paquet. Si l'interface de sortie de cette route est un tunnel IPSec, le paquet est chiffré et envoyé à l'autre extrémité du tunnel.
  • Tunnels basés sur des politiques : Les adresses IP source et cible du paquet sont comparées à une liste d'énoncés de politique. Si une correspondance est trouvée, le paquet est chiffré en fonction des règles de cet énoncé.

Les têtes de réseau du RPV site à site Oracle utilisent des tunnels basés sur des routes, mais fonctionnent avec les tunnels basés sur des politiques. Il existe toutefois certaines restrictions indiquées dans les sections suivantes.

Domaine de chiffrement pour les tunnels basés sur des routes

Si votre équipement local d'abonné prend en charge les tunnels basés sur des routes, utilisez cette méthode pour configurer le tunnel. Il s'agit de la configuration la plus simple. C'est aussi celle qui offre le plus d'interopérabilité avec la tête de réseau du RPV Oracle.

Une connexion IPSec basée sur des routes utilise un domaine de chiffrement avec les valeurs suivantes :

  • Adresse IP source : (0.0.0.0/0)
  • Adresse IP de destination : (0.0.0.0/0)
  • Protocole : IPv4

Si vous devez être plus spécifique, vous pouvez utiliser une seule route sommaire pour vos valeurs de domaine de chiffrement au lieu d'une route par défaut.

Domaine de chiffrement pour les tunnels basés sur des politiques

Lorsque vous utilisez des tunnels basés sur des politiques, chaque entrée de politique (bloc CIDR d'un côté de la connexion IPSec) que vous définissez génère une association de sécurité IPSec avec chaque entrée admissible à l'autre extrémité du tunnel. Cette paire est appelée domaine de chiffrement.

Dans ce diagramme, l'extrémité DRG Oracle du tunnel IPSec comporte des entrées de politique pour trois blocs CIDR IPv4 et un bloc CIDR IPv6. L'extrémité CPE sur place du tunnel en comporte pour deux blocs CIDR IPv4 et deux blocs CIDR IPv6. Chaque entrée génère un domaine de chiffrement avec toutes les entrées possibles à l'autre extrémité du tunnel. Les deux côtés d'une paire SA doivent utiliser la même version d'IP. On obtient un total de huit domaines de chiffrement.

Diagramme montrant plusieurs domaines de chiffrement et comment déterminer leur nombre.
Important

Si votre CPE ne prend en charge que les tunnels basés sur des politiques, tenez compte des restrictions suivantes.

  • Le RPV site à site prend en charge plusieurs domaines de chiffrement, mais a une limite supérieure de 50 domaines de chiffrement.
  • Si vous avez rencontré une situation similaire à l'exemple ci-dessus et que vous n'avez configuré que trois des six domaines de chiffrement IPv4 possibles du côté de l'équipement local d'abonné, le lien serait répertorié dans un état "Partiellement actif", car tous les domaines de chiffrement possibles sont toujours créés du côté de la passerelle DRG.
  • Le routage basé sur des politiques dépend de RPV site à site v2. Voir Service de RPV site à site mis à jour pour plus d'informations sur le RPV site à site v2.
  • Selon le moment où votre tunnel a été créé, vous ne pourrez peut-être pas le modifier pour utiliser un routage basé sur des politiques et il vous faudra peut-être le remplacer par un nouveau tunnel IPSec.
  • Les blocs CIDR utilisés à l'extrémité DRG Oracle du tunnel ne peuvent pas chevaucher les blocs CIDR utilisés à l'extrémité CPE sur place du tunnel.
  • Un domaine de chiffrement doit toujours être compris entre deux blocs CIDR de la même version d'adresse IP.

Si votre équipement local d'abonné est derrière un appareil NAT

En général, l'identificateur IKE de CPE configuré à votre extrémité de la connexion doit correspondre à celui qu'Oracle utilise. Par défaut, Oracle utilise l'adresse IP publique du CPE, que vous fournissez lorsque vous créez l'objet CPE dans la console Oracle. Toutefois, si votre équipement local d'abonné est derrière un appareil NAT, l'identificateur IKE configuré à votre extrémité peut être l'adresse IP privée du CPE, comme illustré dans le diagramme suivant.

Cette image présente le CPE derrière un appareil NAT, les adresses IP publiques et privées, ainsi que l'identificateur IKE de CPE.
Note

Certaines plates-formes CPE ne permettent pas de modifier l'identificateur IKE local. Dans ce cas, vous devez remplacer l'ID IKE distant dans la console Oracle par l'ID IKE local de votre CPE. Vous pouvez entrer cette valeur lorsque vous configurez la connexion à IPSec ou plus tard, lorsque vous la modifiez. Pour Oracle, la valeur doit être une adresse IP ou un nom de domaine complet, tel que cpe.example.com. Pour obtenir des instructions, voir Modification de l'identificateur IKE de CPE utilisé par Oracle.

Paramètres IPSec pris en charge

Pour la liste des paramètres IPSec pris en charge indépendamment du fournisseur pour toutes les régions, voir Paramètres IPSec pris en charge.

Le numéro ASN BGP d'Oracle pour le domaine du nuage commercial est 31898. Si vous configurez un RPV site à site pour le nuage gouvernemental des États-Unis, voir Paramètres de RPV site à site requis pour le nuage gouvernemental et ASN BGP d'Oracle. Pour le nuage gouvernemental du Royaume-Uni, voir ASN BGP d'Oracle.

Configuration de l'équipement local d'abonné

Important

Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour votre équipement local d'abonné. Si vous avez besoin d'une assistance supplémentaire, communiquez directement avec le soutien technique de votre fournisseur.

La figure ci-dessous illustre la disposition de base de la connexion IPSec.

Cette image résume la disposition générale de la connexion et des tunnels IPSec.

Le modèle de configuration fourni concerne un routeur Cisco ASA exécutant la version 8.5 (ou ultérieure) du logiciel.

Note

Les versions 9.7.1 et ultérieures de Cisco ASA prennent en charge une configuration basée sur des routes. Il s'agit de la méthode recommandée pour éviter les problèmes d'interopérabilité.

Pour obtenir la redondance des tunnels avec un seul appareil Cisco ASA, vous devez utiliser la configuration basée sur des routes. Avec une configuration basée sur des politiques, vous ne pouvez configurer qu'un seul tunnel entre votre Cisco ASA et votre passerelle de routage dynamique (DRG).

Le modèle de configuration fait référence aux éléments que vous devez fournir :

  • Adresse IP publique du CPE : Adresse IP routable par Internet affectée à l'interface externe du CPE. Vous, ou l'administrateur d'Oracle, fournissez cette valeur à Oracle lors de la création de l'objet CPE dans la console Oracle.
  • Interface de tunnel interne (obligatoire si BGP est utilisé) : Adresses IP des côtés CPE et Oracle de l'interface de tunnel interne. Vous indiquez ces valeurs lors de la création de la connexion IPSec dans la console Oracle.
  • ASN BGP (obligatoire si BGP est utilisé) : Votre numéro ASN BGP.

De plus, vous devez :

  • Configurer le routage interne qui dirige le trafic entre l'équipement local d'abonné et votre réseau local.
  • Vous assurer de permettre le trafic entre votre ASA et votre réseau VCN Oracle (dans le modèle de configuration suivant, cette liste d'accès est désignée par la variable ${outboundAclName}).
  • Identifier la politique de groupe RPV interne (dans le modèle de configuration suivant, cette politique de groupe est désignée par oracle-vcn-vpn-policy).
  • Identifier le jeu de transformation utilisé pour votre mappage cryptographique (dans le modèle de configuration suivant, ce jeu de transformation est désigné par oracle-vcn-transform).
  • Identifier le nom et le numéro de séquence de la carte de chiffrement (dans le modèle de configuration suivant, la carte est désignée sous le nom oracle-vpn-map-v1 et le numéro de séquence 1).
  • Identifier le numéro d'opération de commande ping en continu du CNS IP (le modèle de configuration suivant utilise le numéro d'opération 1).
Important

Servez-vous du modèle de configuration suivant d'Oracle Cloud Infrastructure comme point de départ de ce que vous devez appliquer à votre équipement local d'abonné. La syntaxe de chaque configuration de CPE peut varier et dépend des versions de modèle et de logiciel. Veillez à comparer le modèle et la version de votre CPE au modèle de configuration approprié.

Certains paramètres référencés dans le modèle doivent être uniques sur le CPE, et cela ne peut être déterminé qu'en accédant au CPE. Assurez-vous que les paramètres sont valides pour votre CPE et qu'ils ne remplacent pas des valeurs configurées précédemment. Assurez-vous particulièrement que les valeurs suivantes sont uniques :

  • Noms ou numéros de politique
  • Noms et numéros de séquence de carte de chiffrement

  • Noms d'interface
  • Noms ou numéros de listes d'accès (le cas échéant)

Oracle prend en charge le protocole Internet Key Exchange version 1 (IKEv1) et version 2 (IKEv2). Si vous configurez la connexion IPSec dans la console pour utiliser IKEv2, vous devez limiter votre CPE aux paramètres de chiffrement IKEv2 et connexes qu'il prend en charge. Pour obtenir la liste des paramètres pris en charge par Oracle pour IKEv1 ou IKEv2, voir Paramètres IPSec pris en charge.

Oracle fournit un modèle de configuration distinct pour IKEv1 et pour IKEv2.

Oracle fournit également un outil permettant de générer le modèle, avec certaines des informations indiquées automatiquement. Pour plus d'informations, voir Utilisation de l'application d'aide pour la configuration de l'équipement local d'abonné.

Modèle de configuration IKEv1

Affichez le modèle de configuration IKEv1 au format plein écran pour en faciliter la lecture.

!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! IKEv1 Configuration Template
! The configuration consists of a single IPSec tunnel.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template involves setting up the following:
! Access Lists
! ISAKMP Policy
! Base VPN Policy
! IPSec Configuration
! IPSec Tunnel Group Configuration
! IP Routing (BGP or Static)
! Optional: Disable NAT for VPN Traffic
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template has various parameters that you must define before applying the configuration.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! PARAMETERS REFERENCED:
! ${OracleInsideTunnelIpAddress1} = Inside tunnel IP address of Oracle-side for the first tunnel. You provide these values when creating the IPSec connection in the Oracle Console.
! ${bgpASN} = Your BGP ASN
! ${cpePublicIpAddress} = The public IP address for the CPE. This is the IP address of your outside interface
! ${outboundAclName} = ACL used to control traffic out of your inside and outside interfaces
! ${oracleHeadend1} = Oracle public IP endpoint obtained from the Oracle Console.
! ${sharedSecret1} = You provide when you set up the IPSec connection in the Oracle Console, or you can use the default Oracle-provided value.
! ${outsideInterface} = The public interface or outside of tunnel interface which is configured with the CPE public IP address.
! ${vcnCidrNetwork} = VCN IP range
! ${vcnCidrNetmask} = Subnet mask for VCN
! ${onPremCidrNetwork} = On-premises IP range
! ${onPremCidrNetmask} = ON-premises subnet mask
! ${cryptoMapAclName} = Name of ACL which will be associated with the IPSec security association.
! ${vcnHostIp} = IP address of a VCN host. Used for IP SLA continuous ping to maintain tunnel UP state.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
 
! Access Lists
 
! Permit Traffic Between Your ASA and Your Oracle VCN
! Assuming there is an access-list controlling traffic in and out of your Internet facing interface, you will need to permit traffic between your CPE and the Oracle VPN Headend
! WARNING: The new ACL entry you add to permit the traffic between your ASA and VPN headend needs to be above any deny statements you might have in your existing access-list
 
access-list ${outboundAclName} extended permit ip host ${oracleHeadend1} host ${cpePublicIpAddress}
 
! Crypto ACL
! Create an ACL named ${cryptoMapAclName} which will later be associated with the IPSec security association using the 'crypto-map' command. This will define which source/destination traffic needs to be encrypted and sent across the VPN tunnel.
! Keep this ACL to a single entry. In a policy based configuration each ACL line will establish a separate encryption domain.
! The encryption domain used in this configuration sample will have a source/destination of any/VCN CIDR. Refer to the 'Encryption domain for policy-based tunnels' subsection for supported alternatives.
 
access-list ${cryptoMapAclName} extended permit ip any ${vcnCidrNetwork} ${vcnCidrNetmask}
 
! ISAKMP Policy
 
! ISAKMP Phase 1 configuration.
! IKEv1 is enabled on the outside interface.
! IKEv1 policy is created for Phase 1 which specifies to use a Pre-Shared Key, AES256, SHA1, Diffie-Hellman Group 5, and a Phase 1 lifetime of 28800 seconds (8 hours).
! If different parameters are required, modify this template before applying the configuration.
! WARNING: The IKEv1 group policy is created with a priority of 10. Make sure this doesn't conflict with any pre-existing configuration on your ASA.
 
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 28800
 
! Base VPN Policy
 
! An internal VPN group policy named 'oracle-vcn-vpn-policy' is created to define some basic VPN tunnel settings
! Idle and session timeouts are disabled to maintain the tunnel UP state and tunnel protocol is set to IKEv1
 
group-policy oracle-vcn-vpn-policy internal
group-policy oracle-vcn-vpn-policy attributes
 vpn-idle-timeout none
 vpn-session-timeout none
 vpn-tunnel-protocol ikev1
 
! IPSec Configuration
 
! Create an IKEv1 transform set named 'oracle-vcn-transform' which defines a combination of IPSec (Phase 2) policy options. Specifically, AES256 for encryption and SHA1 for authentication.
! If different parameters are required, modify this template before applying the configuration.
 
crypto ipsec ikev1 transform-set oracle-vcn-transform esp-aes-256 esp-sha-hmac
 
! A crypto map is used to tie together the important traffic that needs encryption (via crypto map ACL) with defined security policies (from the transform set along with other crypto map statements), and the destination of the traffic to a specific crypto peer.
! In this configuration example, a single crypto map is created named 'oracle-vpn-map-v1' This crypto map references the previously created crypto map ACL, the 'oracle-vcn-transform' transform set and further defines PFS Group 5 and the security association lifetime to 3600 seconds (1 hour).
! WARNING: Make sure your crypto map name and sequence numbers do not overlap with existing crypto maps.
! WARNING: DO NOT use the 'originate-only' option with an Oracle IPSec tunnel. It causes the tunnel's traffic to be inconsistently blackholed. The command is only for tunnels between two Cisco devices. Here's an example of the command that you should NOT use for the Oracle IPSec tunnels: crypto map <map name> <sequence number> set connection-type originate-only
 
crypto map oracle-vpn-map-v1 1 match address ${cryptoMapAclName}
crypto map oracle-vpn-map-v1 1 set pfs group5
crypto map oracle-vpn-map-v1 1 set peer ${oracleHeadend1}
crypto map oracle-vpn-map-v1 1 set ikev1 transform-set oracle-vcn-transform
crypto map oracle-vpn-map-v1 1 set security-association lifetime seconds 3600
 
! WARNING: The below command will apply the 'oracle-vpn-map-v1' crypto map to the outside interface. The Cisco ASA supports a single crypto map per interface. Make sure no other crypto map is applied to the outside interface before using this command.
 
crypto map oracle-vpn-map-v1 interface outside
 
! IPSec Tunnel Group Configuration
 
! This configuration matches the group policy 'oracle-vcn-vpn-policy' with an Oracle VPN headend endpoint.
! The pre-shared key for each Oracle VPN headend is defined in the corresponding tunnel group.
 
tunnel-group ${oracleHeadend1} type ipsec-l2l
tunnel-group ${oracleHeadend1} general-attributes
 default-group-policy oracle-vcn-vpn-policy
tunnel-group ${oracleHeadend1} ipsec-attributes
 ikev1 pre-shared-key ${sharedSecret1}
 
! IP SLA Configuration
 
! The Cisco ASA doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel.
! You must configure IP SLA on your device for a continuous ping so that the tunnel remains up at all times.
! You must allow ICMP on the outside interface.
! Make sure that the SLA monitor number used is unique.
 
sla monitor 1
 type echo protocol ipIcmpEcho ${vcnHostIp} interface outside
 frequency 5
sla monitor schedule 1 life forever start-time now
 
icmp permit any ${outsideInterface}
 
! IP Routing
! Pick either dynamic (BGP) or static routing. Uncomment the corresponding commands prior to applying configuration.
 
! Border Gateway Protocol (BGP) Configuration
! Uncomment below lines if you want to use BGP.
 
! router bgp ${bgpASN}
!  address-family ipv4 unicast
!   neighbor ${OracleInsideTunnelIpAddress1} remote-as 31898
!   neighbor ${OracleInsideTunnelIpAddress1} activate
!   network ${onPremCidrNetwork} mask ${onPremCidrNetmask}
!   no auto-summary
!   no synchronization
!  exit-address-family
 
! Static Route Configuration
! Uncomment below line if you want to use static routing.
  
! route outside ${VcnCidrNetwork} ${VcnCidrNetmask} ${OracleInsideTunnelIpAddress1}
 
! Disable NAT for VPN Traffic
 
! If you are using NAT for traffic between your inside and outside interfaces, you might need to disable NAT for traffic between your on-premises network and the Oracle VCN.
! Two objects are created for this NAT exemption. 'obj-OnPrem' represents the on-premises network as a default route, and 'obj-oracle-vcn-1' represents the VCN CIDR block used in Oracle Cloud Infrastructure.
! If different address ranges are required, modify this template before applying the configuration.
 
! object network obj-onprem
!  subnet 0.0.0.0 0.0.0.0
! object network obj-oracle-vcn-1
!  subnet ${vcnCidrNetwork} ${vcnCidrNetmask}
! nat (inside,outside) source static obj-onprem obj-onprem destination static obj-oracle-vcn-1 obj-oracle-vcn-1
Modèle de configuration IKEv2

Affichez le modèle de configuration IKEv2 au format plein écran pour en faciliter la lecture.

!-------------------------------------------------------------------------------------------------------------------------------------------------------------

! IKEv2 Configuration Template
! The configuration consists of a single IPSec tunnel.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template involves setting up the following:
! Access Lists
! IKEv2 Policy
! Base VPN Policy
! IPSec Configuration
! IPSec Tunnel Group Configuration
! IP Routing (BGP or Static)
! Optional: Disable NAT for VPN Traffic
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template has various parameters that you must define before applying the configuration.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! PARAMETERS REFERENCED:
! ${OracleInsideTunnelIpAddress1} = Inside tunnel IP address of Oracle-side for the first tunnel. You provide these values when creating the IPSec connection in the Oracle Console.
! ${bgpASN} = Your BGP ASN
! ${cpePublicIpAddress} = The public IP address for the CPE. This is the IP address of your outside interface
! ${outboundAclName} = ACL used to control traffic out of your inside and outside interfaces
! ${oracleHeadend1} = Oracle public IP endpoint obtained from the Oracle Console.
! ${sharedSecret1} = You provide when you set up the IPSec connection in the Oracle Console, or you can use the default Oracle-provided value.
! ${outsideInterface} = The public interface or outside of tunnel interface which is configured with the CPE public IP address.
! ${vcnCidrNetwork} = VCN IP range
! ${vcnCidrNetmask} = Subnet mask for VCN
! ${onPremCidrNetwork} = On-premises IP range
! ${onPremCidrNetmask} = ON-premises subnet mask
! ${cryptoMapAclName} = Name of ACL which will be associated with the IPSec security association.
! ${vcnHostIp} = IP address of a VCN host. Used for IP SLA continuous ping to maintain tunnel UP state.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------

! Access Lists

! Permit Traffic Between Your ASA and Your Oracle VCN
! Assuming there is an access-list controlling traffic in and out of your Internet facing interface, you will need to permit traffic between your CPE and the Oracle VPN Headend
! WARNING: The new ACL entry you add to permit the traffic between your ASA and VPN headend needs to be above any deny statements you might have in your existing access-list

access-list ${outboundAclName} extended permit ip host ${oracleHeadend1} host ${cpePublicIpAddress}

! Crypto ACL
! Create an ACL named ${cryptoMapAclName} which will later be associated with the IPSec security association using the 'crypto-map' command. This will define which source/destination traffic needs to be encrypted and sent across the VPN tunnel.
! Keep this ACL to a single entry. In a policy based configuration each ACL line will establish a separate encryption domain.
! The encryption domain used in this configuration sample will have a source/destination of any/VCN CIDR. Refer to the 'Encryption domain for policy-based tunnels' subsection for supported alternatives.

access-list ${cryptoMapAclName} extended permit ip any ${vcnCidrNetwork} ${vcnCidrNetmask}

! IKEv2 Policy

! IKEv2 is enabled on the outside interface.
! IKEv2 policy is created and specifies use of a Pre-Shared Key, AES256, SHA1, Diffie-Hellman Group 5, and a lifetime of 28800 seconds (8 hours).
! If different parameters are required, modify this template before applying the configuration.
! WARNING: The IKEv2 group policy is created with a priority of 10. Make sure this doesn't conflict with any pre-existing configuration on your ASA.

crypto ikev2 enable outside
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 5
 prf sha
 lifetime seconds 28800

! Base VPN Policy

! An internal VPN group policy named 'oracle-vcn-vpn-policy' is created to define some basic VPN tunnel settings
! Idle and session timeouts are disabled to maintain the tunnel UP state and tunnel protocol is set to IKEv2

group-policy oracle-vcn-vpn-policy internal
group-policy oracle-vcn-vpn-policy attributes
 vpn-idle-timeout none
 vpn-session-timeout none
 vpn-tunnel-protocol ikev2

! IPSec Configuration

! Create an IKEv2 IPSec proposal named 'oracle_v2_ipsec_proposal' which defines AES256 for encryption and SHA1 for authentication.
! If different parameters are required, modify this template before applying the configuration.

crypto ipsec ikev2 ipsec-proposal oracle_v2_ipsec_proposal
 protocol esp encryption aes-256
 protocol esp integrity sha-1

! A crypto map is used to tie together the important traffic that needs encryption (via crypto map ACL) with defined security policies (from the IPSec proposal along with other crypto map statements), and the destination of the traffic to a specific crypto peer.
! In this configuration example, a single crypto map is created named 'oracle-vpn-map-v2' This crypto map references the previously created crypto map ACL, the 'oracle_v2_ipsec_proposal' IPSec proposal and further defines PFS Group 5 and the security association lifetime to 3600 seconds (1 hour).
! WARNING: Make sure your crypto map name and sequence numbers do not overlap with existing crypto maps.
! WARNING: DO NOT use the 'originate-only' option with an Oracle IPSec tunnel. It causes the tunnel's traffic to be inconsistently blackholed. The command is only for tunnels between two Cisco devices. Here's an example of the command that you should NOT use for the Oracle IPSec tunnels: crypto map <map name> <sequence number> set connection-type originate-only

crypto map oracle-vpn-map-v2 1 match address ${cryptoMapAclName}
crypto map oracle-vpn-map-v2 1 set pfs group5
crypto map oracle-vpn-map-v2 1 set peer ${oracleHeadend1}
crypto map oracle-vpn-map-v2 1 set ikev2 ipsec-proposal oracle_v2_ipsec_proposal
crypto map oracle-vpn-map-v2 1 set security-association lifetime seconds 3600

! WARNING: The below command will apply the 'oracle-vpn-map-v2' crypto map to the outside interface. The Cisco ASA supports a single crypto map per interface. Make sure no other crypto map is applied to the outside interface before using this command.

crypto map oracle-vpn-map-v2 interface outside

! IPSec Tunnel Group Configuration

! This configuration matches the group policy 'oracle-vcn-vpn-policy' with an Oracle VPN headend endpoint.
! The pre-shared key for each Oracle VPN headend is defined in the corresponding tunnel group.

tunnel-group ${oracleHeadend1} type ipsec-l2l
tunnel-group ${oracleHeadend1} general-attributes
 default-group-policy oracle-vcn-vpn-policy
tunnel-group ${oracleHeadend1} ipsec-attributes
 ikev2 local-authentication pre-shared-key ${sharedSecret1}
 ikev2 remote-authentication pre-shared-key ${sharedSecret1}

! IP SLA Configuration

! The Cisco ASA doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel.
! You must configure IP SLA on your device for a continuous ping so that the tunnel remains up at all times.
! You must allow ICMP on the outside interface.
! Make sure that the SLA monitor number used is unique.

sla monitor 1
type echo protocol ipIcmpEcho ${vcnHostIp} interface outside
frequency 5
sla monitor schedule 1 life forever start-time now

icmp permit any ${outsideInterface}

! IP Routing
! Pick either dynamic (BGP) or static routing. Uncomment the corresponding commands prior to applying configuration.

! Border Gateway Protocol (BGP) Configuration
! Uncomment below lines if you want to use BGP.

! router bgp ${bgpASN}
!  address-family ipv4 unicast
!   neighbor ${OracleInsideTunnelIpAddress1} remote-as 31898
!   neighbor ${OracleInsideTunnelIpAddress1} activate
!   network ${onPremCidrNetwork} mask ${onPremCidrNetmask}
!   no auto-summary
!   no synchronization
!  exit-address-family

! Static Route Configuration
! Uncomment below line if you want to use static routing.

! route outside ${VcnCidrNetwork} ${VcnCidrNetmask} ${OracleInsideTunnelIpAddress1}

! Disable NAT for VPN Traffic

! If you are using NAT for traffic between your inside and outside interfaces, you might need to disable NAT for traffic between your on-premises network and the Oracle VCN.
! Two objects are created for this NAT exemption. 'obj-OnPrem' represents the on-premises network as a default route, and 'obj-oracle-vcn-1' represents the VCN CIDR block used in Oracle Cloud Infrastructure.
! If different address ranges are required, modify this template before applying the configuration.

! object network obj-onprem
!  subnet 0.0.0.0 0.0.0.0
! object network obj-oracle-vcn-1
!  subnet ${vcnCidrNetwork} ${vcnCidrNetmask}
! nat (inside,outside) source static obj-onprem obj-onprem destination static obj-oracle-vcn-1 obj-oracle-vcn-1

Vérification

Les commandes ASA suivantes sont incluses pour le dépannage de base. Pour des informations plus exhaustives, voir le document Dépannage IPSec de Cisco.

Utilisez la commande suivante pour vérifier que les associations de sécurité ISAKMP sont créées entre les deux pairs.

show crypto isakmp sa

Utilisez la commande suivante pour vérifier le statut de toutes vos connexions BGP.

show bgp summary

Utilisez la commande suivante pour vérifier la table de routage d'ASA.

show route

Un service Surveillance, également disponible dans Oracle Cloud Infrastructure, vous permet de contrôler vos ressources en nuage de manière active et passive. Pour plus d'informations sur la surveillance de votre RPV site à site, voir Mesures du RPV site à site.

En cas de problèmes, voir Dépannage du RPV site à site.