1 votes

IPSec entre Palo Alto et Strong Swan - le trafic entre les IP des extrémités du tunnel (utilisé pour le transport ESP) doit passer par le tunnel.

Il y a un pare-feu Palo Alto (que je dois configurer) et un contrôleur industriel (qu'ils appellent CP) que je ne contrôle pas.

Disons que Palo Alto a l'IP externe 1.1.1.1 et CP a 2.2.2.2. Ce sont les IP qu'ils utilisent pour communiquer entre eux, et ces IP peuvent être vues sur un renifleur attaché à l'interface externe de PA.

Le tunnel IPSec est établi, et si le PC a une deuxième interface, tout fonctionne comme prévu. Mais certains de ces CP n'ont qu'une seule interface, qu'une seule IP, et cette IP devrait être accessible via le tunnel, mais elle ne l'est pas.

L'envoi d'un ping 2.2.2.2 depuis PA et l'observation du renifleur montrent pourquoi : PA envoie une demande d'écho ICMP non cryptée, qui ne reçoit pas de réponse. Lorsqu'à la place l'administrateur du PC envoie un ping à 1.1.1.1, le sniffer montre un paquet ESP allant de 2.2.2.2 à 1.1.1.1, puis PA répond avec une réponse ICMP echo non cryptée.

Comment puis-je faire en sorte que mon PA envoie tout le trafic par le tunnel, sauf le trafic IPSec ?

  • J'ai essayé de mettre en place une route vers 2.2.2.2 à travers le tunnel - bien sûr, le tunnel ne se met pas en place, car aucun paquet réseau n'est envoyé à travers le tunnel non établi.

  • J'ai essayé d'"expliquer" le PA pour envoyer le trafic IPSec d'une autre manière que le reste du trafic - la table de routage ne permet pas de spécifier le type de trafic.

  • J'ai essayé de définir un transfert basé sur une politique, qui nécessite une IP pour le tunnel. Le tunnel n'a que 2 IP ; j'ai essayé d'y attacher 1.1.1.1, ce que PA n'a pas apprécié.

  • J'ai trouvé des questions similaires, même ici sur serverfailt, et oui, c'est le même combat : comment acheminer certains paquets directement sur internet et d'autres paquets dans le tunnel, mais il s'agissait de l'open vpn sur Linux, pas de Palo Alto.

Une sortie de journal dont l'administrateur du CP a parlé m'a donné l'idée que les CP utilisent Strong Swan, et j'ai pu reproduire le comportement ci-dessus en utilisant mon PA et Strong Swan sur une boîte Linux.

Maintenant je peux tester plus rapidement, mais il ne me reste aucune idée de comment faire en sorte que PA fasse la différence entre les paquets cryptés et non cryptés en matière de routage.

Quelqu'un a-t-il une meilleure idée ?

Merci ! TomTomTom

1voto

RanRag Points 257

J'ai le regret de vous informer que vous êtes maintenant en mesure de partager ma frustration :

Les PANs ne font pas de mode de transport IPsec

Pourquoi ? Je n'en ai pas la moindre idée. Il est cassé au-delà de toute croyance. J'espère que quelqu'un me corrigera.

gateway charon: 11[IKE] <con3|14> establishing CHILD_SA con3{15}
gateway charon: 11[ENC] <con3|14> generating CREATE_CHILD_SA request 205 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
gateway charon: 11[ENC] <con3|14> parsed CREATE_CHILD_SA response 205 [ N(TS_UNACCEPT) ]
gateway charon: 11[IKE] <con3|14> received TS_UNACCEPTABLE notify, no CHILD_SA built

La solution que j'essaie de mettre en place consiste, bien sûr, à se débarrasser de ces saloperies hors de prix.

0voto

Mark Points 11

Je ne connais pas les pare-feu de Palo Alto, mais ce dont je suis sûr, c'est que nous ne pouvons pas faire passer le trafic par le tunnel et espérer qu'il soit crypté. Nous devons le spécifier via une liste d'accès cryptographique (ou quelque chose d'équivalent).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X