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

    OpenVPN - Port TCP 443 mauvaise performance

    Français
    4
    20
    5.5k
    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.
    • K
      Krome
      last edited by

      Bonjour à tous !

      Je me permets d'ouvrir un topic car je n'arrive pas à régler mon soucis d'OpenVPN avec PFsense.
      Je m'explique : j'utilise OpenVPN pour me connecter à distance sur le PFsense via le port 443 en TCP habituellement réservé au HTTPS, et ce dans le but de bypasser des firewalls (notamment les wifis publics, écoles etc).

      Jusqu'à présent, j'utilisais une machine virtuelle sous Debian située sur un serveur chez OVH, avec openvpn-server.
      Je pouvais monter à des débits plutôt confortables (20 - 30 Mb/s en faisant un speedtest), ce qui est tout à fait honnête depuis une liaison 30 Mb/s fibre.

      J'ai eu envie de passer ce VPN sous PFSense, avec globalement la même configuration (TCP 443), en virtualisant PFSense sur la même machine OVH (vous me suivez?) que ma debian précédente.

      Mais voilà, en passant via PFSense j'obtient un débit largement inférieur à celui d'auparavant : 1,7 Mb/s maximum.
      J'ai essayé pleins de configurations différentes, notamment activer le fast ip forwarding etc etc… mais en vain.

      Je m'en remets donc à vous pour savoir qu'est-ce qui pourrait me causer une telle chute de débit ? Si je me reconnecte sur ma Debian virtuelle, je retrouve le bon débit.
      Mon environnement virtuel est Proxmox dernière version.

      Merci d'avance pour vos réponses !! :)

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

        J'ai eu envie de passer ce VPN sous PFSense, avec globalement la même configuration (TCP 443), en virtualisant PFSense sur la même machine OVH (vous me suivez?)

        Hélas oui. Le premier problème que je peux imaginer serait une mauvaise configuration réseau de Pfsense dans un environnement virtualisé qui complique singulièrement les choses (en dehors des aspects déplorables en matière de sécurité) sur le plan réseau.
        J'ai un certain nombre de Pfsense physique en production qui ne posent pas de difficulté particulière s'agissant des performances vpn, autant en UDP qu'en TCP 443. Je suis évidement amener à faire la même chose pour les mêmes raisons.

        1 Reply Last reply Reply Quote 0
        • K
          Krome
          last edited by

          Merci de ta réponse  ;)
          Cependant expliques moi quels aspects déplorables en matière de sécurité suis-je confronté ?
          La configuration de Pfsense est une des plus simple : interface WAN avec ip publique, interface LAN avec ip privée sur un bridge virtuel différent bien entendu.
          J'ai essayé en testant différents types de NIC : Intel E1000, VIRTIO (avec les drivers qui vont bien) et les performances ne sont pas améliorées.

          EDIT : par ailleurs je ne vois pas le problème de la virtualisation étant donné que ma machine virtuelle Debian avec openvpn server installé fonctionne très bien à côté, sur le même hyperviseur. Ceci est donc un problème inhérent à Pfsense.

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

            J'ai vu la réponse importante sur la fausse bonne idée du port 443/tcp=https sur le site d'OpenVPN (que l'on a tous eu !).
            Il ne faut pas utiliser du TCP en raison de congestion possible (encapsulage de TCP dans TCP = mauvais).

            Il est à noter que Proxmox fait de la virtualisation soit en conteneur (OpenVZ) soit en paravirtualisation (KVM/QEMU).
            pfSense est en BSD donc en paravirtualisation, alors que Debian peut être en OpenVZ (ce n'est pas précisé).
            NB : Virtio avec BSD, j'aimerai voir …, e1000 me parait plus indiqué !

            On peut virtualiser pfSense sur du Proxmox sans grosse difficulté.
            (J'ai un site pour une petite pme dans ce cas.)

            D'abord la précision sur Debian est nécessaire.
            Ensuite je passerai au traditionnel 1194/udp et reverrai la chose.

            La virtualisation complique la compréhension des phénomènes et peut engager la sécurité puisqu'une couche s'intercale.
            Cette couche peut ou non avoir aussi un impact performance : conteneur vs KVM, conversion interface émulée ...

            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
            • K
              Krome
              last edited by

              Bonsoir jdh,

              J'ai précisé que j'utilisais une machine virtuelle et non pas un conteneur OpenVZ pour ma machine Debian ;)
              Virtio avec BSD fonctionne, testé et approuvé par nombre de personnes.

              En UDP j'ai des débits corrects. Pour rappel je veux faire du TCP 443 pour bypasser des firewalls qui bloqueront l'UDP.
              Ce tunnel n'a nullement pour but de relier des environnements de production. On est pas en milieu entreprise, je fais cela à titre personnel ainsi que pour mes amis qui pourront l'utiliser.

              Je suis d'accord que la virtualisation a des impacts sur les performances, à n'importe quel niveau. Mais ce n'est pas la question. Je fais de la virtualisation depuis des années et je sais tout à fait ce que ça implique.
              Par ailleurs, la VM (KVM) Debian me procure des débits tout à fait convenable pour l'utilisation que je veux, et en TCP 443.

              Je cherche juste à savoir pourquoi j'ai un débit aussi mauvais avec Pfsense, et ainsi résoudre le problème :)
              Merci !

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

                Cependant expliques moi quels aspects déplorables en matière de sécurité suis-je confronté ?

                J'ai souvent développé ce point de vue dans le passé sur de nombreux posts dans ce forum et d'autres. Comme l'ANSSI explique de façon très complète ce qu'il en est je vous joins l'url du document.
                http://www.ssi.gouv.fr/IMG/pdf/2012_05_29_-Guide_1343-_Problematique_de_securite_Virtualisation_3_9.pdf

                Ceci est donc un problème inhérent à Pfsense.

                De façon plus mesurée je dirai : avec Pfsense dans cette configuration, ce qui est différent. Et nous renvoie par là au point développé dans les paragraphes 3.7 et 3.8 du document cité précédemment.

                Cela dit la virtualisation reste une technologie très positive, si bien employée.

                1 Reply Last reply Reply Quote 0
                • K
                  Krome
                  last edited by

                  J'admets totalement ce que vous dites, cependant ça ne m'explique pas pourquoi 2 machines virtuelles situées sur le même hôte ont des comportements différents alors que les configurations sont équivalentes.
                  Je ne cherche pas à avoir des leçons sur la virtualisation, j'en ai déjà eu.
                  Je fais partie d'une équipe qui gère une infra de 700 VM dans une société, je sais donc repérer des problèmes dû à la virtualisation en elle-même.

                  J'aimerais simplement déclencher une réflexion sur mon problème, avec des solutions à tester/appliquer. Pourquoi Pfsense refuserait-il de laisser passer mes paquets rapidement alors qu'une VM sous Debian le fait ? Il devrait avoir le même comportement que cette dernière. Cependant il y a sûrement des subtilités qu'il faut exploiter dans la configuration, c'est ce que je suis venu chercher ici.

                  Si je vous avais dit que Pfsense était hébergé sur une alix par exemple, vous seriez probablement en train de me donner des indices au lieu de me parler de virtu ;)

                  Merci de votre attention

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

                    En v3 Proxmox propose de créer un "VM" ou un "CT".
                    Fondamentalement l'un ou l'autre sont des machines virtuelles.

                    J'ai noté que pfSense virtualisé est très loin d'être performant par rapport à un serveur dédié avec les cartes qui vont bien (type vrai Intel 1000 ou Broadcom). Néanmoins il assure son job mais n'est pas forcément adapté à un flux gros volume.
                    En entreprise, je préconise un serveur dédié.

                    Sur le site OpenVpn (et d'autres genre Frame IP), il faut noter que l'encapsulation d'un flux TCP dans TCP n'est pas recommandé.
                    Je peux imaginer que le noyau BSD est différent d'un noyau Linux et que le même outil (OpenVpn) peut avoir un rendement différent.

                    Il est possible que la compression ait aussi un impact sur la taille des paquets qui sont alors rempli d'où le problème d'encapsulation TCP.

                    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
                    • C
                      ccnet
                      last edited by

                      Est il possible de tester Pfsense sur un serveur matériel dédié ? Cela donnerait un autre éclairage sans doute. Free BSD est connu pour avoir une pile réseau particulièrement rapide mais pas nécessairement dans un environnement virtualisé. Il serait intéressant de lever le doute.

                      1 Reply Last reply Reply Quote 0
                      • K
                        Krome
                        last edited by

                        Bonjour,

                        Merci de vos réponses.
                        Pour tester Pfsense sur du dédié ça sera normalement possible d'ici quelques temps je l'espère.
                        Il n'y aurait pas des paramètres TCP que l'on pourrait tester ? Ou bien des paramètres du OpenVPN comme tun-mtu, mssfix etc etc ?

                        Merci

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

                          Pour la virtualisation de BSD, il faudrait une machine physique ou deux identiques : l'une avec proxmox, l'autre sans, et une install pfsense de part et d'autres.
                          J'ai eu l'occasion de tester : je ne suis presque sûr que pfSense en virtualisé ne tient pas le choc.

                          Pour OpenVPN, je vous recommande de lire les réflexions d'OpenVPN, le pourquoi du comment, … et de migrer à 1194/udp.
                          Je reconnais qu'il est curieux qu'UDP soit là plus performant, mais il faut savoir que NFS utilise udp, que tout n'utilise pas tcp.
                          OpenVPN est un VPN donc il doit nécessairement encapsuler un flux dans un autre, tout comme PPP (PPPoE).
                          Or chacun sait que PPP réduit la taille des paquets du fait de l'encapsulation (mtu 1492 au lieu de 1500).
                          Vous pourrez constater qu'1194/udp est plus performant que 443/tcp.

                          Je ne crois pas à l'utilisation de mtu spécifique même si on peut trouver des exemples de config avec mtu modifié.
                          En général, quand on joue avec le mtu c'est à tort. A considérer --link-mtu.
                          Vous voyez que l'encapsulation joue un grand rôle ...

                          NB : ma première utilisation d'OpenVPN utilisait aussi 443/tcp parce que, moi aussi, j'ai cru à "la bonne idée". J'en suis revenu !

                          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
                          • K
                            Krome
                            last edited by

                            Quand je suis chez moi ou derrière une liaison non firewallée ça ne me pose aucun soucis de faire de l'OpenVPN via UDP/1194, je fais même de l'IpSec d'ailleurs à côté. Ca marche et j'en suis très content.

                            Là ma recherche s'effectue sur du TCP/443 uniquement car je veux pouvoir me connecter à travers les firewalls qui bloquent certaines applications (exemple Skype), je veux pouvoir m'en servir en connexion "de secours", mais avec un débit acceptable.

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

                              Salut,

                              Si je résume, le problème ne survient qu'en TCP ?
                              Si oui, merci de faire une capture réseau (wireshark) lors d'une connexion afin de voir si on a un comportement anormal ( beaucoup de retransmission, ou des demande de resize de transmit Windows). Je pense à un problème de MTU par exemple, retester en abaissant le MTU de la carte WAN  et voir si le débit s'améliore.

                              Si le problème se présente sur les deux type de connexion UDP et TCP, voir si les débits évoluent en changeant l'algo de cryptage utilisé.

                              Enfin voir aussi en désactivant, si ce n'est pas déjà le cas, tous les mécanismes d'offload de checksum (TSO and co).

                              1 Reply Last reply Reply Quote 0
                              • K
                                Krome
                                last edited by

                                Salut,

                                Merci de ta réponse !
                                Effectivement le problème est vraiment visible en TCP, un peu moins en UDP. Par contre c'est une machine hébergée :/ et du coup la capture wireshark est impossible.
                                Je pense aussi à un problème de MTU ou autre dans les tunables !

                                J'ai déjà tenté de changer le cryptage, en vain.
                                Je vais voir pour désactiver les TSO et autres.

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

                                  Tu peux faire une capture dans Diagnostics/Packet Capture, puis la télécharger et l'analyser avec Wireshark.

                                  1 Reply Last reply Reply Quote 0
                                  • K
                                    Krome
                                    last edited by

                                    Hello,

                                    J'ai eu une amélioration incroyable en TCP. J'ai désactivé le tcp.inflight, maintenant j'ai un débit comparable à celui de l'UDP !
                                    Cependant à la maison j'ai du 200 Mb/s en réception et sur le serveur j'ai du 1 Gb/s, en faisant un speedtest je ne dépasse pas les 80 Mb/s en TCP ou UDP.
                                    Est-ce qu'il y aurait des system tunables qui pourraient me brider encore ?

                                    Merci !

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

                                      Le débit doit être un peu inférieur à cause de l'overheead de l'encapsulation, mais pas autant.

                                      Charge CPU de la VM  du serveur quand tu es à 80Mbit/s ?

                                      1 Reply Last reply Reply Quote 0
                                      • K
                                        Krome
                                        last edited by

                                        La VM se porte plutôt bien pendant le test :

                                        Une idée ?

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

                                          40% sur 4 CPU, il faudrait se connecter en SSH et regarder si le process openvpn n'est pas à 100 % sur un cpu

                                          1 Reply Last reply Reply Quote 0
                                          • K
                                            Krome
                                            last edited by

                                            Un top durant le test :

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