J'ai actuellement une connexion VPN qui fonctionne bien mais il y a un truc que je ne comprends pas.

J'ai bien renseigné une clé pré-partagée pour l'authentification IKE, mais nulle part on ne ma demandé cette clé lors du paramétrage de mon portable sous W10. Pire, je peux modifier cette clé comme bon me semble, ça ne change rien, la connexion s'établit quand même.

D'où ma question, à quoi peut bien servir cette clé si on peut se connecter sans elle ?

Quand je mets une mauvaise clef sur ma tablette ça ne marche plus chez moi...

Il y a 4 heures, Mic13710 a dit :

mais nulle part on ne ma demandé cette clé lors du paramétrage de mon portable sous W10

Moi j'ai bien l'option (pas testé par contre) :

 

Parce que tu as choisi L2TP/IPSec avec clé pré-partagée ce qui est logique.

Moi j'ai choisi le mode automatique. Et dans ce mode, on ne me demande rien. Une fois renseignés le compte et le mot de passe, le VPN se connecte et se fout royalement de la clé ! Tu peux mettre ce que tu veux dans les paramètres du NAS, ça passe sans problème.

Essaye avec le mode auto, tu devrais toi aussi pouvoir te connecter.

Ce qui me fait poser la question : est-ce que cette clé sert à la sécurisation des échanges ? Parce que là, n'importe qui qui a ton compte et ton mdp peut se connecter à ton réseau. C'est fou ce truc !

il y a 20 minutes, Mic13710 a dit :

Essaye avec le mode auto, tu devrais toi aussi pouvoir te connecter.

Avec le mode auto tu pars du principe que Windows ne va pas se tromper et tu offres la possibilité à n'importe qui en chemin d'intercepter tes identifiants très facilement.

il y a 29 minutes, Mic13710 a dit :

Essaye avec le mode auto, tu devrais toi aussi pouvoir te connecter.

Chez moi ça ne marche pas .

il y a 30 minutes, Mic13710 a dit :

est-ce que cette clé sert à la sécurisation des échanges

Oui, sans cette clef les échanges ne peuvent pas être chiffrés. Si tu arrives à te connecter sans clef ou sans certificat, c'est que tu ne fais pas du L2TP/IPSec. A mon avis tu fais du PPTP.

Si je mets une mauvaise clef pré-partagée, mon poste linux, ma tablette iOS et mon android disent tous la même chose : marche pas - et dans les logs du nas on voit bien l'erreur.

Sous Windows 10, même avec une bonne conf, ça ne marche pas (de manière général L2TP/IPSec n'a jamais marché correctement sous Windows avec un Syno en face, je n'ai jamais cherché pourquoi).

Non, c'est bien du L2TP. C'est le seul serveur que j'ai activé sur le NAS, les ports ouverts sur le routeurs et le NAS ne sont que ceux utilisés par ce protocole, le pare-feu bloque les autres ports VPN et les logs sur le NAS ainsi que dans la liste des connexions sont bien indiqués comme étant en L2TP/IPSec. Je ne vois pas comment je pourrais faire du PPTP dans ces conditions.

Je ne crois pas que la clé IKE soit une clé de cryptage. Elle est indiquée comme étant une clé pré-partagée, ce qui à mon sens signifie qu'elle sert uniquement dans le protocole de connexion, pas forcément dans les transferts de données qui eux sont cryptés avec un algorithme autrement plus sérieux je pense.

Je suis sous W10 et je viens de faire les tests suivants :

j'ai paramétré un VPN avec L2TP/IPSec et clé pré-partagée et effectivement, je n'ai pas réussi à établir une liaison, ce qui confirme bien ce que tu disais à propos de ce protocole et W10. Mais ce qui est étrange, c'est qu'après cet essai, ma liaison en mode automatique (sans IKE) ne fonctionne plus. J'arrête le serveur VPN sur le NAS et je le redémarre, ma liaison auto fonctionne à nouveau. C'est à n'y rien comprendre.

Si tu traces un peu sur le syno (iptables -I INPUT -s <ip public du w10> -j LOG), tu vois quoi comme ports utilisés ?

il y a 17 minutes, Mic13710 a dit :

Je ne crois pas que la clé IKE soit une clé de cryptage

Ce n'est pas une clef de chiffrement à proprement parler, mais c'est utilisé lors de l'échange initial pour identifier les 2 extrémités du tunnel. Si les 2 extrémités du tunnel ne sont pas identifiées correctement, normalement il n'y a pas de négociation du chiffrement et le tunnel IPsec ne monte pas (donc le L2TP encore moins).

