Emplacement du pare-feu pour les tunnels VPN RA et L2L


8

Pour l' accès VPN à distance (RA) et LAN-to-LAN (L2L) , j'utilise actuellement une paire de concentrateurs Cisco VPN 3005 liés à des routeurs de périphérie Internet à l'extérieur et à l'intérieur liés à une paire interne de PIX 535 sur ce qui est le pare-feu en dehors de l'interface avant de pouvoir passer à nos vrais réseaux internes. Les VPN 3005 et PIX 535 sont remplacés par la plate-forme ASA-5545X. Ces pare-feu ne sont pas destinés à notre trafic Internet principal, uniquement VPN, et ils peuvent également servir de pare-feu internes pour le trafic entrant dans le centre de données via des lignes privées.

Les listes de contrôle d'accès du pare-feu interne étant combinées en un seul pare-feu qui dessert le trafic VPN et potentiellement tout autre trafic de ligne privée, pour les limites de sécurité et pour éliminer tout problème de routage potentiel, si l'interface intérieure du pare-feu VPN (5545) reste dans un sous-réseau distinct à partir du pare-feu Internet principal ou est-ce vraiment sans importance? OSPF s'exécute actuellement sur le pare-feu Internet (avec l'origine par défaut) et le VPN 3005. Comme ce centre de données est notre principal contrôleur de domaine pour le trafic Web - notre pain et beurre - je dois éliminer tout problème potentiel avec le placement du Pare-feu VPN qui pourraient interférer avec cela, même le moins du monde.

** Si l'interface intérieure du 5545 atterrit d'abord sur les commutateurs de périphérie L2, puis se connecte aux commutateurs agg pour une meilleure sécurité ou simplement que l'intérieur tombe directement dans la couche Agg, sachant également que le trafic de ligne privée peut passer par une autre interface sur le 5545 à l'avenir.

Seules les parties pertinentes de la connectivité L3 sont illustrées ci-dessous avec l'ASA-5545X * en question.

                     l'Internet
                        |
               Edge rtr + Edge rtr
                        |
5545 * (VPN / FW interne) + 5540 (FW Internet pour le trafic entrant / sortant DC)
                        |
                  Agg-1 + Agg-2
                        |
                       etc

