Tunnel IPSEC entre deux pfsense virtuels
-
Bonjour,
J'ai créé deux pfsense dans deux machines virtuelles séparées sur deux pcs. Sur chaque patte LAN j'ai mis une adresse en 192.168 1.254 et 192.168.2.254, pour la patte WAN, une adresse de mon réseau local et notre adresse de passerelle en passerelle. J'arrive à pinguer les pfsense entre eux mais quand j'essaye de lancer un tunnel, j'ai une erreur en phase1.
J'utilise virtualbox 4.1.4 et pfsense 2.0. Ca me fait la même chose en 1.2.3.Qu'est-ce qui pourrait poser problème? Si besoin je mettrais plus d'info concernant les tunnels ou autres infos demandées.
Je précise que j'ai déjà configuré plusieurs tunnels en réel. J'ai déjà vérifié les adresses utilisées, les paramètres des tunnels me semblent correct (je me suis basé sur ceux étant en production depuis deux ans maintenant).Merci pour vos réponses qui j'espère vont m'aiguiller car la je ne vois pas trop pourquoi ça ne fonctionne pas
-
Pas assez de détails : Quelle erreur en phase 1, schéma réseau, etc.
-
Comme le dirai JDH … on ne virtualise pas les pare-feux -_-'
-
Je suis 'jdh'. Donc je vais (ré)expliquer pourquoi il NE FAUT PAS virtualiser un firewall !
Chaque système de virtualisation a SA vision des réseaux : l'un des switchs virtuels, l'autre des interfaces virtuelles, …
AVANT de tenter d'installer un firewall, il faut avoir compris comment le système de virtualisation fonctionne.
Si on n'a pas compris, on ne peut qu'avoir BEAUCOUP de mal à comprendre ce qu'il se passe : est-ce dû au firewall ? est ce dû à la virtualisation ?
Donc le chapitre 6 du pdf de doc de virtualbox a-t-il été lu, relu et rerelu ? (m'étonnerait)Si on veut (vraiment) être aidé, on donne des précisions, des messages de logs : là, y en a-t-il ? (Il y a une promesse mais ...)
Moi, comme d'autres, je ne vais pas écrire plus : un sujet comme cela, sur de mauvaises bases, sans infos ou presque, j'ai autre chose à faire que de commencer par demander des infos : soit il y a DES INFOS au départ et je peux éventuellement répondre, soit je ne réponds plus ...
NB : je ne pense pas que VirtualBox soit fait pour tester un firewall : faites donc les choses un peu sérieusement : ESXi ou KVM ou XEN et ajouter 2 ou 3 micro switchs, des câbles et 2 pc de test. Cela prend un peu de temps de préparation et c'est sûrement un gain de temps : plus on se prépare, plus on y arrive !
-
Effectivement cela ressemble à un setup de test. Il serait utile de connaitre l'erreur levée en phase 1….
Tout comme jdh, Je vous conseille vraiment d'utiliser des outils comme VMWare ESXI/Player pour tester ce genre de chose.
-
Bonjour,
Merci déjà d'avoir répondu, cette tentative a été faite pour permettre à des établissements d'enseignement agricole de simuler des tunnels IPSEC et de pouvoir faire des tests sans planter le serveur en production.
J'aimerai vraiment tester avec du matériel (serveur, routeur, etc…) mais ce n'est possible ni pour les établissements, ni pour moi. Mais je comprend bien que la virtualisation rajoute une part d'inconnu au milieu.
Je n'ai pas lu le chapitre 6 en question.Voila l'erreur que j'ai eu à chaque fois :
racoon: ERROR: phase1 negotiation failed due to time up. bbef780288489241:0000000000000000
Jan 11 15:55:39 racoon: INFO: delete phase 2 handler.
Jan 11 15:55:39 racoon: [Bourg-les-Valence]: [192.168.15.249] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 192.168.15.246[0]->192.168.15.129[0]
Jan 11 15:55:08 racoon: INFO: begin Aggressive mode.
Jan 11 15:55:08 racoon: [Bourg-les-Valence]: INFO: initiate new phase 1 negotiation: 192.168.15.129[500]<=>192.168.15.246[500]
Jan 11 15:55:08 racoon: [Bourg-les-Valence]: INFO: IPsec-SA request for 192.168.15.246 queued due to no phase1 foundAvez-vous eu vent de problème sur les versions 2.0 avec user distinguished name comme option pour my identifier pour la phase 1?
-
Le problème est lié à un problème de communication permettant la négociation de la phase 1 (UDP/500).
racoon: [Bourg-les-Valence]: [192.168.15.249] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 192.168.15.246[0]->192.168.15.129[0]
Le message dit qu'il n'a pas pu négocier une phase 2 car il n'avait pas de phase 1 associée.
Pour rappel du fonctionnement IPSEC:
- la phase 1 permet de réaliser l'échange de clés (via ISAKMP) et donc d'obtenir une SA (Security Association)
- la SA est utilisée comme matériel cryptographique lors de chaque négociation d'une phase2.
- lorsque la phase 1 expire, une nouvelle est renégociée, entrainant l'obtention d'une nouvelle SA et donc entrainant la renégociation des phase2. (d'ou l'importance d'avoir un lifetime de phase 2 inférieur au lifetime de phase1.)
Vérifiez la connectivité UDP/500 entre les noeuds.