Je viens de regarder vite fait l'implémentation de strongswan dans les syno, il accepte le L2TP direct. Ce qui pose une autre question, comment arrives tu à joindre le syno ? Tu fais bien le test depuis l’extérieur de ton lan ?

il y a 25 minutes, Mic13710 a dit :

Mais ce qui est étrange, c'est qu'après cet essai, ma liaison en mode automatique (sans IKE) ne fonctionne plus. J'arrête le serveur VPN sur le NAS et je le redémarre, ma liaison auto fonctionne à nouveau. C'est à n'y rien comprendre.

Comme c'est de l'UDP, il faut pas mal de temps avant que la connexion soit réellement marquée comme expirée. Peut être que si tu avait attendu un peu, ça serait retombé en marche.

A titre d'exemple, quand j'ai testé sur l'ipad, j'ai eu le temps de supprimer la conf et de la recréer avant d'avoir un popup indiquant l'expiration de la connexion, donc un bon moment après le message d'erreur.

@Mic13710

Pour Windows, il faut changer une clef de registre si le serveur VPN est derrière un nat : https://support.microsoft.com/en-us/kb/926179

Je viens de tester ça marche (mets la valeur à 2 et reboot le pc)

Par contre je viens de trouver un soucis avec la psk :

• je mets la bonne clef => ok
• je mets un caractère devant => ko
• je mets un caractères derrière => ça marche toujours !!!

On dirait que pour le syno, si le début de la psk match, c'est bon (à la manière d'un grep)

Il y a 1 heure, Fenrir a dit :

Si tu traces un peu sur le syno (iptables -I INPUT -s <ip public du w10> -j LOG), tu vois quoi comme ports utilisés ?

Je regarderai ça demain (portable arrêté).

Il y a 1 heure, Fenrir a dit :

Ce n'est pas une clef de chiffrement à proprement parler, mais c'est utilisé lors de l'échange initial pour identifier les 2 extrémités du tunnel. Si les 2 extrémités du tunnel ne sont pas identifiées correctement, normalement il n'y a pas de négociation du chiffrement et le tunnel IPsec ne monte pas (donc le L2TP encore moins).

Je viens de regarder vite fait l'implémentation de strongswan dans les syno, il accepte le L2TP direct. Ce qui pose une autre question, comment arrives tu à joindre le syno ? Tu fais bien le test depuis l’extérieur de ton lan ?

On est d'accord sur l'utilisation lors de l'échange initial.

C'est clair que je fonctionne en L2TP direct, sinon il y aurait un sérieux problème. Ce que tu as observé confirme ce que j'ai pu faire.

J'ai fait les tests depuis l'extérieur et depuis mon lan. Mais c'est pareil car mon routeur accepte le loopback. Les deux fonctionnent comme je l'ai décrit.

Il y a 2 heures, Fenrir a dit :

Comme c'est de l'UDP, il faut pas mal de temps avant que la connexion soit réellement marquée comme expirée. Peut être que si tu avait attendu un peu, ça serait retombé en marche.

A titre d'exemple, quand j'ai testé sur l'ipad, j'ai eu le temps de supprimer la conf et de la recréer avant d'avoir un popup indiquant l'expiration de la connexion, donc un bon moment après le message d'erreur.

OK, la prochaine fois j'essayerai d'être plus patient .

Il y a 1 heure, Fenrir a dit :

@Mic13710

Pour Windows, il faut changer une clef de registre si le serveur VPN est derrière un nat : https://support.microsoft.com/en-us/kb/926179

Je viens de tester ça marche (mets la valeur à 2 et reboot le pc)

Par contre je viens de trouver un soucis avec la psk :

• je mets la bonne clef => ok
• je mets un caractère devant => ko
• je mets un caractères derrière => ça marche toujours !!!

On dirait que pour le syno, si le début de la psk match, c'est bon (à la manière d'un grep)

Merci pour l'info. Je ferai ça demain.

il y a 2 minutes, Mic13710 a dit :

Mais c'est pareil car mon routeur accepte le loopback.

Non, ce n'est pas pareil, ça change même beaucoup de chose pour le L2TP qui est un protocole de niveau 2, si tu es dans le même lan tu peux avoir des annonces arp qui passent en direct au lieu de passer par le tunnel IPsec.

à l’instant, Fenrir a dit :

