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

    [OpenVPN] Site à site - coupures intempestives

    Scheduled Pinned Locked Moved Français
    16 Posts 3 Posters 9.6k 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.
    • Z
      zsunol
      last edited by

      Bonsoir,

      Ton ping est stable entre les 2 sites?

      As-tu essayé de créer une règle qui autorise tcp 3389 ( RDP) , place la en 1er

      zs

      1 Reply Last reply Reply Quote 0
      • B
        bezourox
        last edited by

        Bonjour,

        Le ping est stable.
        L'interface qui est impactée par la règle de filtrage bloquante est TUN0, hors je suis en configuration automatique de mon interface VPN, difficile dans ces conditions de créer une règle de filtrage sur une interface non répertoriée..

        1 Reply Last reply Reply Quote 0
        • Z
          zsunol
          last edited by

          Bonjour,

          J'ai déjà eu un souci au niveau des mtu , ce qui engendrait des comportement curieux.

          zs
          PS: As-tu essayé de monter une maquette en 2 RC3?

          @bezourox:

          Bonjour,

          Le ping est stable.
          L'interface qui est impactée par la règle de filtrage bloquante est TUN0, hors je suis en configuration automatique de mon interface VPN, difficile dans ces conditions de créer une règle de filtrage sur une interface non répertoriée..

          1 Reply Last reply Reply Quote 0
          • B
            bezourox
            last edited by

            Bonjour,

            Non je n'ai pas testé de 2.0RC
            Mais mon but est de valider ce projet pour le passer en production, donc de la RC pour prod, pas tip top :s

            1 Reply Last reply Reply Quote 0
            • Z
              zsunol
              last edited by

              ok dans ce cas essaye de monter un vpn ipsec mobile avec Shrew

              @bezourox:

              Bonjour,

              Non je n'ai pas testé de 2.0RC
              Mais mon but est de valider ce projet pour le passer en production, donc de la RC pour prod, pas tip top :s

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

                Sous pfSense 1.2.3, il n'est pas possible d'avoir des règles pour le flux OpenVPN : la preuve, il n'y a pas d'onglet OpenVPN.
                Sous pfSense 2.0RC, il est possible d'avoir des règles pour le flux OpenVPN ! De plus, pfSense intègre l'administration des certificats.

                Dans un contexte prod, on peut considérer OpenVPN comme certificats de confiance à partir du moment où on gère correctement les certificats (en mettant à jour les CRL par exemple). Mais je n'accorderai de certificats qu'au personnel de l'entreprise : les intervenants extérieurs ne devraient pas utiliser le même accès ! Dans ces cas, on peut se passer de filtrage et rester en 1.2.3.

                Je n'ai pas noté de déconnexion intempestive (dès lors que l'on active le "ping de maintien").

                Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                1 Reply Last reply Reply Quote 0
                • B
                  bezourox
                  last edited by

                  Bonjour,

                  Sous 1.2.3, effectivement pas d'onglet VPN en natif, mais ce n'est pas pour autant qu'on ne peut pas gérer le flux sur le tunel…

                  http://doc.pfsense.org/index.php/OpenVPN_Traffic_Filtering_on_1.2.3

                  En revanche, vous me parlez de ping de maintien à activer, ou se trouve cette option ? Il faut sans doute que je l'active.

                  1 Reply Last reply Reply Quote 0
                  • Z
                    zsunol
                    last edited by

                    Bonjour,

                    Il me semble que cette option ne soit pas dispo, par contre coté client dans la conf tu peux la modifier / activer:

                    # The keepalive directive causes ping-like
                    # messages to be sent back and forth over
                    # the link so that each side knows when
                    # the other side has gone down.
                    # Ping every 10 seconds, assume that remote
                    # peer is down if no ping received during
                    # a 120 second time period.
                    keepalive 10 120
                    

                    @bezourox:

                    Bonjour,

                    Sous 1.2.3, effectivement pas d'onglet VPN en natif, mais ce n'est pas pour autant qu'on ne peut pas gérer le flux sur le tunel…

                    http://doc.pfsense.org/index.php/OpenVPN_Traffic_Filtering_on_1.2.3

                    En revanche, vous me parlez de ping de maintien à activer, ou se trouve cette option ? Il faut sans doute que je l'active.

                    1 Reply Last reply Reply Quote 0
                    • B
                      bezourox
                      last edited by

                      Ok je viens de check mes fichiers de conf et tout me parait OK :

                      Côté serveur :
                      Mon /var/etc/openVPN_server1.conf

                      writepid /var/run/openvpn_server1.pid
                      #user nobody
                      #group nobody
                      daemon
                      keepalive 10 120
                      ping-timer-rem
                      persist-tun
                      persist-key
                      dev tun
                      proto tcp-server
                      cipher BF-CBC
                      up /etc/rc.filter_configure
                      down /etc/rc.filter_configure
                      ifconfig 10.0.7.1 10.0.7.2
                      lport 1193
                      push "dhcp-option DOMAIN blabla.local"
                      push "dhcp-option DNS 10.163.135.14"
                      push "dhcp-option NTP 10.163.135.14"
                      route 10.145.7.0 255.255.255.0
                      secret /var/etc/openvpn_server1.secret
                      comp-lzo
                      persist-remote-ip
                      float
                      –ifconfig 10.0.7.1 10.145.7.4
                      management 127.0.0.1 1193

                      Côté client :
                      Mon  /var/run/openvpn_client1.conf

                      writepid /var/run/openvpn_client1.pid
                      #user nobody
                      #group nobody
                      daemon
                      keepalive 10 120
                      ping-timer-rem
                      persist-tun
                      persist-key
                      dev tun
                      proto tcp-client
                      cipher BF-CBC
                      up /etc/rc.filter_configure
                      down /etc/rc.filter_configure
                      remote 109.2.99.144 1193
                      lport 1195
                      ifconfig 10.145.7.2 10.145.7.1
                      route 10.163.135.0 255.255.255.0
                      secret /var/etc/openvpn_client1.secret
                      comp-lzo
                      –ifconfig 10.145.7.4 10.0.7.1

                      Le problème vient du côté client où je vois les logs me disant que le trafic a été bloqué.
                      On voit ici le résultat de mes 2 tests, un ping et une connexion SSH sur 2 machines.

                      Aug 23 11:38:55 VPN 10.163.135.29:1763 10.145.7.17:22 TCP:S
                        Aug 23 11:39:14 VPN 10.163.135.29 10.145.7.12 ICMP

                      Côté serveur, rien à signaler…

                      Le message d'erreur suivant montre qu'une règle me bloque (la 48)
                      Où trouve t-on ces règles ?

                      The rule that triggered this action is:
                      @48 block drop in log quick all label "Default deny rule

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

                        Il est à conseiller de suivre les indications du site d'OpenVPN et, notamment, du choix d'udp comme protocole transport !

                        NFS, qui est un protocole très sérieux et établi, utilise le transport par … udp !

                        Mais là, dans le cas d'un VPN, il est IMPORTANT de comprendre les motivations du choix udp !
                        Au besoin, lire les explications CALECA ou de FrameIp (de mémoire).

                        Perso, j'avais initialement choisi, pour une entreprise et pour ma première mise en oeuvre d'OpenVPN, d'utiliser 443/tcp (c'est à dire https).
                        C'était une mauvaise bonne idée ...

                        De même, je reste circonspect sur la "bonne idée" de comp-lzo ...

                        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                        1 Reply Last reply Reply Quote 0
                        • B
                          bezourox
                          last edited by

                          Bonjour et merci pour ces infos.
                          Par contre je viens de modifier la config pour utiliser udp sur mon vpn. J'ai modifié en conséquent les règles de filtrage, et pourtant, toujours le même problème…

                          1 Reply Last reply Reply Quote 0
                          • Z
                            zsunol
                            last edited by

                            Bonjour,

                            Question toute bête as-tu essayé de lancer la connexion depuis un autre PC ( xp sans Antivirus avec FW  :-\ )  et une connexion internet différente? ( de chez toi par exemple)

                            zs

                            1 Reply Last reply Reply Quote 0
                            • B
                              bezourox
                              last edited by

                              Bonjour,

                              Je me vois mal ramener chez moi la tour sur laquelle j'ai mis pfsense juste pour tester si ça marche mieux  ;D ;D
                              Et puis je n'y vois pas l'intéret… le problème ne vient pas de l'OS puisque j'ai testé du Windows mais aussi du ssh sur terminal linux.
                              De plus la connexion internet est stable, le ping est continu, et les logs pfsense me parlent d'un blocage par une règle d'interdiction par défaut.
                              Donc pour moi le problème c'est pfsense, pas ma connexion internet ou un client distant du vpn

                              1 Reply Last reply Reply Quote 0
                              • Z
                                zsunol
                                last edited by

                                ok  ;)
                                @bezourox:

                                Bonjour,

                                Je me vois mal ramener chez moi la tour sur laquelle j'ai mis pfsense juste pour tester si ça marche mieux  ;D ;D
                                Et puis je n'y vois pas l'intéret… le problème ne vient pas de l'OS puisque j'ai testé du Windows mais aussi du ssh sur terminal linux.
                                De plus la connexion internet est stable, le ping est continu, et les logs pfsense me parlent d'un blocage par une règle d'interdiction par défaut.
                                Donc pour moi le problème c'est pfsense, pas ma connexion internet ou un client distant du vpn

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bezourox
                                  last edited by

                                  Problème résolu.
                                  Le problème était le mauvais routage sur le poste de test distant.

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