VPN IPSEC établie - le routage avec 2 sous-réseaux ne fonctionne pas

VPN
1

Bonjour.
J’ai un VPN IPSEC entre 2 sites, mais en raison de réseaux qui se chevauchent, nous avons décidé que le SITE A créerait un nouveau VLAN avec un sous-réseau inutilisé dans le SITE B.
La topologie (simplifiée) est la suivante :
SITE A
SOUS-RÉSEAU A - 10.10.3.1/24 - sous-réseau principal
SOUS-RÉSEAU B - 10.10.10.1/24 - sous-réseau utilisé uniquement pour le vpn
SITE B
Sous-réseau C - 10.1.1.2/32
VPN IPSEC site A
adresse locale - 10.10.10.1/24
adresse distante - 10.1.1.2/32
VPN IPSEC site B
adresse locale - 10.1.1.2/32
adresse distante - 10.10.10.1/24

Le VPN IPSEC est établi et tout fonctionne, mais je veux pouvoir me connecter depuis le SITE A, sous-réseau A 10.10.3.1, vers le SITE B, sous-réseau C 10.1.1.2.
Depuis la CLI, si je définis comme adresse source 10.10.10.1, je peux pinger 10.1.1.2 ou faire telnet sur les ports disponibles, mais je me demande quels sont les règles de pare-feu ou les politiques de routage nécessaires pour permettre au sous-réseau A de se connecter au sous-réseau C.
L’assistant VPN a automatiquement ajouté la route vers LE SOUS-RÉSEAU C et les règles de pare-feu blackhole+2.
J’ai des règles de pare-feu en place permettant le trafic de :
SOUS-RÉSEAU A vers B (fonctionne)
SOUS-RÉSEAU B vers A (fonctionne)
SOUS-RÉSEAU B vers C (fonctionne)
Tunnel VPN vers SOUS-RÉSEAU B (fonctionne, ajouté par l’assistant VPN)
SOUS-RÉSEAU B vers Tunnel VPN (fonctionne, ajouté par l’assistant VPN)
Dans la route politique, j’ai ajouté SOUS-RÉSEAU A vers SOUS-RÉSEAU C, avec l’interface sortante VPN TUNNEL et la passerelle 0.0.0.0, mais sans succès.
Des idées ?

2

N’utilisez pas de tunnels VPN basés sur des politiques. Définissez les adresses locale/distante sur 0.0.0.0 et utilisez simplement des routes statiques et des politiques de pare-feu pour décider qui peut atteindre qui.

3

  1. Le tunnel ne laissera pas passer le sous-réseau A car il ne fait pas partie des sous-réseaux P2 de l’ipsec. Mais c’est normal puisqu’il ne devrait pas passer par le tunnel de toute façon.

  2. Vous devez faire une NAT source du trafic du Site A. Le Site B ne doit pas voir le SOUS-RÉSEAU A car cela causerait des problèmes de routage sur le Site B puisqu’ils ont déjà un sous-réseau similaire. Sur le site A, vous devez créer une règle de pare-feu où le sous-réseau A comme source est autorisé à accéder au sous-réseau C, mais vous ajoutez un pool NAT pour la règle et utilisez une IP du sous-réseau B pour la NAT. De cette manière, le site B voit le trafic provenant du sous-réseau B et peut le gérer sans problème. Lorsque le trafic revient au site A, le pare-feu traduira alors les adresses pour qu’il retourne à la vraie IP du sous-réseau A.

4

Cet exemple ne montre pas d’IP qui se chevauchent.

SITE A
SOUS-RÉSEAU A - 10.10.3.0/24   (/24 = 0-255)
SOUS-RÉSEAU B - 10.10.10.0/24  (/24 = 0-255)

SITE B
SOUS-RÉSEAU C - 10.1.1.2/32

Le sous-réseau C chevauche-t-il un réseau sur le SITE A ?

et/ou

Le sous-réseau A et/ou le sous-réseau B chevauche-t-il un réseau sur le SITE B ?

Si NON : Vous n’avez pas besoin de faire de NAT

Si OUI : Vous devez utiliser une NAT ou un pool IP dans la politique vers l’autre côté.

Si NAT est utilisé sans pool IP, une IP sur l’interface TUNNEL doit exister.

Supprimez la route politique, cela pourrait poser plus de problèmes qu’autre chose.

Le tableau de routage de chaque côté doit avoir une route vers le sous-réseau à l’autre extrémité.

Le SITE A doit savoir envoyer vers la destination 10.1.1.2/32 via le VPN TUNNEL
Le SITE C doit savoir envoyer vers la destination 10.10.10.0/24 via le VPN TUNNEL

Les systèmes eux-mêmes doivent aussi connaître le routage.
Donc un système en 10.10.3.x doit savoir comment atteindre 10.1.1.2 et vice versa.
N’assumez pas une route par défaut, VERIFIEZ !

Vous aurez besoin de politiques

sur le SITE A : du SOUS-RÉSEAU-A vers le TUNNEL VPN et vice versa
sur le site B : du SOUS-RÉSEAU-C vers le TUNNEL VPN et vice versa

L’utilisation de NAT dans l’une ou l’autre de ces configurations dépend du chevauchement mentionné auparavant et/ou du routage des systèmes.