Non, ce n'est pas pareil, ça change même beaucoup de chose pour le L2TP qui est un protocole de niveau 2, si tu es dans le même lan tu peux avoir des annonces arp qui passent en direct au lieu de passer par le tunnel IPsec.

OK, mais ça fonctionne aussi avec le portable connecté via mon smartphone, donc hors lan.

Comme Fenrir j'ai pas ce soucis en l2tp, si la clé pré partagée n'est pas correcte, la connection est refoulée.

Sinon je comprends pas que le vpn soit dans un log un part du centre de journaux, pour ma part j'ai un script qui tourne et m'informe du moindre changement dans le log ce dernier, car à moins d'aller spécifiquement le voir, on a pas de vue...

Il y a 9 heures, Einsteinium a dit :

Comme Fenrir j'ai pas ce soucis en l2tp, si la clé pré partagée n'est pas correcte, la connection est refoulée.

Sinon je comprends pas que le vpn soit dans un log un part du centre de journaux, pour ma part j'ai un script qui tourne et m'informe du moindre changement dans le log ce dernier, car à moins d'aller spécifiquement le voir, on a pas de vue...

Comme je l'ai dit, ma connexion sur mon portable est en automatique. Dans cette configuration, la clé IKE est inutile. Tu peux essayer en créant une connexion VPN avec un type de réseau automatique, l'adresse de ton serveur, ton nom et ton mdp. Dans ce mode, on ne te demande pas de clé IKE et la connexion se fait quand même.

 

Il y a 12 heures, Fenrir a dit :

Si tu traces un peu sur le syno (iptables -I INPUT -s <ip public du w10> -j LOG), tu vois quoi comme ports utilisés ?

PROTO=UDP SPT=48078 DPT=4500 LEN=236
PROTO=UDP SPT=1701 DPT=1701 LEN=177

Ce sont bien des ports L2TP/IPSec (le portable est en wifi sur mon smartphone )

J'ai fait ensuite le rajout de la clé dans le PolicyAgent de la base de registre et effectivement, ça fonctionne avec la clé IKE (ce qui est un net progrès), mais aussi sans (donc pas de changement côté connexion directe). Merci Fenrir pour ce lien où soit dit en passant W10 n'est pas listé dans les "Applies to". C'est du reste totalement incompréhensible qu'elle ne soit pas en natif dans le registre, et surtout que Synology n'y fasse pas allusion dans les paramétrages car après tout c'est le cas de la quasi majorité de ceux qui utilisent Windows avec ce paquet. D'ailleurs toi même tu y avais renoncé d'après ce que tu dis plus haut, et c'est une aubaine que tu ais pu dénicher cette modif.

Il y a 12 heures, Fenrir a dit :

Par contre je viens de trouver un soucis avec la psk :

• je mets la bonne clef => ok
• je mets un caractère devant => ko
• je mets un caractères derrière => ça marche toujours !!!

On dirait que pour le syno, si le début de la psk match, c'est bon (à la manière d'un grep)

Je n'ai pas du tout ce comportement. Si je rajoute un caractère devant ou derrière, impossible de me connecter. Tu es sûr d'avoir validé les changements ? 

 

Ce qui reste quand même un gros point d'interrogation c'est la possibilité de se connecter sans la clé IKE. On peut se demander au fond en quoi c'est une sécurité si on peut la contourner aussi facilement. Je ne vois pas non plus son utilité puisque lors de la connexion, l'authentification suit le protocole MS-CHAP v2 qui est sensé crypter le mot de passe des clients VPN.

Maintenant, si cette clé participe vraiment à la sécurisation de la connexion, il faudrait alors avoir le choix au niveau du serveur (le NAS donc) d'accepter ou non des liaisons sans cette clé. Ça me semble tomber sous le sens.

Bref, je suis dubitatif sur la sécurisation réelle tout au long de la chaine sur ce type de connexion VPN, pourtant donné comme l'un des plus sûrs. Est-ce que j'ai raté quelque chose ?

 

 

Le 12/08/2016 at 09:45, Mic13710 a dit :

D'ailleurs toi même tu y avais renoncé d'après ce que tu dis plus haut, et c'est une aubaine que tu ais pu dénicher cette modif.

J'y avais renoncé car je n'utilise pas le VPN du syno depuis un post Windows . En pratique c'est mon routeur qui fait serveur IPSec et mes clients vpn c'est soit mon portable sous Debian soit mon gsm (android), et dans tous les cas je précise bien avec PSK.