Une paire de commutateurs L2 connecte tous les périphériques périphériques avant d'atteindre les commutateurs Agg.
Espace IP public à l'extérieur des pare-feu, privé à l'intérieur.
(Chaque pare-feu fait partie d'une paire de basculement distincte non représentée; les 5545 et 5540
n'ont aucune interaction.)

Vous recherchez des réponses / commentaires qui pourraient être considérés comme les meilleures pratiques ou ce que vous avez trouvé fonctionne mieux dans un réseau d'entreprise typique.


Existe-t-il un adressage privé ou public entre les routeurs de périphérie et l'ASA 5545X?
Mike Pennington

@MikePennington, adresses publiques entre les routeurs périphériques et les pare-feu ASA.
generalnetworkerror

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
Ron Maupin

Réponses:


3

Si l'interface intérieure du 5545 atterrit d'abord sur les commutateurs de périphérie L2, puis se connecte aux commutateurs agg pour une meilleure sécurité ou simplement que l'intérieur tombe directement dans la couche Agg, sachant également que le trafic de ligne privée peut passer par une autre interface sur le 5545 dans le futur

Puisque vous n'avez pas dit que les L2 exécuteraient des ACL, je ne verrais pas de différence. Je suppose que vous exécuterez le balisage sur les ASA internes à la couche de distribution. Mes pare-feu se connectent directement aux commutateurs d'agrégation avec un vlan dédié qui exécute HSRP / VRRP entre chaque ensemble de pare-feu et les commutateurs agg.

En ce qui concerne le trafic de ligne privée, je n'utilise pas ASA mais je pense qu'ils ont des zones construites comme IOS ZBF et vous empêcherez le trafic VPN d'aller vers / depuis le trafic de ligne privée sans passer par le filtrage de paquets.

Cela ressemble à des itinéraires par défaut vers le 5540 et vous utiliserez des itinéraires plus spécifiques pour accéder à vos pools d'accès VPN internes et aux adresses de ligne privée. Le 5545 a la route par défaut pointant vers le 5540 et il est normal que le trafic VPN arrive directement sur Internet (je ne sais pas si vous divisez le tunnel sur vos clients VPN) et d'autres routes vers votre espace d'adressage interne.

Je ne vois donc aucun problème réel avec votre plan. Mais certaines de mes hypothèses ci-dessus peuvent être erronées


Quel est votre raisonnement pour le vlan dédié entre chaque ensemble de pare-feu? BTW, les commutateurs de périphérie L2 n'ont pas d'ACL pour le trafic traversant.
generalnetworkerror

Pour une gestion plus facile, nous pouvons associer un VLAN à un pare-feu et un ensemble de HSRP sur les routeurs, VRRP sur les pare-feu à un cluster de pare-feu spécifique. Obtenez un peu plus d'isolement avec 1 domaine de diffusion par pare-feu. C'est fondamentalement un problème de style, pas vraiment besoin de le faire.
fredpbaker

2

D'après ce que je comprends de votre scénario, peu importe si vous avez deux interfaces internes de pare-feu différentes sur le même sous-réseau interne. Vous devez garder les éléments suivants à l'esprit lorsque vous prenez cette décision:

  1. Les avoir sur le même sous-réseau rend-il la configuration plus simple et plus facile?
  2. Cela va-t-il aider s'ils étaient sur des sous-réseaux séparés de quelque façon?
  3. Ai-je fait un routage approprié et je comprends le chemin de tout scénario de connexion? Par exemple, le trafic interne passera par quels appareils avant d'atteindre la destination?
  4. Ai-je tous configuré correctement toutes les règles sur les pare-feu pour m'assurer qu'aucun routage inter-domaine ne se produit? Cela signifie que le trafic sur le même sous-réseau qui appartient à un autre appareil (autre pare-feu) n'est pas acheminé. Cela pourrait être la chose la plus critique de votre configuration qui vous préoccupe. Encore une fois, tout dépend de vos chemins de trafic requis.

2

J'ai déployé des ASA dans des scénarios similaires et tout s'est bien passé, avec une planification et une maintenance minutieuses.

Pour l'interface externe, sécurisez tout d'abord votre processus OSPF à l'aide de MD5. Vous devez connecter cette interface à vos commutateurs d'agrégat L2.

Sur votre interface interne, nous pouvons plonger dans: - techniquement, vous pouvez le connecter à votre commutateur L3 afin de répartir le rôle ou la charge entre vos périphériques réseau, a également du sens pour un pare-feu normal (si à un moment donné, vous rencontrez des problèmes avec vos périphériques d'agrégation L2, au moins le réseau du bas vers le pare-feu fonctionne) - pour ce scénario, car ASA est utilisé par VPN, cela signifie que vous pouvez également connecter votre intérieur aux commutateurs d'agrégation L2. Sans ces commutateurs d'agrégat L2, votre 5545 deviendra inutile pour votre réseau. Néanmoins, pour ce choix, vous devez penser aux interfaces surveillées car toutes vos interfaces physiques de pare-feu seront connectées à un appareil physique. Conclusion: si j'ai des ports et une capacité pour une meilleure logique et un meilleur dépannage, je me connecterais directement à l'intérieur des commutateurs inférieurs L3.

Enfin en ce qui concerne votre 1ère question: j'ai utilisé l'interface intérieure à la fois comme réseau partagé avec l'autre pare-feu intérieur (vous pouvez rencontrer certains détails avec la même commande de sécurité-trafic et également comme réseau dédié, plutôt que d'utiliser des commutateurs inférieurs pour vous connecter au reste du réseau.

Je préfère le dernier car dans ce cas, le filtrage VPN L2L est effectué sur le pare-feu (ASA 5545) au lieu de l'ACL de stratégie de groupe (puis en l'appliquant au groupe de tunnels). Il est facile à gérer, à visualiser, à dépanner (pour moi) et aussi à m'éloigner de certains scénarios en épingle à cheveux de trafic ASA plus délicats.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.