OpenVPN - Port TCP 443 mauvaise performance



  • 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 !! :)



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



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



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



  • 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 !



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



  • 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



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



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



  • 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



  • 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 !



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



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



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



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



  • 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 !



  • 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 ?



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

    Une idée ?



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



  • Un top durant le test :


Log in to reply