Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Problème Question IPSec

    Français
    3
    4
    783
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      Lolight
      last edited by

      Hello la compagnie, je suis de retour avec mes interrogations lié a un problème.

      Milieux Pro / Etudiant

      Mon besoins est d'arriver a joindre un réseaux distant par le biais d'un tunnel IPsec.

      Une description de l'infra en place: D'un côté mon serveur pfSense de l'autre un FW SonicWall.
      Le tunnel part de mon pfSense et arrive sur le SonicWall.

      J'ai dernièrement beaucoup utilisé OpenVPN qui remplis très bien son job mais dans notre cas je suis contrains d'utiliser IPSec.

      J'ai pas tellement d'infos concernant le FW en face mais avant d'en demander ou d'incriminer le FW en face je veut être sur que de mon côté je suis clean, et actuellement je suis sur que j'ai un ou plusieurs soucis.

      Pour info mon pfSens a une patte LAN ou j'ai mes postes, une patte Wan qui sort sur le net, une patte Wan2 avec des vlan taggé. Ou oubliera la Patte avec les Vlan qui n'a rien a voir avec le tunnel et le LAN.

      J'ai plusieurs tunnel VPN actifs, certain en OpenVpn et un tunnel IPSec qui me pose problème.

      Bien que le tunnel soit établis j'ai des soucis de routage (cf mon test de capture de trame) ou NAT (je suppose ).

      Quelques pistes :

      Les Logs :

      
May 20 17:13:49 	charon: 11[NET] received packet: from IPPublicClient [4500] to 192.168.1.14[4500] (84 bytes)
May 20 17:13:49 	charon: 11[ENC] parsed INFORMATIONAL_V1 request 4117391390 [ HASH N(DPD) ]
May 20 17:13:49 	charon: 11[ENC] generating INFORMATIONAL_V1 request 116261344 [ HASH N(DPD_ACK) ]

      Au niveau des adressage le réseau en 192.168.1.14 est la patte Wan de mon pfSense, celle qui est relié a la box internet.
      (La box a bien mon serveur pfSense en DMZ)

      Je me suis documenté sur ce type d'erreur, et a priori ça serais un soucis de définissions de l'adresse du réseau client.
      Adressage que j'ai pris soins de me faire confirmer.
      http://www.thegreenbow.com/support_flow.html?page=12105C&lang=fr

      Donc mon tunnel est bien établis, comme mon but est encore et toujours de faire des ping d'un poste présent dans le LAN pfSense a travers le tunnel IPSec vers le LAN client.
      J'ai alors réalisé un petit test lancé un ping de mon LAN PfSense vers une adresse du réseau client et fais une capture de paquet sur pfSense sur l'interface IPSec.

      Résultat : NADA, nothing, rien. Ce qui me pousse a croire que mon paquet va partout sauf dans mon tunnel.

      J'ai consulté mes Routes, et aucune ne prend en compte le réseau Lan de mon client.
      Seulement, quand on configure un OpenVPN nous avons bien un tunnel avec un adressage IP se qui permet d'aiguiller un paquet dedans, mais IPSec ne fonctionne vraisemblablement pas pareil.

      Je rajouterais que la partie NAT Outbound de mon pfSense est configuré en Manuel et je souhaite que ça reste comme ça.
      J'ai donc rajouté une règle sur l'interface IPSec pour l'adressage de réseau source : 192.168.14.0

      J'ai suivis la documentation pfSense, bien que je n'ai pas tout bien saisis apparemment.
      Ainsi que celle-ci : https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel

      Une de mes principale interrogation est pourquoi nous avons un tunnel apparent sur OpenVPN et pourquoi je n'en vois pas sur IPSec ?

      Mon FW sur l'interface IPSec accepte tout.
      Le tunnel est bien établis.

      Je vous fais un petit schéma dans la soirée Merci, n'hésitez pas si j'ai oublié des infos qui pourrais vous être utile.

      MonSuperSchema.png
      MonSuperSchema.png_thumb

      1 Reply Last reply Reply Quote 0
      • C
        ccnet
        last edited by

        Dans un premier temps des question pour compléter notre information.
        D'où provient la capture de logs ?
        Que donne un tracert / trace route vers le lan de destination ?
        Peut être pouvez vous poster votre configuration IpSec côté Pfsense ? Les logs ipsec côté Pfsense lors de l'établissement du tunnel tant que l'on y est peuvent servir.
        Cela dit le routage et IpSec sont des jeux qui se jouent à deux ou plus. L"autre extrémité peut être impliquée.
        La présence la box en routeur ne m'enchante pas mais si vous dites que le tunnel est correctement monté …

        1 Reply Last reply Reply Quote 0
        • L
          Lolight
          last edited by

          Merci CCnet pour ta réponse.  :)

          @ccnet:

          Dans un premier temps des question pour compléter notre information.
          D'où provient la capture de logs ?

          La partie de log que je vous ai envoyé est celle trouvé dans les log pfSense de la Partie IPSec.
          La partie des log que je vais vous présenter par la suite fera elle aussi partie de pfSense dans la catégorie IPSec.

          @ccnet:

          Que donne un tracert / trace route vers le lan de destination ?

          Un premier traceroute fais sur la machine pfSense en adresse source le LAN.
          192.168.1.1 est l'adresse de la boxe internet qui se situe sur la Patte Wan du pfSense.
          J'ai l'impression que mon ping va se perdre sur internet et qu'une adresse ip public que je ne connais pas me répond (80.10.124.152)

          
 1  192.168.1.1 (192.168.1.1)  1.454 ms  1.094 ms  1.031 ms
 2  80.10.124.152 (80.10.124.152)  2.084 ms !X  2.785 ms !X  1.619 ms !X

          @ccnet:

          Peut être pouvez vous poster votre configuration IpSec côté Pfsense ?

          Oui je la rajoute en pièce jointe a mon post.
          Si tu veut la page complète que la première phase et de la seconde je peux aussi.

          @ccnet:

          Les logs IPSec côté Pfsense lors de l'établissement du tunnel tant que l'on y est peuvent servir.

          J'ai fais une capture et l'établissement du tunnel, je me suis permis de cacher l'ip Public du client.
          Je l'ai mis un peut plus bas dans le poste pour une meilleur lisibilité

          @ccnet:

          Cela dit le routage et IpSec sont des jeux qui se jouent à deux ou plus. L"autre extrémité peut être impliquée.
          La présence la box en routeur ne m'enchante pas mais si vous dites que le tunnel est correctement monté …

          Oui, effectivement, j'aimerais dans un premier temps régler le soucis de mon côté et bien voir que mon ping se dirige vers le tunnel IPSec, se qu'il n'es pas le cas quand j'effectue une capture de paquets.
          Il me semble que si le client n'a pas les route et que moi je les ai, la communication ne fonctionnerais seulement dans mon sens, c'est a dire a mon initiative. Si j'ai bien compris mon ping arriverais sur le SW Client, celui-ci connaîtrais la destination, donc l’enverrais sur le poste Client dans le LAN, ensuite le retour passerais par le chemin emprunté a l’allée.
          Donc si il y a une soucis de routage côté client cela poserais soucis quand lui serais a l'initiative d'un ping ou autre.
          Confirmez vous ?
          Oui il s’établit bien les logs devrais le confirmer, je met un second screen en PJ qui devrais attester de ça.

          Informations remplacée :
          #IPPUBLICCLIENT : Ip public du client, c'est assez parlant.
          #My identifier : Identifiant de mon côté utilisé dans la phase 1 IPSec
          #Peer identifier : Équivalent, identifiant côté client dans la phase 1 IPSec

          
