L'ASA relie le même réseau entre ses interfaces. Étant donné que le pare-feu n’est pas un tronçon de routage, vous pouvez facilement introduire un pare-feu transparent dans un réseau existant.

La figure suivante montre un réseau de pare-feu transparent typique où les périphériques externes se trouvent sur le même sous-réseau que les périphériques internes. Le routeur interne et les hôtes semblent être directement connectés au routeur externe.

En plus de chaque adresse IP d’interface virtuelle de pont (BVI), vous pouvez ajouter une interface de Management (gestion) logement/port distincte qui ne fait partie d’aucun groupe de ponts et qui autorise uniquement le trafic de gestion vers l’ASA. Pour obtenir plus de renseignements, consultez Interface de gestion.

Pour les fonctionnalités qui ne sont pas directement prises en charge sur le pare-feu transparent, vous pouvez laisser le trafic passer pour que les routeurs en amont et en aval prennent en charge la fonctionnalité. Par exemple, en utilisant une règle d’accès, vous pouvez autoriser le trafic DHCP (au lieu de la fonction de relais DHCP non prise en charge) ou le trafic de multidiffusion comme celui créé par IP/TV. Vous pouvez également établir des contiguïtés de protocole de routage par l’intermédiaire d’un pare-feu transparent; vous pouvez autoriser le trafic OSPF, RIP, EIGRP ou BGP en fonction d’une règle d’accès. De même, des protocoles comme HSRP ou VRRP peuvent passer par le ASA.

Chaque groupe de ponts comprend une interface virtuelle de pont (BVI). ASA utilise l’adresse IP des BVI comme adresse source pour les paquets provenant du groupe de ponts. L’adresse IP BVI doit se trouver sur le même sous-réseau que les interfaces membres du groupe de ponts. Les BVI ne prennent pas en charge le trafic sur les réseaux secondaires; seul le trafic sur le même réseau que l’adresse IP BVI est pris en charge.

En mode transparent : seules les interfaces des membres du groupe de ponts sont nommées et peuvent être utilisées avec les fonctionnalités basées sur l’interface.

En mode routé : les BVI servent de passerelle entre le groupe de ponts et les autres interfaces routées. Pour le routage entre groupes de ponts/interfaces routées, vous devez nommer le BVI. Pour certaines fonctionnalités basées sur l’interface, vous pouvez utiliser le BVI lui-même :

• Access Rules (règles d’accès) : vous pouvez configurer des règles d’accès pour les interfaces des membres des groupes de ponts et pour les BVI; pour les règles de trafic entrant, l’interface membre est vérifiée en premier. Pour les règles de trafic sortant, les BVI sont vérifiés en premier.

• Serveur DHCPv4 : seuls les BVI prennent en charge la configuration de serveur DHCPv4.

• Routes statiques : vous pouvez configurer des routes statiques pour les BVI; vous ne pouvez pas configurer de routage statique pour les interfaces membres.

• Serveur syslog et autre trafic provenant de ASA : lorsque vous spécifiez un serveur syslog (ou un serveur SNMP, ou un autre service où le trafic provient de ASA), vous pouvez spécifier une interface BVI ou une interface membre.

Si vous ne nommez pas les BVI en mode routé, ASA n’acheminera pas le trafic du groupe de ponts. Cette configuration reproduit le mode de pare-feu transparent pour le groupe de ponts. Si vous n’avez pas besoin du mode à contextes multiples ni de mise en grappe, ni d’interfaces membre EtherChannel ou VNI, vous pouvez envisager d’utiliser le mode routé à la place. En mode routé, vous pouvez avoir un ou plusieurs groupes de ponts isolés comme en mode transparent, mais vous pouvez également avoir des interfaces de routage normales pour un déploiement mixte.

