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

    OpenVPN - ne pas forcer trafic internet local dans le VPN

    Scheduled Pinned Locked Moved Français
    17 Posts 2 Posters 3.1k 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.
    • N
      Nackir
      last edited by Nackir

      Bonsoir

      sur un serveur dédié pour une utilisation personnelle, j'ai instalé PFSense et monter un VPN site à site pour avoir accès au machines derrière PFSense.
      J'ai configuré comme ceci

      859cdb3a-c466-453b-998e-6f33e62d78c8-image.png

      06a9cd7d-50bc-4989-8a3b-8638bc10225a-image.png

      ce que je ne comprends pas c'est que malgré le fait que "Redirect IPV4 Gateway" soit pas coché, le trafic internet de mon pc (celui que j'utilise pour me connecter au VPN) passe par le VPN.
      Je le vois car l'adresse IP est celle de mon serveur et non celle ce ma box.

      Y a t-il autre chose à faire? malgré qq recherches je ne trouve rien qui me fait penser qu'il y autre à faire.

      voilà, voilà...

      Merci d'avance pour toute suggestion

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

        La présence de 'redirect-gateway def1' côté serveur impose au client de passer par le serveur ... en principe.

        En premier, côté serveur, je vérifierai la config de serveur OpenVPN.
        Le fichier de conf, généré par l'interface, est dans /var/etc/openvpn/server??/openvpn.conf.
        Il ne doit pas y avoir de ligne 'redirect-gateway def1' ... (ou 'push "redirect...')
        En cas, il faut modifier le serveur OpenVPN pour faire disparaitre la ligne ...
        (Je préconise d'assurer avec Status > Services et redémarrage du service 'OpenVPN' !)

        En second, côté client, il faut vérifier les 'route' (avant et après connexion).
        En ligne de commande (peut-être en tant qu'admin), 'route print' et s'intéresser à 'Destination 0.0.0.0'.
        Notez la ligne avant OpenVPN et après permet de voir si le client applique quelque chose !

        Le lien https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway donne quelques idées ... même si le serveur fournit 'redirect-gateway'

        Une autre hypothèse utilise 'pull-filter' côté client ...

        (On peut essayer 'pfsense openvpn .....' mais il vaut mieux essayer sans 'pfsense', ce sera plus général ...)

        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.)

        N 1 Reply Last reply Reply Quote 0
        • N
          Nackir @jdh
          last edited by Nackir

          @jdh
          Bonjour,

          merci pour la réponse et les pistes.

          J'ai vérifié le fichier de configuration openvpn sur PFSense, aucune mention de 'redirect gateway...' ni 'push..'.

          Coté client, j'ai procédé aux vérifications de la table de routage avant et après connexion au VPN, en effet après connexion je me retrouve avec deux lignes 'destination 0.0.0.0' l'une d'elle indiquant bien la passerelle du VPN l'@ IP de l'interface du serveur VPN en tant que passerelle.

          Avant connexion

          # route -n              
          Table de routage IP du noyau
          Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
          0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
          10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
          

          Après connexion

          # route -n
          Table de routage IP du noyau
          Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
          0.0.0.0         10.2.2.1        0.0.0.0         UG    50     0        0 tun0
          0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
          10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
          10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
          10.2.2.0        0.0.0.0         255.255.255.0   U     50     0        0 tun0
          IP publique     10.0.2.2        255.255.255.255 UGH   100    0        0 enp0s3
          192.168.100.0    10.2.2.1        255.255.255.0   UG    50     0        0 tun0
          

          Ceci est valable quelles que soient les options que j'ajoute au client, je pense notamment à

          pull-filter ignore redirect-gateway
          

          Voilà je me suis rendu compte, en consultant le lien suggéré sur openvpn.net que les mots clés choisi dans ma recherche précédant mon post n'était pas si pertinent.
          Je continue...
          Encore une fois merci

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

            (Il faut avoir une approche 'pragmatique' pour comprendre ce qui se passe ...)

            Le démarrage d'OpenVPN Client modifie la route par défaut, alors que le serveur ne l'impose pas. C'est difficile à comprendre !

            Je supprimerai la config existante de serveur OpenVPN, et j'en recréérai une nouvelle (après un reboot de pfSense). Bien sûr avec vérification de la disparition et réapparition du fichier de conf.

            Il va falloir afficher la config serveur ...

            NB : en recréant une config, le certificat DH sera à remplacer ...

            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.)

            N 1 Reply Last reply Reply Quote 0
            • N
              Nackir @jdh
              last edited by

              merci pour l'intérêt porté à ma demande

              @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

              (Il faut avoir une approche 'pragmatique' pour comprendre ce qui se passe ...)

              Le message est passé, je crois

              Avant de tout recommencer, je poste des détails en plus
              Je ne sais pas si cela a de l'intérêt pour mieux comprendre (je ne maîtrise pas encore tous les tenants et aboutissants)
              PFSense est une VM installée sur/dans proxmox

              j'ai un script qui me permet de rediriger le trafic entrant vers PFSense, il est activé au boot par une directive post-up dans le fichier /etc/networtk/interface dans la partie qui correspond à la config de la carte réseau LAN.
              Son contenu est le suivant :

              echo 1 > /proc/sys/net/ipv4/ip_forward
              
              ip route change 192.168.100.0/24 via 10.0.0.2 dev vmbr1
              ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1
              

              vmbr0 porte l'@IP publique (bridge entre l'interface physique du serveur et celle de proxmox)
              vmbr1 est la patte WAN
              vmbr2 la patte LAN
              le VPN est dans le réseau 10.2.2.0/24

              le contenu de la config openvpn:

              cat /var/etc/openvpn/server1/config.ovpn
              
              dev ovpns1
              verb 1
              dev-type tun
              dev-node /dev/tun1
              writepid /var/run/openvpn_server1.pid
              #user nobody
              #group nobody
              script-security 3
              daemon
              keepalive 10 60
              ping-timer-rem
              persist-tun
              persist-key
              proto udp4
              auth SHA256
              up /usr/local/sbin/ovpn-linkup
              down /usr/local/sbin/ovpn-linkdown
              client-connect /usr/local/sbin/openvpn.attributes.sh
              client-disconnect /usr/local/sbin/openvpn.attributes.sh
              local 10.0.0.2
              tls-server
              server 10.2.2.0 255.255.255.0
              client-config-dir /var/etc/openvpn/server1/csc
              plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1194
              tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'host.domain.tld' 1"
              lport 1194
              management /var/etc/openvpn/server1/sock unix
              max-clients 3
              push "route 192.168.100.0 255.255.255.0"
              remote-cert-tls client
              capath /var/etc/openvpn/server1/ca
              cert /var/etc/openvpn/server1/cert 
              key /var/etc/openvpn/server1/key 
              dh /etc/dh-parameters.4096
              tls-auth /var/etc/openvpn/server1/tls-auth 0
              data-ciphers AES-256-GCM:AES-256-CBC
              data-ciphers-fallback AES-256-CBC
              allow-compression no
              persist-remote-ip
              float
              topology subnet
              explicit-exit-notify 1
              inactive 300
              --route-noexec
              

              voilà, voilà...

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

                Tout détail a son importance ! Et c'est le défaut de débutants de ne pas fournir assez d'informations : ça ne doit pas être utile, et non !

                Je note la ligne 'client-config-dir /var/etc/openvpn/server1/csc' : y a-t-il quelque chose dans ce dossier : il peut contenir un dossier par utilisateur et les réglages spécifiques à cet utilisateur, y compris un 'redirect-gateway' ! (C'est un peu lié avec votre choix 'Remote Acess + User Auth'.)

                C'est ce qui est décrit dans 'Client Specific Overrides' : je préconise de n'avoir rien de spécifique par utilisateur, à vérifier ...

                Moi aussi, j'ai un pfSense sur un Proxmox, le tout derrière une box.
                Et la box renvoie le trafic 1194/udp sur l'ip WAN de la VM pfSense.
                MAIS, jamais au grand jamais, Proxmox fait des transferts de flux : ça c'est folie.
                Proxmox n'a PAS à connaitre le réseau OpenVPN de pfSense ! Jamais !

                => Votre architecture est à revoir (et simplifier) !! (Il vous faudra un routeur Wifi dédié car votre réseau interne sera distinct du réseau ethernet et wifi de la box !)

                (NB : je préconise TRES FORTEMENT d'avoir un Proxmox avec 2 interfaces Ethernet, pour chacune d'utiliser des bridges 'vmbrX', et la VM PfSense sera la SEULE VM a disposer de 2 interfaces : l'une sur le bridge WAN = vers la box, l'autre vers le bridge LAN = vers le réseau interne. J'au un ami qui avait un Proxmox mono interface avec un script très compliqué de renvoi : je lui ai fait ajouter une interface et je lui ai montré que tout se simplifiait ensuite !)

                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.)

                N 1 Reply Last reply Reply Quote 0
                • N
                  Nackir @jdh
                  last edited by Nackir

                  @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                  Tout détail a son importance ! Et c'est le défaut de débutants de ne pas fournir assez d'informations : ça ne doit pas être utile, et non !

                  😖
                  Je dirais plutôt que c'est la difficulté à cerner ce qui peut être utile ou non dans mon cas et c'est là que ça va fuser de tous les cotés 😕 la machine est un serveur dédié 😲 donc un seule interface réseau possible...
                  Pour différentes raison, j'ai laissé tomber la config à la maison, 2 onduleurs HS en peu de temps et depuis qq temps des coupures elec incessantes ajouté à cela que le seul opérateur qui m'ait relié à la fibre ne propose pas d'IP fixe

                  @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                  Je note la ligne 'client-config-dir /var/etc/openvpn/server1/csc' : y a-t-il quelque chose dans ce dossier : il peut contenir un dossier par utilisateur et les réglages spécifiques à cet utilisateur, y compris un 'redirect-gateway' ! (C'est un peu lié avec votre choix 'Remote Acess + User Auth'.)

                  le dossier csc est vide donc pas de réglages spécifiques ?

                  @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                  MAIS, jamais au grand jamais, Proxmox fait des transferts de flux : ça c'est folie.
                  Proxmox n'a PAS à connaitre le réseau OpenVPN de pfSense ! Jamais !

                  même dans ce cas de figure, un serveur dédié avec une seule interface réseau?

                  le temps passant et les connaissances étant limitées, je me suis dit que si je n'aboutissait pas, je monterai une VM dans mon PC, VM dédiée à "l'admin de mon serveur" 😥
                  Je vais reprendre la config à zéro d'OpenVPN comme suggéré plus tôt

                  edit: au cas où, la finalité de tout ça est de me permettre d'avoir un serveur nextcloud "protégé" et accessible en tout temps derrière un reverse proxy avec Haproxy...

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

                    Commençons dans l'ordre :

                    • un pfSense doit, nécessairement, avoir 2 interfaces WAN et LAN bien distinctes = un n° de réseau distinct est le minimum
                    • le réseau WAN est entre la box et WAN de pfSense, disons 192.168.1.x/24,
                    • le réseau LAN est entre le LAN de pfSense et les PC ou VM internes, reliés en ethernet ou wifi, disons 192.168.10.x/24

                    Si vous avez un Proxmox avec UNE seule interface ethernet, vous avez créé 2 interfaces (WAN et LAN) bridgées sur cette seule interface. De facto le DHCP de la BOX rentre en conflit avec le DHCP du LAN de pfSense. (En outre, vous devrez avoir un point d'accès wifi sur le réseau LAN !)

                    Un serveur 'tour' comme hôte de virtualisation peut toujours avoir une interface ethernet supplémentaire (et ça coute <15 €). Mon ami a un NUC : on a donc ajouté un adaptateur USB3/Ethernet, et ça fonctionne ...

                    Les redirections sont réalisées au niveau de la Box et renvoient vers l'IP WAN de (la VM) pfSense. Les PC internes voient l'ip LAN de (la VM) pfSense comme leur gateway, ce qui va bien pour un PC connecté par (Open)VPN. Bref AUCUN réglage réseau au niveau de l'hôte (Penser à lui fournir une ip côté LAN !).

                    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.)

                    N 1 Reply Last reply Reply Quote 0
                    • N
                      Nackir @jdh
                      last edited by

                      @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                      Commençons dans l'ordre :

                      • un pfSense doit, nécessairement, avoir 2 interfaces WAN et LAN bien distinctes = un n° de réseau distinct est le minimum
                      • le réseau WAN est entre la box et WAN de pfSense, disons 192.168.1.x/24,
                      • le réseau LAN est entre le LAN de pfSense et les PC ou VM internes, reliés en ethernet ou wifi, disons 192.168.10.x/24

                      Si vous avez un Proxmox avec UNE seule interface ethernet, vous avez créé 2 interfaces (WAN et LAN) bridgées sur cette seule interface. De facto le DHCP de la BOX rentre en conflit avec le DHCP du LAN de pfSense. (En outre, vous devrez avoir un point d'accès wifi sur le réseau LAN !)

                      Un serveur 'tour' comme hôte de virtualisation peut toujours avoir une interface ethernet supplémentaire (et ça coute <15 €). Mon ami a un NUC : on a donc ajouté un adaptateur USB3/Ethernet, et ça fonctionne ...

                      Les redirections sont réalisées au niveau de la Box et renvoient vers l'IP WAN de (la VM) pfSense. Les PC internes voient l'ip LAN de (la VM) pfSense comme leur gateway, ce qui va bien pour un PC connecté par (Open)VPN. Bref AUCUN réglage réseau au niveau de l'hôte (Penser à lui fournir une ip côté LAN !).

                      Je suis d'accord avec tout ça mais quand je disais serveur dédié cela sous entendait loué auprès d'OVH en l’occurrence donc je n'ai pas la main sur le matériel...

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

                        Le serveur est un serveur dédié OVH : voilà une info à fournir dès le début !

                        Avec un serveur dédié chez un hébergeur, il faut

                        • 2 adresses ip : une pour l'hôte de virtualisation (Proxmox), et une pour WAN de pfSense,
                        • on installe avec un Proxmox accédé en ssh avec son adresse ip,
                        • l'interface ethernet du serveur est bridgé sous le nom 'vmbr0' avec l'ip de l'hôte,
                        • une interface bridgée reliée à aucune interface réelle sera 'vmbr1' et sera l'interface des VM internes avec un réseau privé 192.168.x.0/24,
                        • une seule VM aura 2 interfaces : l'une sur 'vmbr0' avec l'ip WAN, l'autre sur 'vmbr1' qui sera la passerelle par défaut des autres VM,
                        • ce qui compte c'est de bien configurer le WAN en statique avec l'ip WAN distincte de l'ip de l'hôte (je ne sais pas comment on fait chez OVH mais je suppose que cela se fait avec une ip failover).

                        Je comprends que, ayant attribué une adresse ip dans le réseau interne à votre hôte, vous ayez besoin d'une route spécifique au réseau des clients VPN.

                        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.)

                        N 1 Reply Last reply Reply Quote 0
                        • N
                          Nackir @jdh
                          last edited by

                          @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                          Le serveur est un serveur dédié OVH : voilà une info à fournir dès le début !

                          Vraiment merci pour la patience et l'aide apportée.

                          @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                          Avec un serveur dédié chez un hébergeur, il faut

                          2 adresses ip : une pour l'hôte de virtualisation (Proxmox), et une pour WAN de pfSense,
                          on installe avec un Proxmox accédé en ssh avec son adresse ip,
                          l'interface ethernet du serveur est bridgé sous le nom 'vmbr0' avec l'ip de l'hôte,
                          une interface bridgée reliée à aucune interface réelle sera 'vmbr1' et sera l'interface des VM internes avec un réseau privé 192.168.x.0/24,
                          une seule VM aura 2 interfaces : l'une sur 'vmbr0' avec l'ip WAN, l'autre sur 'vmbr1' qui sera la passerelle par défaut des autres VM,
                          ce qui compte c'est de bien configurer le WAN en statique avec l'ip WAN distincte de l'ip de l'hôte (je ne sais pas comment on fait chez OVH mais je suppose que cela se fait avec une ip failover).

                          Du coup, je n'ai plus besoin d'aucune des deux règles de routage sur l'hôte (?)

                          Ainsi que l'ensemble de règles iptables sur l'hôte pourrait se résumer à tout bloquer en entrant hormis les ports qui m'intéressent soit celui de SSH et celui d l'interface de proxmox ?
                          Ceci déleste vraiment tout le travail à la VM PFSense.

                          J'ai fait un schéma, histoire de mieux m'imprégner des conseils promulgués, même s'il n'est pas conventionnel, est-il compréhensible et correct?

                          config.png

                          J'ai commandé l'@IP FailOver et je vais la mettre en place pour Proxmox (IP FO), l'@IP déjà fournie sera celle qui sera attribuée à vmbr0 (IP WAN).

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

                            Le schéma est presque correct.

                            'vmbr0' est un bridge sur l'interface physique 'enp3s00'
                            Proxmox a une adresse ip (publique) sur cette interface (et pas sur l'interface physique)
                            La VM pfSense a une interface connectée à ce bridge 'vmbr0', avec une adresse ip (publique) : l'ip FailOver ?

                            NB : il ne faut pas activer le 'ip_forwarding' sur Proxmox, et il faut activer un firewall : ne permettre que ssh sur l'interface 'vmbr0', avec une limitation du nombre de connection !

                            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.)

                            N 1 Reply Last reply Reply Quote 0
                            • N
                              Nackir @jdh
                              last edited by

                              @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                              Le schéma est presque correct.
                              'vmbr0' est un bridge sur l'interface physique 'enp3s00'
                              Proxmox a une adresse ip (publique) sur cette interface (et pas sur l'interface physique)
                              La VM pfSense a une interface connectée à ce bridge 'vmbr0', avec une adresse ip (publique) : l'ip FailOver ?

                              Voilà le schéma modifié

                              config.png

                              J'ai mis en place l'@IP failover sur l'interface WAN de PFSense, avec une VM connectée à vmbr1, j'ai bien accès à internet et je vois bien que cela passe par PFSense (IP failOver)

                              J'ai accès à l'interface de Proxmox ainsi qu'à SSH par l'IP Publique

                              En ajustant la config client du VPN avec la bonne IP (failover), je récupère l'accès et ait accès à l'interface web de PFSense.
                              Cela n'a pas réglé le problème de l'accès à internet qui veut toujours passer par le VPN mais je vais y venir en reprenant la config à zéro comme vous l'avez suggéré.

                              @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                              NB : il ne faut pas activer le 'ip_forwarding' sur Proxmox, et il faut activer un firewall : ne permettre que ssh sur l'interface 'vmbr0', avec une limitation du nombre de connexion !

                              L'ip forwarding est bien désactivé et pour le moment, j'ai juste mis en place le firewall proposé par OVH qui bloque en entrée de son réseau les ports inutiles. J'ai vu une baisse significative des tentatives de connexion en regardant les logs de fail2ban. La config du firewall sur l'hôte est en cours...

                              Encore une fois merci, je ressens une grande satisfaction (d'avoir compris vos directives) même si cela est basique pour un grand nombre...

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

                                Je pense qu'il faut regarder, au niveau du Proxmox, les règles de firewall !
                                Côté public entrant (=vmbr0), seul ssh doit être ouvert mais aussi limité

                                'iptables ---state new -limit' permet de limiter le nombre de sessions (initiales) ssh à un nombre à définir par secondes, minutes : par exemple 6 sessions ssh par minute (soit 1 tout les 10 secondes) est un bon moyen de limiter les effets d'une attaque 'brut force'.

                                (Voire utiliser du 'port knocking' ... exemple https://www.linuxbabe.com/security/secure-ssh-service-port-knocking-debian-ubuntu NB : à essayer sur une autre machine avant d'appliquer à Proxmox !)

                                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.)

                                N 1 Reply Last reply Reply Quote 0
                                • N
                                  Nackir @jdh
                                  last edited by Nackir

                                  @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                                  Je pense qu'il faut regarder, au niveau du Proxmox, les règles de firewall !
                                  Côté public entrant (=vmbr0), seul ssh doit être ouvert mais aussi limité

                                  Faisant de la sorte je vais me bloquer l'accès à l'interface web de Proxmox (?)
                                  Ce que j'en ai compris, Proxmox n'a qu'une IP qui est l'ip publique donc je ne vois pas comment faire dans cette nouvelle configuration pour y accéder si le port est fermé.

                                  @jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

                                  (Voire utiliser du 'port knocking' ... exemple https://www.linuxbabe.com/security/secure-ssh-service-port-knocking-debian-ubuntu NB : à essayer sur une autre machine avant d'appliquer à Proxmox !)

                                  Merci pour la ressource, c'est en effet intéressant. Du coup je me dis que c'est peut-être la solution à ma précédente interrogation pour accéder à l'interface web de proxmox.

                                  Avec cette configuration (2 adresses IP) je me rend compte à l'usage que je n'ai plus de demande de vérification que je ne suis pas un robot lorsque je me connecte à divers sites même une simple recherche google par exemple...

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

                                    Le proxmox devrait être

                                    • accessible en ssh depuis l'extérieur (et depuis le VPN),
                                    • administrable en web (sur le port 8006/tcp) depuis le VPN (et pas depuis l'extérieur).

                                    En sus, le port knocking permet d'éviter franchement les attaques brut-force (au contraire de le limiter avec '--limit' : avec --limit le port est ouvert en permanence).

                                    (L'article indiqué est le premier que je trouve à être très complet sur le sujet ... car le port knocking est une technique assez ancienne.)

                                    NB : si la VM pfSense est tombée et que le VPN ne fonctionne pas, il est possible en ssh de redémarrer la VM en ligne de commande !

                                    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.)

                                    N 1 Reply Last reply Reply Quote 0
                                    • N
                                      Nackir @jdh
                                      last edited by Nackir

                                      @jdh

                                      En attendant de mieux maîtriser la situation, j'ai mis en place le pare-feu empêchant toute connexion et je gère l'ouverture des accès avec le KVM IP.
                                      Une fois arrivé à ce point, je me lancerai dans le port-knocking.

                                      Dans toutes mes tentatives de bloquer l'accès au port 8006 depuis internet et le permettre depuis le VPN, je me retrouve bloqué dehors.

                                      J'ai refait la config d'openVPN en m'assurant que le fichier de conf ne soit plus présent après un reboot de la VM, rien n'y fait... le trafic internet passe toujours par la le VPN.
                                      Sur un autre serveur dédié hébergé, j'ai eu le même problème...

                                      Je vais reprendre l'installation de ce dernier avec les indications que m'avez données, une seule interface réseau physique et 2 adresses IP. Il me servira de "labo"...

                                      Merci du temps que vous avez accordé à me fournir les éléments qui m'ont permis d'avancer.
                                      je reviendrai poster les résultats de mes tests

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