charon: 00[JOB] spawning 16 worker threads
May 21 08:15:41 	ipsec_starter[68744]: charon (68921) started after 40 ms
May 21 08:15:41 	charon: 15[CFG] received stroke: add connection 'con1000'
May 21 08:15:41 	charon: 15[CFG] added configuration 'con1000'
May 21 08:15:41 	charon: 16[CFG] received stroke: route 'con1000'
May 21 08:15:41 	ipsec_starter[68744]: 'con1000' routed
May 21 08:15:41 	ipsec_starter[68744]:
May 21 08:15:42 	charon: 16[KNL] creating acquire job for policy 192.168.1.14/32|/0 === #IPPUBLICCLIENT/32|/0 with reqid {1}
May 21 08:15:42 	charon: 16[IKE] <con1000|1>initiating Main Mode IKE_SA con1000[1] to #IPPUBLICCLIENT
May 21 08:15:42 	charon: 16[IKE] initiating Main Mode IKE_SA con1000[1] to #IPPUBLICCLIENT
May 21 08:15:42 	charon: 16[ENC] generating ID_PROT request 0 [ SA V V V V V V ]
May 21 08:15:42 	charon: 16[NET] sending packet: from 192.168.1.14[500] to #IPPUBLICCLIENT[500] (196 bytes)
May 21 08:15:42 	charon: 14[NET] received packet: from #IPPUBLICCLIENT[500] to 192.168.1.14[500] (112 bytes)
May 21 08:15:42 	charon: 14[ENC] parsed ID_PROT response 0 [ SA V V ]
May 21 08:15:42 	charon: 14[ENC] received unknown vendor ID: 5b:36:2b:c8:20:f6:00:07
May 21 08:15:42 	charon: 14[IKE] <con1000|1>received NAT-T (RFC 3947) vendor ID
May 21 08:15:42 	charon: 14[IKE] received NAT-T (RFC 3947) vendor ID
May 21 08:15:42 	charon: 14[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
May 21 08:15:42 	charon: 14[NET] sending packet: from 192.168.1.14[500] to #IPPUBLICCLIENT[500] (244 bytes)
May 21 08:15:42 	charon: 14[NET] received packet: from #IPPUBLICCLIENT[500] to 192.168.1.14[500] (276 bytes)
May 21 08:15:42 	charon: 14[ENC] parsed ID_PROT response 0 [ KE NAT-D NAT-D No V V V ]
May 21 08:15:42 	charon: 14[ENC] received unknown vendor ID: 40:4b:f4:39:52:2c:a3:f6
May 21 08:15:42 	charon: 14[IKE] <con1000|1>received XAuth vendor ID
May 21 08:15:42 	charon: 14[IKE] received XAuth vendor ID
May 21 08:15:42 	charon: 14[IKE] <con1000|1>received DPD vendor ID
May 21 08:15:42 	charon: 14[IKE] received DPD vendor ID
May 21 08:15:42 	charon: 14[IKE] <con1000|1>local host is behind NAT, sending keep alives
May 21 08:15:42 	charon: 14[IKE] local host is behind NAT, sending keep alives
May 21 08:15:42 	charon: 14[ENC] generating ID_PROT request 0 [ ID HASH ]
May 21 08:15:42 	charon: 14[NET] sending packet: from 192.168.1.14[4500] to #IPPUBLICCLIENT[4500] (84 bytes)
May 21 08:15:42 	charon: 14[NET] received packet: from #IPPUBLICCLIENT[4500] to 192.168.1.14[4500] (100 bytes)
May 21 08:15:42 	charon: 14[ENC] parsed ID_PROT response 0 [ ID HASH N(INITIAL_CONTACT) ]
May 21 08:15:42 	charon: 14[IKE] <con1000|1>IKE_SA con1000[1] established between 192.168.1.14[#My identifier]...IPPUBLICCLIENT[#Peer identifier]
May 21 08:15:42 	charon: 14[IKE] IKE_SA con1000[1] established between 192.168.1.14[#My identifier]...IPPUBLICCLIENT[]
May 21 08:15:42 	charon: 14[IKE] <con1000|1>scheduling reauthentication in 27970s
May 21 08:15:42 	charon: 14[IKE] scheduling reauthentication in 27970s
May 21 08:15:42 	charon: 14[IKE] <con1000|1>maximum IKE_SA lifetime 28510s
May 21 08:15:42 	charon: 14[IKE] maximum IKE_SA lifetime 28510s
May 21 08:15:42 	charon: 14[ENC] generating QUICK_MODE request 2086442243 [ HASH SA No KE ID ID ]
May 21 08:15:42 	charon: 14[NET] sending packet: from 192.168.1.14[4500] to #IPPUBLICCLIENT[4500] (308 bytes)
May 21 08:15:42 	charon: 14[NET] received packet: from #IPPUBLICCLIENT[4500] to 192.168.1.14[4500] (116 bytes)
May 21 08:15:42 	charon: 14[ENC] parsed INFORMATIONAL_V1 request 737251251 [ HASH N(INVAL_ID) ]
May 21 08:15:42 	charon: 14[IKE] <con1000|1>received INVALID_ID_INFORMATION error notify
May 21 08:15:42 	charon: 14[IKE] received INVALID_ID_INFORMATION error notify
May 21 08:15:52 	charon: 14[IKE] <con1000|1>sending DPD request
May 21 08:15:52 	charon: 14[IKE] sending DPD request
May 21 08:15:52 	charon: 14[ENC] generating INFORMATIONAL_V1 request 2492580 [ HASH N(DPD) ]
May 21 08:15:52 	charon: 14[NET] sending packet: from 192.168.1.14[4500] to #IPPUBLICCLIENT[4500] (92 bytes)
May 21 08:15:52 	charon: 14[NET] received packet: from #IPPUBLICCLIENT[4500] to 192.168.1.14[4500] (84 bytes)
May 21 08:15:52 	charon: 14[ENC] parsed INFORMATIONAL_V1 request 261159815 [ HASH N(DPD_ACK) ]</con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1>

          ConfIPsec.png
          ConfIPsec.png_thumb
          TunnelEtablis.png
          TunnelEtablis.png_thumb

          1 Reply Last reply Reply Quote 0
          • C
            chris4916
            last edited by

            80.10.124.152 est un équipement réseau de Orange (probablement ton ISP  ;))

            Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.