Le trafic des groupes de ponts est isolé des autres groupes de ponts; le trafic n’est pas acheminé vers un autre groupe de ponts dans ASA, et le trafic doit quitter ASA avant d’être acheminé par un routeur externe vers un autre groupe de ponts dans ASA. Bien que les fonctions de pont soient distinctes pour chaque groupe de ponts, de nombreuses autres fonctions sont partagées entre tous les groupes de ponts. Par exemple, tous les groupes de ponts partagent une configuration de serveur syslog ou de serveur AAA. Pour une séparation complète des politiques de sécurité, utilisez les contextes de sécurité avec un groupe de ponts dans chaque contexte.

Vous pouvez inclure plusieurs interfaces par groupe de ponts. Consultez Lignes directrices sur le mode pare-feu pour connaître le nombre exact de groupes de ponts et d’interfaces pris en charge. Si vous utilisez plus de deux interfaces par groupe de ponts, vous pouvez contrôler la communication entre plusieurs segments du même réseau, et pas seulement entre l’intérieur et l’extérieur. Par exemple, s’il y a trois segments internes avec lesquels vous ne souhaitez pas communiquer, vous pouvez placer chaque segment sur une interface distincte et les autoriser uniquement à communiquer avec l’interface externe. Vous pouvez également personnaliser les règles d’accès entre les interfaces pour autoriser uniquement les accès souhaités.

La figure suivante montre deux réseaux connectés à un ASA, qui comporte deux groupes de ponts.

Le trafic de groupe de ponts peut être acheminé vers d’autres groupes de ponts ou interfaces routées. Vous pouvez choisir d’isoler le trafic de groupe de ponts en n’attribuant pas de nom à l’interface BVI pour le groupe de ponts. Si vous nommez les BVI, alors les BVI participent au routage comme toute autre interface standard.

Une des utilisations d’un groupe de ponts en mode routé est d’utiliser des interfaces supplémentaires sur ASA au lieu d’un commutateur externe. Par exemple, la configuration par défaut de certains périphériques inclut une interface externe en tant qu’interface standard, puis toutes les autres interfaces affectées au groupe de ponts internes. Comme le but de ce groupe de ponts est de remplacer un commutateur externe, vous devez configurer une politique d’accès afin que toutes les interfaces du groupe de ponts puissent communiquer librement. Par exemple, comme dans la configuration par défaut, réglez toutes les interfaces au même niveau de sécurité, puis activez la communication de l'interface de même sécurité; aucune règle d’accès n’est requise.

En mode routé, certains types de trafic ne peuvent pas traverser l’ASA, même si vous l’autorisez dans un critère d’accès. Le groupe de ponts peut toutefois autoriser la quasi-totalité du trafic à passer en utilisant un critère d’accès (pour le trafic IP) ou une règle EtherType (pour le trafic non IP) :

• Trafic IP : en mode de pare-feu routé, le trafic de diffusion et de multidiffusion est bloqué même si vous l’autorisez dans un critère d’accès, y compris les protocoles de routage dynamique non pris en charge et le protocole DHCP (sauf si vous configurez le relais DHCP). Dans un groupe de ponts, vous pouvez autoriser ce trafic avec un critère d’accès (à l’aide d’une ACL étendue).

• Trafic non IP : AppleTalk, IPX, BPDU et MPLS, par exemple, peuvent être configurés pour passer par une règle EtherType.

Remarque

Le groupe de ponts ne transmet pas les paquets CDP ni les paquets qui n’ont pas d’EtherType valide supérieur ou égal à 0x600. Une exception est faite pour les BPDU et IS-IS, qui sont pris en charge.

• Le trafic IPv4 et IPv6 de monodiffusion est autorisé par le groupe de ponts automatiquement d’une interface à sécurité supérieure vers une interface à sécurité inférieure, sans règle d’accès.

• Pour le trafic de couche 3 passant d’une interface de sécurité faible à une interface de sécurité élevée, une règle d’accès est requise sur l’interface de sécurité faible.

• Les protocoles ARP sont autorisés dans le groupe de ponts dans les deux sens sans règle d’accès. Le trafic ARP peut être contrôlé par inspection ARP.

• Les paquets de découverte de voisin IPv6 et de sollicitation de routeur peuvent être transmis à l’aide de règles d’accès.

