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

    [OpenVPN] Site à site - coupures intempestives

    Français
    3
    16
    9.4k
    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.
    • B
      bezourox
      last edited by

      Bonjour,

      Voilà je coince depuis un moment sur la mise en place d'un tunnel VPN avec OpenVPN entre 2 pfsense 1.2.3.

      Coté pfsense serveur : branchée en PPPOE avec adresse ip publique
      Coté pfsense cliente : branchée en IP fixe derrière un routeur

      Le schéma réseau :

      LAN siège    >      WAN Pfsense serveur > Internet >    Routeur FT    > WAN Pfsense cliente > LAN Pfsense cliente
      10.163.135.17            IP PUBLIQUE                          192.168.1.1          192.168.1.100          10.145.7.17

      Depuis un poste de mon réseau central, je pingue en continu un serveur du réseau distant.
      Quand je lance une connexion de bureau à distance sur ce poste, j'arrive à me loguer, mais au bout de 10 secondes environ, la connexion se coupe.

      Même problème lorsque je lance une connexion en SSH sur un serveur.

      Coté log de la pfsense serveur, RAS
      Coté log de la pfsense cliente, je vois ça :

      x  Aug 19 14:58:11  TUN0  10.163.135.29:1085  10.145.7.1:3389  TCP:P

      quand je clique sur la croix rouge, voici le message en popup :

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

      j'ai essayé de configurer l'interface OPT1 pour mon VPN, en désactivant la création automatique des règles sur les VPN et en créant mes propres règles, mais c'est pire, les PC entre les 2 sites ne communiquent plus…

      Je m'en remets donc à vous si vous avez une piste... ça fait maintenant un bon moment que je coince là dessus.

      1 Reply Last reply Reply Quote 0
      • 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.