Par contre je suis d'accord que Syno devrait l'indiquer dans ses doc.

Le 12/08/2016 at 09:45, Mic13710 a dit :

Je n'ai pas du tout ce comportement. Si je rajoute un caractère devant ou derrière, impossible de me connecter. Tu es sûr d'avoir validé les changements ? 

Oui, mais d'un autre coté, je viens de refaire une série de test, Windows garde une partie de la connexion ouverte après qu'on ait fait déconnexion, ça doit être pour ça que ça a marché chez moi.

De plus comme c'est de l'UDP, je ne peux pas shooter les sessions.

=>en gros il faut tout relancer (windows et serveur vpn) entre 2 tests

Le 12/08/2016 at 09:45, Mic13710 a dit :

Ce qui reste quand même un gros point d'interrogation c'est la possibilité de se connecter sans la clé IKE. On peut se demander au fond en quoi c'est une sécurité si on peut la contourner aussi facilement. Je ne vois pas non plus son utilité puisque lors de la connexion, l'authentification suit le protocole MS-CHAP v2 qui est sensé crypter le mot de passe des clients VPN.

Maintenant, si cette clé participe vraiment à la sécurisation de la connexion, il faudrait alors avoir le choix au niveau du serveur (le NAS donc) d'accepter ou non des liaisons sans cette clé. Ça me semble tomber sous le sens.

Bref, je suis dubitatif sur la sécurisation réelle tout au long de la chaine sur ce type de connexion VPN, pourtant donné comme l'un des plus sûrs. Est-ce que j'ai raté quelque chose ?

C'est un double problème, le principal fautif est Synology qui a fait de la merde dans ses docs et Microsoft n'a pas fait beaucoup mieux avec son mode auto (mais ça c'est pour nous vendre DirectConnect).

En gros, si on n'est pas un spécialiste L2TP/IPSec on peut se fait avoir facilement, même en étant du métier (j'ai failli louper ton problème) :

Pourtant je pense avoir d'assez bonnes connaissances dans ces domaines (linux/windows/syno/réseau et sécurité), si j'avais pris le temps de réfléchir je t’aurai donné la bonne réponse tout de suite, je n'étais pas loin :

Le 11/08/2016 at 21:09, Fenrir a dit :

Je viens de regarder vite fait l'implémentation de strongswan dans les syno, il accepte le L2TP direct. Ce qui pose une autre question, comment arrives tu à joindre le syno ? Tu fais bien le test depuis l’extérieur de ton lan ?

Le soucis venait bien de là. Tu autorises le L2TP depuis le net.

----------

Bilan des courses pour le mode auto :

• c'est très dangereux car Windows essaye différents proto, dont l2tp, pptp et https
  • si un pirate monte un proxy l2tp, pptp ou https, il peut intercepter les infos de connexion (je n'ai pas dit le login+pass), donc être en mesure de se connecter à notre place
• c'est très lent la première fois pour la même raison (tous les proto y passent)
• s'il a réussi à se connecter via un proto, il ne retente pas les autres même si ça ne marche plus
  • il faut supprimer le profil et le recréer
• si le L2TP depuis Internet est autorisé => ça marche
  • ce n'était pas mon cas, aucune raison d'ouvrir le L2TP puisque je fais de l'IPSec (le L2TP passe dans l'IPSec)
  • par contre niveau sécurité, c'est zéro :
    • la sécurité se limite à login+pass
    • rien n'est chiffré (le L2TP c'est juste un proto authentification)
• si le L2TP depuis Internet n'est pas autorisé => ça ne marche pas
  • on voit bien Windows tenter l'IKE mais comme il ne demande pas la PSK à l'utilisateur on a ça :
  • Aug 12 16:47:13 nas pluto[22236]: packet from xxx.xxx.xxx.xxx:500: sending  notification v2N_INVALID_MESSAGE_ID to xxx.xxx.xxx.xxx:500

=========>ce qu'il faut faire en pratique (j'ai fait quelques tests, ça semble ok, si quelqu'un veut bien se donner la peine de vérifier ...)

