Vpn Ipsec, pfsense to Netopia, net to net

Français
Log in to reply
  • M

    Bonjour à tous,

    Toutes mes excuses pour ce post, mais mes nombreuses heures de recherche et de lecture ne m'ont pas permis de trouver la réponse.

    Actuellement, j'utilise Ipcop pour établir un vpn ipsec avec un routeur Netopia 3346ENT. J'envisage sérieusement le remplacement d'Ipcop par Pfsense (v1.2.2 dans mes tests), mais je bloque pour l'instant complètement sur l'établissement du vpn ipsec entre Pfsense et le routeur Netopia.

    Tous les vpn sont configurés comme ceci :

    Phase 1 :
    mode : main
    encryption : 3des
    hash algorithm : md5
    dh key group : 2
    authentication method : PSK

    Phase 2 :
    protocol : esp
    encryption algorithm : 3des
    hash algorithm : md5
    PFS key group : 2

    Soit Pfsense, Ipcop et Netopia chacun sur une ip fixe. Le wan de Pfsense est en mode PPPOE. Les vpn ipsec donnent comme résultat :

    Pfsense <-> Ipcop = Ok (sous condition)
    Pfsense <-> Netopia = Impossible
    Ipcop <-> Netopia = Ok

    Je parviens donc à établir un vpn avec Ipcop, mais uniquement en initiant le tunnel côté Ipcop. Si le tunnel tombe par exemple, je n'ai rien trouvé côté Pfsense qui permette de remonter le tunnel (y compris le redémarrage de racoon). J'ai créé une règle dans Pfsense afin de voir passer les trames sur le port 500, et tant que rien n'arrive d'Ipcop, le tunnel ne remonte pas. En revanche, un redémarrage du tunnel côté Ipcop donne un résultat correct immédiatement.

    Côté logs, c'est un peu le désert, et côté Pfsense, et côté Netopia. Néanmoins, les logs du Netopia permettent clairement de voir qu'il arrive des informations concernant ipsec depuis Ipcop mais pas depuis Pfsense. C'est un peu comme si Pfsense ne savait pas initier un tunnel, et le Netopia non plus…

    Bien entendu, Pfsense accède bien au Netopia et inversement (ping notamment). Le port udp 500 et le protocole 50 sont bien ouvert à Pfsense sur le Netopia. Les logs du pare-feu ne me donne rien de bloqué mais me montre bien les arrivées sur le port 500 d'Ipcop (et pas du Netopia),

    Un redémarrage de racoon avec uniquement le profil Ipcop (sans le profil Netopia donc) me donne ceci :

    Apr 21 17:35:28 	racoon: [Self]: INFO: 192.168.170.1[500] used as isakmp port (fd=15)
