OpenVPN 443 avec serveur WEB



  • Bonjour à toutes et à tous,

    Je me permets de venir vers vous, car je rencontre un problème avec ma configuration OpenVPN.

    Je souhaite passer le VPN par le port 443 et sachant que sur ce port un NAT est pour sur un serveur WEB.

    Quand je lance le client celui-ci reset constamment la connexion.

    dbb60e86-9214-4297-924f-ee10308df5e8-image.png

    Ci-dessous ma configuration côté serveur.
    open1.png
    open2.png

    Je vous remercie d'avance.



  • Je suis... comment dire... perplexe.
    Pourquoi vouloir faire ce genre de chose ?
    Pourquoi utiliser SHA1 alors que 2 lignes sous le choix de l'option, l'interface graphique précise que ce n'est pas vraiment sécurisé ?
    Pourquoi choisir un port (443) qui est en conflit avec le NAT vers un serveur web ?

    Je ne sais pas trop quoi répondre à ce genre de demande, si ce n'est que je n'en comprends pas la logique.



  • Je veux passer par le port 443 pour la raison suivante:
    Souvent les ports VPN sont bloqués dans certain lieus. Alors que le port 443 et un port ouvert.

    Par contre je ne comprend pas votre remarque sur "Pourquoi utiliser SHA1 alors que 2 lignes sous le choix de l'option"



  • En effet, 443 est souvent, quand il n'y a pas de proxy 😈 , ouvert mais l'objectif de cette ouverture de port est de permettre un accès à des serveurs de type Web. Vouloir contourner ce principe me semble particulièrement étrange mais bon, acceptons cette contrainte. Dans ce cas, pourquoi ne pas faire tourner ton propre serveur Web sur un autre port. tu n'auras ainsi plus de conflit avec la règle de NAT.
    Je te propose le port 25 pour le serveur web 🤐

    Quand à mon autre remarque, je te renvoie à ta propre copie d'écran qui montre que ton serveur OpenVPN implémente SHA1
    7ff332f5-a579-498a-ae5c-f6ea7a8d141c-image.png



  • D'ailleurs, si tu regardes bien cette page
    https://fr.wikipedia.org/wiki/Liste_de_ports_logiciels
    le port 443 est officiellement attribué à HTTPS par l'IANA.

    mais c'est vrai que c'est tentant de voir que comme ce port est ouvert, pourquoi ne pas essayer de s'infiltrer dans le passage.



  • Je voulais mettre en pratique cette option:
    https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/sharing-a-port-between-openvpn-and-a-web-server.html

    Qui consiste a partager le même port pour deux services.



  • oui mais pour faire ça il ne faut pas que tu ais de NAT vers le serveur Web puisque c'est le serveur VPN qui fait la redirection.



  • Pourtant j'ai bien désactiver le NAT.



  • Choisir 443/tcp pour OpenVPN est vieux ... comme OpenVPN ! Tout administrateur qui installe cette solution a, à un moment, cette idée, et le forum a déjà des fils sur le sujet, il y a quelques années (il eut fallu commencer par chercher) !

    C'est une mauvaise idée ! Ou une fausse bonne idée !

    Premier point, sur le site OpenVPN, on recommande d'utiliser UDP et non TCP car encapsuler du TCP dans du TCP provoque de la congestion et de la baisse de performance. Rappel, OpenVPN a pour défaut 1194/UDP.

    Deuxième point, OpenVPN a prévu une commande 'port-share' qui permet de 'faire le tri' entre paquet (au cas où on insiste). Est ce prévu pour fonctionner sur un firewall qui va NATer le trafic ? Presque sans doute pas, parce que la règle NAT est intangible alors que 'port-share' est une redirection au cas par cas : je reçois tout mais si c'est pas pour moi, je transfère vers l'autre programme.

    Le plus simple, on laisse OpenVPN sur son port naturel, et si, sur un site, on n'a pas de sortie, on demande.

    C'est toujours le même problème : on s'organise pour ne pas demander chez les autres ... alors qu'on ne tolèrerai pas de voir quelqu'un faire ça sur notre réseau !



  • Au surplus, sur les solutions de sécurité un peu évoluées en entreprise, même si vous tentez de passer par le 443/TCP pour monter le tunnel VPN la nature de connexion sera détectée et sera probablement bloquée. L'état chinois fait cela très bien mais pas mal de produits le font très bien, y compris les outils de surveillance et détections d'actions non conformes.



  • J'ai trouvé d'où venait le problème :
    Quand on utilise l'option port-share il faut que le port du serveur web soit autre que 443.
    port-share x.x.x.x 443

    La solution la plus simple est de passer par exemple OpenVPN sur un autre port exemple 25.



  • @ccnet said in OpenVPN 443 avec serveur WEB:

    Au surplus, sur les solutions de sécurité un peu évoluées en entreprise, même si vous tentez de passer par le 443/TCP pour monter le tunnel VPN la nature de connexion sera détectée et sera probablement bloquée. L'état chinois fait cela très bien mais pas mal de produits le font très bien, y compris les outils de surveillance et détections d'actions non conformes.

    Ccnet est déjà intervenu sur des fils au contenu similaire (OpenVPN 443).

    Je ne peux que confirmer : des outils d'inspection peuvent identifier et analyser le flux pour déterminer le type précis de communication, y compris sur port qui n'est pas la référence.

    On peut voir, avec un proxy, et en particulier Squid, si le trafic sur 443 est véritablement du HTTP en mode HTTPS ou seulement du 'CONNECT' (et donc n'importe quoi dedans).

    Exemple : LUFY est un système de transfert de gros fichiers. Or LUFY est prévu pour crypter depuis le PC émetteur (via javascript) de sorte que le serveur ne stocke que des données cryptées (et inexploitables par l'admin). Si vous utilisez HTTP et que le destinataire est derrière un proxy, il faut que CONNECT soit dispo pour HTTP. Gros problème de conf et gros danger.

    (c'est un peu éloigné mais c'est 'connexe').

    OpenVPN sur port 25(/tcp) ? Il y a encore moins de chance que ce port soit ouvert, en particulier sur les box grand public, il est par défaut bridé !



  • quand j'écrivais "port 25" c'était une forme d'humour. Le port 25 est celui réservé à SMTP, de même que le port 80 est pour HTTP et 443 pour HTTPS.
    Plus sérieusement, pour le serveur OpenVPN, 1194 est très bien et si tu persistes à le faire sur le port 443, pourquoi pas, alors il faut faire la redirection vers ton serveur web sur un port libre, à consulter dans les ports non-réservés par IANA. Le lien que je t'ai envoyé donne la liste des ports dynamiques que tu peux sans risque utiliser.
    En dessous de 1024, il y a des ports libres, comme 26 😎



  • Salut,

    Je n'approuve pas démarche de passer outre des restrictions ... mais la solution est simple pour peu qu'il n'y ai qu'une restriction de port ...

    1/ tu configure ton client Ovpn pour sortir sur UDP / 443
    2/ ton serveur Ovpn sur pf écoute classiquement sur UDP / 1194
    3/ tu garde le nat activer sur pf et tu crée 2 règles de nat : TCP/443 vers ton serveur web et UDP/443 vers ovpn avec destination port 1194


Log in to reply