IPSEC entre deux Fortigate 60

[adminrestel]

Bonjour à tous,
j'aimerais configurer une connexion IPSEC entre un fortifate 60 et un 60B.

J'ai suivi la documentation, en partant sur l'idée de réaliser une VPN basé sur les routes.

A la suite de cette installation, je me retrouve avec l'erreur suivante :

Code: Tout sélectionner

Initiator: sent XX.XX.XX.XX main mode message #1 (OK)
Negotiate SA Error: No matching gateway for new phase 1 request.


Je ne comprend pas de quelle passerelle il parle, j'ai la même erreur des deux cotés.

Alors oui, j’imagine qu'il faudra plus d'infos, mais déjà est-ce que cela vous évoque quelque chose de gros que j'aurais pu oublier ?

Je vous donnerais plus d'infos cet après-midi, mais sachez que je dispose d'une IP fixe des deux cotés, que j'ai bien suivi l'exemple fournit dans la doc.

Merci pour votre aide.

[ccnet]

VPN basé sur les routes

Je ne comprend pas ce que cela signifie.

Êtes vous certain d'avoir exactement les mêmes paramètres cryptographiques des deux côtés ?

[adminrestel]

En fait, lorsque l'on suit la procédure (l'exemple nottament) de configuration, on nous laisse le choix entre :
policy-based VPN et route-based VPN

Pour ma part j'ai trouvé plus simple de choisir le mode route-based, sachant que même avec le mode policy-based que j'ai testé ce matin, le problème est identique.

Pour répondre à :

Êtes vous certain d'avoir exactement les mêmes paramètres cryptographiques des deux côtés ?

Oui, si par paramètres cryptographiques ont entend avoir mis la même clef partagée.

Voici les informations sur le paramétrage du premier fortigate :

Plage réseau local : 192.168.1.0/255.255.255.0
Plage réseau distante : 192.168.3.0/255.255.255.0

Voici ma configuration :
Phase 1 :


Phase 2:


Ensuite j'ai crée deux plages d'adresses correspondant à mon réseau local et au réseau local distant (que je souhaite joindre via ce VPN) ici pour l'exemple :
Plage_locale 192.168.1.0/255.255.255.0
Plage_distant 192.168.3.0/255.255.255.0

Ensuite je vais dans le firewall ajoute deux règles :


et



Puis enfin j'ajoute ma règle de routage :


Le second j'ai tout pareil mais en inversé bien sûr

Voici l'erreur qui apparaît ensuite dans le journal :
2011-04-22 14:31:27 log_id=0101023003 type=event subtype=ipsec pri=error vd=root loc_ip=192.168.15.252 loc_port=500 rem_ip=213.XX.XXX.XXX rem_port=500 out_if="wan2" vpn_tunnel="unknown" cookies=2XXXXXXXXX/0000000000000000 action=negotiate status=negotiate_error msg="Negotiate SA Error: No matching gateway for new phase 1 request."


Est ce que vous voyez quelque chose d'affreux dans cette configuration qui semble pourtant correspondre à 100% avec ma doc ?

[jdh]

Il est étonnant qu'il n'y ait aucune information sur la connectivité vers Internet.
C'est important puisque Ipsec n'aime pas le NAT d'où l'option "NAT traversal" (nécessaire ici !).

Le terme "passerelle" est ambigu : s'agit-il de la passerelle locale ou de l'ip publique externe de l'autre extrémité ?
(Même s'il est mentionné plus loin une "passerelle ip locale").

Le message semble nettement indiquer la "passerelle"

Le routage statique me semble inutile : quand le lien sera monté, la route sera créé.

[ccnet]

Un petit google sur Negotiate SA Error: No matching gateway for new phase 1 request." ne devrait pas tomber loin ...
Je pense qu'il manque à chaque équipement une information sur l'ip (probablement) de l'autre extrémité. L'ip de l'extrémité distante est elle connu de chacun des fortigate ?

[adminrestel]

Un petit google sur Negotiate SA Error: No matching gateway for new phase 1 request." ne devrait pas tomber loin ...
Je pense qu'il manque à chaque équipement une information sur l'ip (probablement) de l'autre extrémité. L'ip de l'extrémité distante est elle connu de chacun des fortigate ?

J'ai bien évidement googlé pour "Negotiate SA Error: No matching gateway for new phase 1 request" ce qui ne pas avancé et j'en veux pour preuve que ce message apparaît déjà sur la première page de résultat de notre ami google !!!, de plus l'information sur l'ip distante est connue puisqu'elle est définie dans la phase 1 pour chaque équipement (c'est noté dans mes captures ).

