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

    FTP et IpSec

    Scheduled Pinned Locked Moved Français
    6 Posts 2 Posters 4.0k Views
    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.
    • A
      alliass
      last edited by

      Bonjour à tous,

      je rencontre actuellement un problème. J'ai monter un vpn Ipsec entre deux sites.

      Site 192.168.3.1 –--> routeur 222.91.87.226 ---- > Pfsense -> 223.92.86.135 -> site 192.168.1.1

      le FTP se trouve sur l'adresse 192.168.1.1.

      Lorsque je ne crée aucune NAT, je parviens à me connecter à partir de l'adresse 192.168.3.1 sur le serveur ftp 192.168.1.1. Cependant je ne parviens pas a pinger a partir de l'adresse 192.168.3.1 vers 192.168.1.1.

      est ce qu'une personne pourrais me venir en aide.

      cdt.

      1 Reply Last reply Reply Quote 0
      • J
        Juve
        last edited by

        Quelles sont les règles de firewall sur les interfaces IPSEC ? quoi qu'il en soit il ne devrait pas y avoir de NAT entre les deux reseaux privé.

        Que donnent les logs des fitres ? Ouvrez une console SSH sur les firewall et mettez vous en écoute sur les logs du filtre de paquet avec la commande suivante :
        tcpdump -i pflog0 -ttt -n host 192.168.3.1 or host 192.168.1.1

        Refaites vos tests et vérifiez que rien ne se retrouve bloqué (les paquets bloqués apparaitrons sur la console ssh).

        Bonne chance.

        1 Reply Last reply Reply Quote 0
        • A
          alliass
          last edited by

          Merci pour votre réponse.

          Pour votre première question au sujet des rêgles firewall sur l'interface IPSEC :
          J'ai créé deux rêgles :
          Action  : Pass
          Interface : Ipsec
          protocol : Any
          Source : Lan subnet
          destination : 192.168.3.1
          Case coché pour log paquet

          la deuxieme regles est identique sauf que l'adresse 192.168.3.1 est en source et le Lan Subnet en destination.

          "quoi qu'il en soit il ne devrait pas y avoir de NAT entre les deux reseaux " -> Quand je ne créé pas de nat, il m'est impossible de pinger ou d'atteindre les postes avec un utilitaire type pc anywhere

          "Que donnent les logs des fitres ?" -> dans la section Status -> System Log -> Firewall je n'ai pas de log de block. la traces apparente correspondant au FTP sont la suivante :  pass -> ENC0 192.168.3.1:3039 192.168.1.1:21 TCP

          "Ouvrez une console SSH sur les firewall et mettez vous en écoute sur les logs du filtre de paquet avec la commande suivante :
          tcpdump -i pflog0 -ttt -n host 192.168.3.1 or host 192.168.1.1" ->  Voila ce que j'obtiens dans la console SSH

          tcpdump -i pflog0 -ttt -n host 192.168.3.1 or host 192.168.1.1
          tcpdump: WARNING: pflog0: no IPv4 address assigned
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
          000000 IP 192.168.3.1.3152 > 192.168.1.1.21: S 1752956026:1752956026(0) win 64240 <mss 1394,nop,nop,sackok="">l'erreur apparante lors de la tentative de connexion VPN est 500 Invalid port command.

          cdt</mss>

          1 Reply Last reply Reply Quote 0
          • J
            Juve
            last edited by

            Ok, il faut bien penser à une chose lorsqu'on créé les règles, pfsense filtre les paquets entrants c'est à dire qu'il faut faire une règle pour les paquets qui vont entrer par l'interface sur laquelle on travaille, dans le cas du tunnel IPSEC également (interface IPSEC), C'est juste un petit rappel pour que vous validiez bien vos adresses source et destination.

            Avez vous coché "Enable ftp helper" sur l'interface LAN coté 192.168.3.X ?

            1 Reply Last reply Reply Quote 0
            • A
              alliass
              last edited by

              Bonjour, merci du tps que vous m'accordez.

              Je viens de comprendre mon problème. mais j'avoue pour l'instant ne pas savoir comment le résoudre. Peut etre pourrez vous m'aiguiller.

              en réalité j'ai une archi qui ressemble à ça :

              site distant :

              1 poste -> 1 routeur (pas pfsense)

              site local :

              plusieurs poste derriere un routeur autre que pfsense

              je cherche à remplacer celui ci par pfsense.

              mon probleme d'acces est parce que mes deux routeurs (passerelle) ne communique pas ensemble avec mon site distant.

              je m'explique : quand mon site distant se connect en Ipsec sur le pfsense et veux atteindre une machine se trouvant derriere mon autre routeur, il n'y parvient pas. Je suppose qu'il faut faire une route pour y remedier?

              encore merci pour votre aide.

              1 Reply Last reply Reply Quote 0
              • J
                Juve
                last edited by

                Ok, le problème vient du fait que les deux routeur (le routeur X et la pfsense) sont tous les deux branchés donc les postes ont comme route par defaut le routeur X…et les paquets ne reviennent jamais via la pfsense.
                Une solution pour tester serait de faire du source NAT des paquets qui sortent de la pfsense avec son IP LAN, dès lors les paquets provenant de la machine en subnet 192.168.3.x serait réécrit comme provenant de l'adresse de la pfsense dans le reseau 192.168.1.x et seraient donc de proximité pour les postes locaux évitant donc le recours à la route par défaut.

                Pour tester cela, aller dans NAT, créez une regle de NAT sur la carte LAN qui dit source: 192.168.3.0/24 nat avec l'adresse de l'interface (option selectionnée par défaut).

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