• Le trafic en diffusion et en multidiffusion peut être transmis à l’aide de règles d’accès.

Les adresses MAC de destination suivantes sont autorisées par le biais du groupe de ponts si elles le sont par votre politique d’accès (voir Autorisation du trafic de couche 3). Toute adresse MAC qui ne figure pas dans cette liste est abandonnée.

• VRAIE adresse MAC de destination de diffusion égale à FFFF.FFFF.FFFF

• Adresses MAC IPv4 de multidiffusion, de 0100.5E00.0000 à 0100.5EFE.FFFF

• Adresses MAC IPv6 de multidiffusion, de 3333.0000.0000 à 3333.FFFF.FFFF

• Adresse de multidiffusion BPDU égale à 0100.0CCC.CCCD

• Adresses MAC AppleTalk de multidiffusion, de 0900.0700.0000 à 0900.07FF.FFFF

Pour éviter les boucles avec le protocole Spanning Tree, les BPDU (Bridge Protocol Data Unit, Unité de données du protocole de pont) sont transmises par défaut. Pour bloquer les BPDU, vous devez configurer une règle EtherType pour les refuser. Vous pouvez également bloquer les BPDU sur les commutateurs externes. Par exemple, vous pouvez bloquer des BPDU sur le commutateur si des membres du même groupe de ponts sont connectés aux ports de commutation de différents VLAN. Dans ce cas, les BPDU d’un VLAN seront visibles dans l’autre VLAN, ce qui peut causer des problèmes de processus de sélection du pont racine du protocole Spanning Tree.

Si vous utilisez le basculement, vous souhaiterez peut-être bloquer les BPDU pour empêcher le port de commutation de passer à l’état de blocage lorsque la topologie change. Consultez Exigences en matière de groupes de ponts pour le basculement pour de plus amples renseignements.

Pour le trafic à l’intérieur d’un groupe de ponts, l’interface sortante d’un paquet est déterminée en effectuant une recherche d’adresse MAC de destination plutôt qu’une recherche de route.

Cependant, les recherches de routage sont nécessaires dans les situations suivantes :

• Trafic provenant de l’ASA : ajoutez une voie de routage statique/par défaut sur l’ASA pour le trafic destiné à un réseau distant où se trouve un serveur syslog, par exemple.