• Il faut interdire le L2TP en direct depuis le net (UDP 1701) sur le routeur
• Il faut bien choisir L2TP/IPSec avec clef pré-partagée (psk) sur le client
• Ensuite selon le type de réseau :
  • Si le nas est derrière un routeur
    • sur le routeur :
      • il faut forwarder/autoriser l'IKE (UDP 500) et le NAT-T (UDP 4500) depuis Internet
    • sur le nas :
      • il faut ouvrir les ports 500, 1701 et 4500 depuis Internet
    • sous Windows, il faut créer la valeur de registre suivante : https://support.microsoft.com/en-us/kb/926179
      • Clef : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
      • Valeur : AssumeUDPEncapsulationContextOnSendRule
      • Donnée de la valeur : 2
  • Si votre nas est en IP publique ou que vous voulez faire de l'IPv6 :
    • Il faut autoriser les ports :
      • UDP 500 : IKE
      • UDP 4500 : NAT-T (aucun intérêt en IPv6)
    • Il faut autoriser les protocoles IPSec : attention, il s'agit des numéros de protocole, pas des ports
      • ESP (50)
      • AH (51)

    • iptables -A INPUT -i ethX -p udp --dport 500 -j ACCEPT
      iptables -A INPUT -i ethX -p udp --dport 4500 -j ACCEPT
      iptables -A INPUT -i ethX -p 50 -j ACCEPT
      iptables -A INPUT -i ethX -p 51 -j ACCEPT
      iptables -A INPUT -i ethX -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT
      
      ip6tables -A INPUT -i ethX -p udp --dport 500 -j ACCEPT
      ip6tables -A INPUT -i ethX -p udp --dport 4500 -j ACCEPT
      ip6tables -A INPUT -i ethX -p 50 -j ACCEPT
      ip6tables -A INPUT -i ethX -p 51 -j ACCEPT
      ip6tables -A INPUT -i ethX -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT

    • Pour la dernière règle, on peut s'en sortir en interdisant le port UDP 1701 depuis des ip publiques, mais ceux qui mettent une IP publique sur un nas devraient être en mesure de créer des règles à la main

ps : un jour il faudrait mettre en place un section tuto sur le forum

edit : corrections sur les ports

nb : tuto en cours de rédaction

Modifié le 13 août 20169 a par Fenrir

Oulala, j'ai mal au crane tout d'un coup.

Je veux bien essayer, mais je n'ai plus trop le temps aujourd'hui.

Tu as raison de dire que la toute première connexion en auto est assez longue car il teste tous les protocoles, mais que c'est beaucoup plus rapide après car il ne fait plus le scan, il se connecte directement avec les infos qu'il a eu précédemment. Par contre, si j'arrive bien à me connecter avec l'IKE, c'est d'une lenteur effroyable. Autant la connexion directe fonctionne correctement, celle par IKE est inexploitable. Peut-être que la qualité de la connexion à son importante et celle que j'ai de chez moi sur mon smart n'est pas excellente (pas de 4G).

il y a 49 minutes, Fenrir a dit :

 

ps : un jour il faudrait mettre en place un section tuto sur le forum

Euh, il y en a une ici !

Ah oui bon descriptif pour les novices.

Exact pour les ports, le 500/4500 est suffisant pour le l2tp/IPSec, moi perso j'utilise que les produits de la pomme et il y a pas le choix, c'est du l2tp/IPSec forcé, au moins il y a pas de risque de négligeance.

Pour la connexion IPSec (donc avec IKE), c'est comme le L2TP direct, la première fois c'est lent, mais après plus de soucis (3 sec en 4g).

Pour la section tuto, je n’avais jamais fait attention

Si ma doc marche chez les autres (l'installation réseau chez moi n'est pas vraiment standard), je referais le post en mode tuto.

Ce n'est pas l'établissement de la connexion qui est lent, ça va assez vite. C'est l'utilisation qui est juste impossible. Pour ouvrir un dossier du NAS, en IPSec il mouline pendant plusieurs minutes et finalement n'ouvre rien alors que c'est quelques secondes en mode direct.

Je ferai un test de ton tuto dès que possible pour voir si ça change quelque chose, mais à priori, ça n'a pas l'air de vraiment fonctionner.

Dans tout les cas que Windows face du l2tp simple... le problème il est la déjà.

Il y a 1 heure, Mic13710 a dit :

Pour ouvrir un dossier du NAS, en IPSec il mouline pendant plusieurs minutes et finalement n'ouvre rien