Il est étonnant qu'il n'y ait aucune information sur la connectivité vers Internet.
C'est important puisque Ipsec n'aime pas le NAT d'où l'option "NAT traversal" (nécessaire ici !).

Le terme "passerelle" est ambigu : s'agit-il de la passerelle locale ou de l'ip publique externe de l'autre extrémité ?
(Même s'il est mentionné plus loin une "passerelle ip locale").

Le message semble nettement indiquer la "passerelle"
Le routage statique me semble inutile : quand le lien sera monté, la route sera créé.

Concernant la connexion Internet, d'un coté c'est une connexion Oleane monté via un modem Business Livebox. De l'autre une connexion orange monté via un modem dlink.

Le terme passerelle est effectivement ambigu mais le message d'erreur n'indique rien d'autre et je ne vois pas ou cette information semble manquer (puisque le message dit en gros qu'il ne trouve pas de passerelle correspondante pour la requete de ma phase1)

Concerant le routage statique, j'ai fait comme noté dans la doc

C'est vraiment difficile à debugger .....

[jdh]

Je n'ai jamais réussi à monter un ipsec derrière une Livebox Pro (cas testé : entre 2 pfSense).

Il est impératif de faire de l'ipsec avec "NAT traversal" !
Cela semble être le cas mais !

La "passerelle" indiqué DOIT être l'ip publique externe de l'autre extrémité.
Dans le cas d'un routeur (comme la livebox), il faut bien entendu qu'il y a les renvois nécessaires (500/tcp et 4900/tcp ?)

[ccnet]

IPSEC derrière une livebox ... effectivement connaissant les habitudes et les travers de FT ... bien sûr il faut renvoyer tout les flux

[adminrestel]

Merci pour vos réponses,
attention cependant, il ne s'agit pas d'une "vulgaire" livebox pro mais bien d'un business.
C'est certainement le même problème mais il ne faut pas confondre les deux produits.

Ensuite, d'après l'historique tous les flux sont bel est bien renvoyés vers le Fortigate qui se charge de les gérer par la suite.
Ce n'est pas le premier service que je met en place (nous avons configuré le PPTP qui mache raisonnablement bien, des redirections de ports pour OWA, pour du TSE, etc.) et c'est bien la première fois que nous sommes bloqué de la sorte.

Il faudrait quand même que je confirme cette redirection de flux mais je n'ai pas la main sur ce boitier FT (l'historique de ma boite est assez flou).

[ccnet]

Ce n'est pas le premier service que je met en place (nous avons configuré le PPTP qui mache raisonnablement bien, des redirections de ports pour OWA, pour du TSE, etc.) et c'est bien la première fois que nous sommes bloqué de la sorte.

IpSec est un peu "particulier" vis à vis du nat néanmoins. On ne peut pas tirer de conclusion d'une redirection de port fonctionnelle pour OWA pour faire fonctionner IPSec au travers d'un boitier qui translate. Ce qui ne signifie pas que cela ne peut pas fonctionner mais ...

[jdh]

La distinction des Livebox est inutile : savez vous faire un renvoi d'autre chose que tcp ou udp ?

Par manque de connaissance d'IPSEC, vous ne savez pas qu'IPSEC (en standard) ne se contente pas que de protocole tcp ou udp ! Sauf avec NAT traversal !
(Il est notable que PPTP, protocole VPN obsolète et à éviter, utilise aussi un autre protocole mais c'est effectivement géré par la Livebox de façon transparente.)

(ccnet écrit la même chose que moi, comme c'est bizarre !)


La SEULE solution (à ma connaissance) est de faire du "NAT traversal".
Mais vous n'en parlez pas !

Pour quelle raison, affirmez vous que l'autre extrémité reçoit quelque chose ?