• Trafic de voix sur IP (VoIP) et TFTP avec inspection activée, et le point terminal se trouve à au moins un saut (ajouter une route statique sur l’ASA pour le trafic destiné au point terminal distant afin que les connexions secondaires soient réussies. L’ASA crée un « trou » temporaire dans la politique de contrôle d’accès pour autoriser la connexion secondaire; et comme la connexion peut utiliser un ensemble d’adresses IP différent de celui de la connexion principale, l’ASA doit effectuer une recherche de routage pour installer le sténopé sur la bonne interface.

  Parmi les autres applications concernées, on trouve :

  • CTIQBE

  • GTP

  • H.323

  • MGCP

  • RTSP

  • SIP

  • Skinny (SCCP)

  • SQL*Net

  • SunRPC

  • TFTP

• Trafic à au moins un saut de distance pour lequel l’ASA exécute la NAT - Configurer une route statique sur l’ASA pour le trafic destiné au réseau distant. Vous avez également besoin d’une route statique sur le routeur en amont pour que le trafic destiné aux adresses mappées soit envoyé à l’ASA.

  Cette exigence de routage est également vraie pour les adresses IP intégrées pour VoIP et DNS avec inspection et NAT activées, et les adresses IP intégrées sont à au moins un sautillement. L’ASA doit identifier la bonne interface de sortie pour pouvoir effectuer la traduction.

  

Le tableau suivant répertorie les fonctionnalités non prises en charge dans les groupes de ponts en mode transparent.

Le tableau suivant répertorie les fonctions non prises en charge dans les groupes de ponts en mode routé.

La figure suivante montre un utilisateur interne accédant à un serveur web externe.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. L’utilisateur sur le réseau interne demande une page Web à www.exemple.com.

2. L’ASA reçoit le paquet et, comme il s’agit d’une nouvelle session, il vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

3. L’ASA traduit l’adresse réelle (10.1.2.27) en adresse mappée 209.165.201.10, qui se trouve sur le sous-réseau de l’interface externe.

   L’adresse mappée peut se trouver sur n’importe quel sous-réseau, mais le routage est simplifié lorsqu’elle se trouve sur le sous-réseau d’interface externe.

4. L’ASA enregistre ensuite qu’une session est établie et transfère le paquet de l’interface externe.

5. Lorsque www.exemple.com répond à la demande, le paquet passe par l’ASA, et comme la session est déjà établie, le paquet contourne les nombreuses recherches associées à une nouvelle connexion. L’ASA effectue la NAT en ne traduisant pas l’adresse de destination globale en adresse d’utilisateur locale, 10.1.2.27.

6. L’ASA transmet le paquet à l’utilisateur interne.

La figure suivante montre un utilisateur externe accédant au serveur web DMZ.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau externe demande une page Web au serveur web DMZ en utilisant l’adresse mappée 209.165.201.3, qui se trouve sur le sous-réseau de l’interface externe.

2. L’ASA reçoit le paquet et traduit l’adresse mappée en adresse réelle 10.1.1.3.

3. Comme il s’agit d’une nouvelle session, l’ASA vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

4. L’ASA ajoute ensuite une entrée de session au chemin rapide et transfère le paquet de l’interface DMZ.

5. Lorsque le serveur web DMZ répond à la demande, le paquet passe par l’ASA et, comme la session est déjà établie, le paquet contourne les nombreuses recherches associées à une nouvelle connexion. L’ASA effectue la NAT en traduisant l’adresse réelle en 209.165.201.3.

6. L’ASA transmet le paquet à l’utilisateur externe.

La figure suivante montre un utilisateur interne accédant au serveur web DMZ.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau interne demande une page Web au serveur web DMZ en utilisant l’adresse de destination 10.1.1.3.

2. L’ASA reçoit le paquet et, comme il s’agit d’une nouvelle session, l’ASA vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

3. L’ASA enregistre ensuite qu’une session est établie et transfère le paquet de l’interface DMZ.

4. Lorsque le serveur web DMZ répond à la demande, le paquet emprunte le chemin d’accès rapide, ce qui lui permet de contourner les nombreuses recherches associées à une nouvelle connexion.

5. L’ASA transmet le paquet à l’utilisateur interne.

La figure suivante montre un utilisateur externe qui tente d’accéder au réseau interne.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau externe tente d’atteindre un hôte interne (en supposant que l’hôte a une adresse IP routable).

   Si le réseau interne utilise des adresses privées, aucun utilisateur externe ne peut atteindre le réseau interne sans la NAT. L’utilisateur externe peut tenter de joindre un utilisateur interne en utilisant une session NAT existante.

2. L’ASA reçoit le paquet et, parce qu’il s’agit d’une nouvelle session, il vérifie si le paquet est autorisé conformément à la politique de sécurité.

3. Le paquet est refusé et l’ASA abandonne le paquet et consigne la tentative de connexion.

   Si l’utilisateur externe tente d’attaque le réseau interne, l’ASA utilise de nombreuses technologies pour déterminer si un paquet est valide pour une session déjà établie.

La figure suivante montre un utilisateur dans la DMZ tente d’accéder au réseau interne.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau DMZ tente d’atteindre un hôte interne. Étant donné que la DMZ n’a pas à acheminer le trafic sur Internet, le système d’adressage privé n’empêche pas le routage.

2. L’ASA reçoit le paquet et, parce qu’il s’agit d’une nouvelle session, il vérifie si le paquet est autorisé conformément à la politique de sécurité.

   Le paquet est refusé et l’ASA abandonne le paquet et consigne la tentative de connexion.

La figure suivante montre un utilisateur interne accédant à un serveur web externe.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. L’utilisateur sur le réseau interne demande une page Web à www.exemple.com.

2. L’ASA reçoit le paquet et ajoute l’adresse MAC source au tableau d’adresses MAC, le cas échéant. Comme il s’agit d’une nouvelle session, il vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

3. L’ASA enregistre qu’une session est établie.

4. Si l’adresse MAC de destination se trouve dans son tableau, l’ASA transfère le paquet hors de l’interface externe. L’adresse MAC de destination est celle du routeur en amont, 209.165.201.2.

   Si l’adresse MAC de destination ne se trouve pas dans le tableau ASA, il tente de découvrir l’adresse MAC en envoyant une requête ARP ou un message Ping. Le premier paquet est abandonné.

5. Le serveur web répond à la demande; comme la session est déjà établie, le paquet contourne les nombreuses recherches associées à une nouvelle connexion.

6. L’ASA transmet le paquet à l’utilisateur interne.

La figure suivante montre un utilisateur interne accédant à un serveur web externe.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. L’utilisateur sur le réseau interne demande une page Web à www.exemple.com.

2. L’ASA reçoit le paquet et ajoute l’adresse MAC source au tableau d’adresses MAC, le cas échéant. Comme il s’agit d’une nouvelle session, il vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet selon une interface unique.

3. L’ASA traduit l’adresse réelle (10.1.2.27) en adresse mappée 209.165.201.10.

   Étant donné que l’adresse mappée ne se trouve pas sur le même réseau que l’interface externe, assurez-vous que le routeur en amont a une route statique vers le réseau mappé qui pointe vers l’ASA.

4. L’ASA enregistre ensuite qu’une session est établie et transfère le paquet de l’interface externe.

5. Si l’adresse MAC de destination se trouve dans son tableau, l’ASA transfère le paquet hors de l’interface externe. L’adresse MAC de destination est celle du routeur en amont, 10.1.2.1.

   Si l’adresse MAC de destination ne se trouve pas dans le tableau ASA, il tente alors de découvrir l’adresse MAC en envoyant une requête ARP et un message Ping. Le premier paquet est abandonné.

6. Le serveur web répond à la demande; comme la session est déjà établie, le paquet contourne les nombreuses recherches associées à une nouvelle connexion.

7. L’ASA effectue la NAT en ne traduisant pas l’adresse mappée en adresse réelle, 10.1.2.27.

La figure suivante montre un utilisateur externe accédant au serveur web interne.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau externe demande une page Web au serveur web interne.

2. L’ASA reçoit le paquet et ajoute l’adresse MAC source au tableau d’adresses MAC, le cas échéant. Comme il s’agit d’une nouvelle session, il vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

3. L’ASA enregistre qu’une session est établie.

4. Si l’adresse MAC de destination se trouve dans son tableau, l’ASA transfère le paquet hors de l’interface interne. L’adresse MAC de destination est celle du routeur en aval, 209.165.201.1.

   Si l’adresse MAC de destination ne se trouve pas dans le tableau ASA, il tente alors de découvrir l’adresse MAC en envoyant une requête ARP et un message Ping. Le premier paquet est abandonné.

5. Le serveur web répond à la demande; comme la session est déjà établie, le paquet contourne les nombreuses recherches associées à une nouvelle connexion.

6. L’ASA transmet le paquet à l’utilisateur externe.

La figure suivante montre un utilisateur externe qui tente d’accéder à un hôte sur le réseau interne.

Les étapes suivantes décrivent comment les données passent par l’ASA :

1. Un utilisateur sur le réseau externe tente d’atteindre un hôte interne.

2. L’ASA reçoit le paquet et ajoute l’adresse MAC source au tableau d’adresses MAC, le cas échéant. Comme il s’agit d’une nouvelle session, il vérifie que le paquet est autorisé selon les conditions de la politique de sécurité.

   Pour le mode de contexte multiple, l’ASA classe d’abord le paquet dans un contexte.

3. Le paquet est refusé, car aucun critère d’accès n’autorise l’hôte externe, et le ASA abandonne le paquet.

4. Si l’utilisateur externe tente d’attaque le réseau interne, l’ASA utilise de nombreuses technologies pour déterminer si un paquet est valide pour une session déjà établie.