C'est évidemment plus lent qu'en L2TP car il y a la couche de chiffrement en plus et une réduction de la mtu, mais chez moi ça va, 1 ou 2 secondes pour afficher le contenu d'un dossier en partage windows, par contre le transfert d'un fichier de 15mo en CIFS met le nas à genou (??? par compris pourquoi mais je n'ai pas cherché, peut être un soucis de fragmentation de paquets) et Windows fini par interrompre le transfert.

Le même fichier avec filestation ça fonctionne correctement malgré l'up de mon adsl, mais le débit est effectivement plus bas qu'il ne devrait (je pense que la conf openswan du syno n'est pas au top).

edit : en fait c'est mon up qui s'était cassé la gueule ces derniers jours ... les joies de l'adsl longue distance

le débit correspond bien à mon upload adsl

Il y a 1 heure, Einsteinium a dit :

Dans tout les cas que Windows face du l2tp simple... le problème il est la déjà.

Je ne suis pas du même avis, pour moi le soucis est que Synology :

• laisse les utilisateurs faire du L2TP en direct en leur faisant croire que c'est sécurisé (pour rappel, L2TP ne chiffre RIEN)
• demande d'ouvrir le port 1701 dans les docs alors que ce n'est pas nécessaire voir dangereux
• et le met aussi dans les les notification du parefeu/règles auto /...

Que Windows (ou n'importe quel OS) permette aux utilisateurs de faire du L2TP en direct n'a rien de choquant.

Modifié le 12 août 20169 a par Fenrir

Il y a 3 heures, Fenrir a dit :

• Ensuite selon le type de réseau :
  • Si le nas est derrière un routeur
    • sur le routeur :
      • il faut forwarder/autoriser l'IKE (UDP 500) et le NAT-T (UDP 4500) depuis Internet
    • sur le nas :
      • il faut uniquement autoriser le NAT-T (UDP 4500) depuis Internet
        • le UDP 500 est géré autrement
    • sous Windows, il faut créer la valeur de registre suivante : https://support.microsoft.com/en-us/kb/926179
      • Clef : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
      • Valeur : AssumeUDPEncapsulationContextOnSendRule
      • Donnée de la valeur : 2

 

J'ai finalement trouvé le temps de tester la première partie de ton tuto.

J'ai supprimé le 1701 sur le routeur et sur le NAS. J'ai laissé le 500 et le 4500 sur le routeur. Par contre impossible de supprimer le 500 du pare-feu du NAS : 500 et 4500 sont ouverts ensemble ! Ca se résume donc pour le moment a supprimer le 1701 sur le routeur et sur le NAS.

Malheureusement, ça ne fonctionne pas.

Par contre, si je rétabli le 1701 dans le NAS, j'arrive a me connecter mais toujours avec un sacré problème de lenteur. La liaison directe quand à elle ne fonctionne plus puisque le 1701 est fermé sur le routeur.

Finalement, la seule option possible pour les ports c'est de supprimer la redirection du 1701. Ce qui du même coup simplifie grandement le tuto

Ça dépend beaucoup des règles déjà en place, par exemple sur mon syno, j'autorise tous les réseaux locaux mais je ne fais aucune règle sur les interfaces.

Comme tu l'indique, l'important c'est que le 1701 ne soit pas autorisé sur le routeur.

Bonjour,

Ayant le meme problème de lenteurs (une page web pouvait mettre jusqu'à plusieurs minutes à se charger), j'ai désactivé l'option "Exécuter en mode noyau (kernel)" dans l'appli VPN Server de mon NAS (synology).

Depuis, je n'ai plus aucun problème de vitesse. Je ne sais cependant pas à quoi sert cette option...

Quelle est votre version de DSM ?

Sur la 5.2, cette option n'existe pas.

Mon problème de lenteur, ou disons plutôt l'impossibilité d'avoir une connexion digne de ce nom, c'est seulement quand je passe par mon forfait mobile. Free c'est bien et pas cher mais là c'est carrément la loose. Sur une liaison internet normale, ça fonctionne très bien. Ce lundi par exemple, j'ai pu tester les impressions à distance. L'imprimante par défaut a été tout de suite reconnue, l'impression s'est lancée rapidement et les infos (niveaux d'encre, paramètres, liste d'impression) remontaient bien. Bref, rien de différent à ce que je trouve lorsque je suis chez moi.

il y a une heure, Mic13710 a dit :

Sur la 5.2, cette option n'existe pas.

Elle n'existait pas non plus en DSM 6.0 au moment de la rédaction du tuto, elle est apparu lors d'une mise à jour ultérieure mais pas de trace dans la release note (je suppose que c'est dans le bug fix de celle du 18 aout).

Je suis sous la dernière version de DSM.

Par contre, aucune idée de l'utilité de laisser cette option cochée.