Apr 21 17:35:28 	racoon: [Self]: INFO: 127.0.0.1[500] used as isakmp port (fd=14)
Apr 21 17:35:28 	racoon: [Self]: INFO: {ip.publique.pfsense}[500] used as isakmp port (fd=13)
Apr 21 17:35:28 	racoon: WARNING: /var/etc/racoon.conf:3: "0660" admin port support not compiled in
Apr 21 17:35:28 	racoon: INFO: unsupported PF_KEY message REGISTER
Apr 21 17:35:28 	racoon: [Self]: INFO: 192.168.170.1[500] used as isakmp port (fd=15)
Apr 21 17:35:28 	racoon: [Self]: INFO: 127.0.0.1[500] used as isakmp port (fd=14)
Apr 21 17:35:28 	racoon: [Self]: INFO: {ip.publique.pfsense}[500] used as isakmp port (fd=13)
Apr 21 17:35:28 	racoon: WARNING: /var/etc/racoon.conf:3: "0660" admin port support not compiled in
Apr 21 17:35:28 	racoon: INFO: Resize address pool from 0 to 255
Apr 21 17:35:28 	racoon: INFO: Reading configuration from "/var/etc/racoon.conf"
Apr 21 17:35:28 	racoon: INFO: @(#)This product linked OpenSSL 0.9.8e 23 Feb 2007 (http://www.openssl.org/)
Apr 21 17:35:28 	racoon: INFO: @(#)ipsec-tools 0.7.1 (http://ipsec-tools.sourceforge.net)

    Le redémarrage avec le profil Netopia en plus donne ceci :

    Apr 21 17:40:00 	racoon: [Self]: INFO: 192.168.170.1[500] used as isakmp port (fd=15)
Apr 21 17:40:00 	racoon: [Self]: INFO: 127.0.0.1[500] used as isakmp port (fd=14)
Apr 21 17:40:00 	racoon: [Self]: INFO: {ip.publique.pfsense}[500] used as isakmp port (fd=13)
Apr 21 17:40:00 	racoon: WARNING: /var/etc/racoon.conf:3: "0660" admin port support not compiled in
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.12.0/24[0] 192.168.170.0/24[0] proto=any dir=in
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.170.0/24[0] 192.168.12.0/24[0] proto=any dir=out
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.2.0/24[0] 192.168.170.0/24[0] proto=any dir=in
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.170.0/24[0] 192.168.2.0/24[0] proto=any dir=out
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.170.1/32[0] 192.168.170.0/24[0] proto=any dir=out
Apr 21 17:40:00 	racoon: ERROR: such policy already exists. anyway replace it: 192.168.170.0/24[0] 192.168.170.1/32[0] proto=any dir=in
Apr 21 17:40:00 	racoon: INFO: unsupported PF_KEY message REGISTER
Apr 21 17:40:00 	racoon: [Self]: INFO: 192.168.170.1[500] used as isakmp port (fd=15)
Apr 21 17:40:00 	racoon: [Self]: INFO: 127.0.0.1[500] used as isakmp port (fd=14)
Apr 21 17:40:00 	racoon: [Self]: INFO: {ip.publique.pfsense}[500] used as isakmp port (fd=13)
Apr 21 17:40:00 	racoon: WARNING: /var/etc/racoon.conf:3: "0660" admin port support not compiled in
Apr 21 17:40:00 	racoon: INFO: Resize address pool from 0 to 255
Apr 21 17:40:00 	racoon: INFO: Reading configuration from "/var/etc/racoon.conf"
Apr 21 17:40:00 	racoon: INFO: @(#)This product linked OpenSSL 0.9.8e 23 Feb 2007 (http://www.openssl.org/)
Apr 21 17:40:00 	racoon: INFO: @(#)ipsec-tools 0.7.1 (http://ipsec-tools.sourceforge.net)

    Voilà. J'espère avoir été suffisamment complet pour vous permettre de m'aider et pas trop long pour réussir à vous emmener jusqu'au bout de ce message. Si quelqu'un à une idée qui pourrait permettre de résoudre ce problème, cela me rendrait un grand service car là, je patine…  ???

    D'avance merci !

    0
  • M

    Incroyable !  ??? ??? ??? Ce matin, le tunnel est ouvert !  ??? ??? ??? Faut-il attendre un certain temps avant de le voir monter ? Combien de temps ?

    En tous les cas, cela ressemble à une bonne nouvelle. Je vais continuer à creuser. Merci de votre aide.  ;D ;D ;D

    0
  • M

    Visiblement, le tunnel ne monte que… lorsqu'il y a du trafic. Tout "simplement"...

    0
  • J

    oui :-)

    Si la SA expire et qu'aucun trafic ne passe alors le tunnel tombe. Au premier paquet renvoyé le tunnel est renégocié.

    0
  • M

    @Juve:

    Si la SA expire et qu'aucun trafic ne passe alors le tunnel tombe. Au premier paquet renvoyé le tunnel est renégocié.

    N'y a-t-il pas moyen de changer ce comportement par défaut ? Avec un ou deux tunnels, ce n'est peut-être pas gênant (quoique), mais avec plusieurs dizaines, voir d'un seul coup d'oeil ceux qui sont tombés (parce qu'ils n'arrivent pas à remonter) est un vrai plus.

    0
  • J

    En fait il y a une option de ping par tunnel pour permettre cela. Dernier champs en bas de la page de config d'un tunnel.

    0
  • M

    Ah oui ! Cela semble très bien fonctionner. C'est parfait ! Merci.

    0

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy