Forum d'entraide de la communauté Freedom-IP VPN
Vous n'êtes pas identifié(e).
Hors ligne
Hello
Personne à une idée pour mon soucis ? N'importe laquelle serait la bienvenue
Hors ligne
Hey
Dans OpenVPN tu as bien renseigné le proxy avec le port, et as-tu essayé de cocher l’authentification ? (prompt for username/password)
Sinon, à mon école, il n'y a que le NL qui marche car il utilise le port 443
Hors ligne
Hors ligne
J'ai déjà essayé de remettre la configuration en Manual Configuration est repassée par l'authentification (prompt for username/passwrod), et comme je le pensais ça ne marche pas. Je pense aussi que le proxy bloque tout ce qui a un rapport à OpenVPN, que ça soit leur site officiel ou le programme
Hors ligne
openvpn utilise un port tcp de toute façon (je veux dire par là que l'école peut pas bloquer openvpn en particulier) donc normalement ils peuvent pas bloquer le port 443 ce qui devrait laisser passer le serveur NL ! Bizarre que ca ne passe pas avec toi. L'ip qu'on peut voir dans ton 1er post est celle de ton proxy n'est-ce pas ? (port 9090)
Mais si je peux te rassurer, ca me l'a fait aussi une fois à l'école, je n'arrivais plus à passer le proxy puis quelque temps après c'était bon ^^
Tu essaies bien avec le serveur NL ? (port 443)
Tiens, tu peux tenter ça sinon :
Ouvre une invite de commande :
telnet 146.191.69.201 9090
CONNECT vpn2.Freedom-IP.com:443 HTTP/1.0
pour voir ce que retourne le proxy Tu peux aussi essayer avant de faire un nslookup vpn2.Freedom-IP.com + ping vpn2.Freedom-IP.com pour voir si le proxy ne bloque pas la résolution DNS et/ou les serveurs Freedom-IP
Dernière modification par LebArmy75 (2012-12-02 22:37:28)
Hors ligne
Merci beaucoup de prendre un peu de temps pour moi déjà (:
Au niveau de tes commandes, cela ne marche pas dans mon cmd, ça me dit que les commandes telnet et CONNECT ne sont pas reconnus
Au niveau du ping vpn2.Freedom-IP.com, il faudrait que je sois déjà connecté au VPN pour que cela marche, or ce n'est pas le cas donc le ping n'est pas retourné, mais je pense que c'est normal non ?
Par contre pour le nslookup, cela me retourne ça :
Serveur : dns-pai.uws.ac.uk
Address: 146.191.241.166
Réponse ne faisant pas autorité :
Nom : vpn2.Freedom-IP.com
Address: 94.23.145.51
Je t'avoue que je sais pas si c'est bon signe mais on dirait (:
Et j'ai peut-être une petite piste, quand je vais chercher mon adresse de proxy sur des sites tel que monip, je me retrouve avec l'IP que je t'ai indiqué, or quand je tape netstat -an, cet IP est nul part. J'ai comme l'impression qu'ils ont peut-être caché la véritable adresse de proxy, est-ce vraiment faisable ? peut-on la récupérer si c'est le cas ? je commence à croire que le problème ne vient pas au niveau de OpenVPN, mais peut-être directement de l'adresse du proxy qu'ils ont peut-être dissimulé ce qui est en soit une bonne chose pour moi, ça n'est peut-être pas fini
Voilà, si tu (ou d'autres lecteurs!) ont d'autres idées, mon PC et mon invite de commande sont tous à vous.
Hors ligne
pkgmgr /iu:"TelnetClient"
Hors ligne
HTTP/1.0 403 URLBlocked
Via: 1.0 146.191.69.201 (McAfee Web Gateway 7.2.0.2.0.13603)
Connection: Close
Content-Type: text/html
Cache-Control: no-cache
Content-Length: 3118
Dernière modification par Iceyes (2012-12-05 03:44:35)
Hors ligne
Bon d'après le retour de la commande, il parait que Mcafee bloque l'URL ... tu pourrais réessayer stp avec l'ip maintenant ?
donc :
telnet 146.191.69.201 9090
CONNECT 94.23.145.51:443 HTTP/1.0
Après utiliser 2 proxys je sis pas si ça marche mais si tu dis que c'est le cas je te crois ^^
Par contre je n'ai pas compris l'histoire de mon-ip.com ? Tu n'obtiens pas l'ip du proxy ? (sinon laquelle) Normalement c'est elle que tu devrais avoir sauf si mcafee gateway agit comme une passerelle comme son nom l'indique et il y met son ip mais je comprends pas alors comment le site arrive à détecter l'ip du proxy dans ce cas ..
Dernière modification par LebArmy75 (2012-12-05 07:04:23)
Hors ligne
Avec l'IP l'URL aussi est bloqué, mais comme je te l'ai dit je suis persuadé qu'il bloque par mots-clés. Il y a pas une liste prédéfini de 50% du web, en particulier pour des sites français (rappel: je suis en Ecosse).
HTTP/1.0 403 URLBlocked
Via: 1.0 146.191.69.201 (McAfee Web Gateway 7.2.0.2.0.13603)
Content-Type: text/html
Cache-Control: no-cache
Content-Length: 3108
Proxy-Connection: Close
Pour l'utilisation de 2 proxys me faudrait juste trouver le moyen d'installer 2 cartes TAP win32 mais je t'avoue que ça je ne sais pas comment faire pour les différencier et en installer 2 qui fonctionnent en parallèle.
Sur mon-ip, dans l'IP personnel j'obtiens l'IP que le proxy renvoie sur internet de moi et dans l'adresse IP du proxy j'obtiens le proxy que je t'ai donné (146.191.69.201). Mais quand je lance netstat -an, l'IP du proxy est nulle part, est-ce normal ? Et sur ton site (whatismyip.com) j'obtiens l'adresse du proxy dans mon adresse IP personnel, et il ne me détecte aucun proxy. Mais je pense que mon-ip.com a raison puisque d'autres sites de détection d'IP me renvoie exactement la même chose que celui-ci.
Cassage de tête hein..
Hors ligne
Quand tu dis l'ip que le proxy renvoie de toi ca veut dire quoi ? T'obtiens quoi comme ip ^^ ?
Je ne savais pas que tu étais en Ecosse ^^ Mais que tu n'obtiennes pas l'ip du proxy dans un netstat doit être normal s'ils font du proxy transparent, en gros le proxy ou le mcafee doit jouer le rôle de passerelle ...
J'ai bien peur que l'ip soit bloqué au niveau de mcafee il n'y a rien que tu puisses faire à part créer ton propre tunnel chez toi ^^
Faudrait voir comment faire passer 2 proxy mais ca me semble assez tirée par les cheveux cette histoire
Je regarderai demain, car je n'ai absolument pas une bonne connexion à ma résidence ...
Dernière modification par LebArmy75 (2012-12-05 20:41:07)
Hors ligne
J'obtiens l'IP que le proxy change pour me faire connaître sur le web : 146.191.179.XXX
Au début, pour obtenir le port du proxy je suis passé par netstat et j'avais l'adresse de mon proxy dans les différentes connexions. Maintenant, vu que ce réseau est tout nouveau et qu'il était totalement buggé et mal foutu au début, il est mis à jour presque chaque semaine et j'ai remarqué que le proxy n'était plus dans mon netstat, et donc que je ne peux plus me connecter aux serveurs...
Crée son tunnel c'est l'utilisation d'un PC (mon PC français je suppose) comme connexion non ? Je serai prêt à effectuer ça mais s'il y a d'autres moyens pour éviter ça je dis pas non..
Dernière modification par Iceyes (2012-12-06 14:04:46)
Hors ligne
Si tu fais un netstat t'as pas forcément l'adresse du proxy. T'as essayé en décochant l'utilisation du proxy sur openvpn ?
Tu peux créer ton tunnel au niveau de ton pc oui bon là FIP servira à rien pour toi ^^ Mais si tu veux tu peux tenter, au moins tu sauras si ça passe Mais essayer sans dire à openvpn de passer par un proxy serait déjà un bon test.
Hors ligne
Oui j'ai déjà essayé en configurant openVPN sans proxy, la plupart des serveurs la connexion n'arrive tout simplement pas à se faire. Mais avec le port 443 (serveur NL1), la connexion se fait mais cela ressort :
Thu Dec 06 18:08:39 2012 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Thu Dec 06 18:08:39 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Dec 06 18:08:39 2012 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Thu Dec 06 18:08:39 2012 LZO compression initialized
Thu Dec 06 18:08:39 2012 Attempting to establish TCP connection with 94.23.145.51:443
Thu Dec 06 18:08:39 2012 TCP connection established with 94.23.145.51:443
Thu Dec 06 18:08:39 2012 TCPv4_CLIENT link local: [undef]
Thu Dec 06 18:08:39 2012 TCPv4_CLIENT link remote: 94.23.145.51:443
Thu Dec 06 18:08:39 2012 WARNING: Bad encapsulated packet length from peer (18516), which must be > 0 and <= 1560 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Thu Dec 06 18:08:39 2012 Connection reset, restarting [0]
Thu Dec 06 18:08:39 2012 SIGUSR1[soft,connection-reset] received, process restarting
Hors ligne
Ah cool ça, donc sans proxy tu peux y aller directement même si ça doit quand même passer par un proxy après je pense ...
Dans le fichier de config NL_Freedomip peux tu essayer en rajoutant cette ligne stp :
tun-mtu 1500 (ou 1400 ou aussi le paramètre mtu-test, faut voir avec les admins du site, mais si ça se trouve le problème ne vient pas de là mais de la gateway qui modifie le paquet mais qui ne tente rien n'a rien ^^)
Sinon par hasard tu ne peux pas prendre la config d'un des pc de l'école et voir s'il y a un proxy par exemple ?...
Dernière modification par LebArmy75 (2012-12-06 20:52:08)
Hors ligne
J'ai essayé mais ça me renvoie exactement le même message d'erreur, peut-être que c'est pas l'exact commande pour modifier le paquet ? Mais on est proche si c'est juste ça qu'il faut faire, on est proche !
Je suis pas sur exactement le même réseau, puisque je suis dans un batiment construit cet été tout le réseau ici est indépendant. Donc pas de config que je puisse un peu étudier !
Hors ligne
D'accord, mais y a pas un autre pc dans ce bâtiment dont tu peux voir la config ?
Car le message d'erreur est étrange ... mcafee modifierait le paquet oO
donc tun-mtu .. ou mtu-test n'ont pas marché ... =/
Faudrait essayer avec un tunnel ssh sur ton pc en France pour voir.
Hors ligne
Non aucun, les seuls sont ceux de la réception et forcément je ne peux absolument pas y accéder..
tun-mtu non et mtu-test me dit que ça marche uniquement avec proto-udp..
Mais ce que je trouve bizarre c'est que FrozenWay se connecte très bien en HTTPS donc le port 443 (tout comme je peux aussi y accéder par Freedom-IP), ce qui veut dire que FrozenWay est bien "réglé" non ? Je pense vraiment qu'il faut juste un petit réglage en plus dans les fichiers configs mais j'en ai aucune idée vu que je connais absolument pas OpenVPN. Peut-être un admin du réseau pourrait me donner un coup de main ?
Je pense que j'essaierai de monter un tunnel ssh quand je rentrerai chez moi, si je dois vraiment en arriver là
Hors ligne
Bonsoir ...
De ce que j'ai put voir des fichiers de configuration OpenVPN de FrozenWay, c'est qu'ils utilisent le protocole UDP qui semblerait passer au travers du PareFeu / Proxy de votre établissement. Malheureusement pour vous, Freedom-IP utilise le protocole TCP qui lui semble être bloqué (ou dénaturé).
Cordialement, David.
Hors ligne
Pour moi ca serait plutôt un blocage des IP de Freedom-IP ..
Ca aurait été cool de tester sur une autre ip mais de ce que je vois, tous les serveurs (NL, IE) ont la même ip ! =/ Faudrait que tu essaies de mettre un serveur openvpn sur ton pc en tcp 443 et voir si tu passes.
Pour FrozenWay étrange qu'il passe car normalement l'UDP est bloqué sur les pare feu sauf pour le DNS ...
Dernière modification par LebArmy75 (2012-12-11 07:12:15)
Hors ligne
Bonjour ...
S'il y avait blocage, cette ligne n'apparaitrait pas :
Thu Dec 06 18:08:39 2012 TCP connection established with 94.23.145.51:443
... et serait plus un "Time Out" lors de la tentative de connexion.
IceEyes, avez vous tentez de vous connecter au serveur VPN IE !?
Cordialement, David.
Hors ligne
Alors en utilisant le proxy j'ai l'habituel :
Tue Dec 11 13:05:55 2012 Attempting to establish TCP connection with 146.191.228.22:9090
Tue Dec 11 13:05:55 2012 TCP connection established with 146.191.228.22:9090
Tue Dec 11 13:05:55 2012 HTTP proxy returned bad status
Et sans utiliser le proxy, j'ai :
Tue Dec 11 13:06:25 2012 Attempting to establish TCP connection with 94.23.145.51:80
Tue Dec 11 13:06:25 2012 TCP connection established with 94.23.145.51:80
Tue Dec 11 13:06:25 2012 TCPv4_CLIENT link local: [undef]
Tue Dec 11 13:06:25 2012 TCPv4_CLIENT link remote: 94.23.145.51:80
Tue Dec 11 13:06:51 2012 Connection reset, restarting [0]
Tue Dec 11 13:06:51 2012 SIGUSR1[soft,connection-reset] received, process restarting
Tue Dec 11 13:06:56 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Dec 11 13:06:56 2012 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Tue Dec 11 13:06:56 2012 Attempting to establish TCP connection with 94.23.145.51:80
Tue Dec 11 13:06:56 2012 TCP connection established with 94.23.145.51:80
Tue Dec 11 13:06:56 2012 TCPv4_CLIENT link local: [undef]
Tue Dec 11 13:06:56 2012 TCPv4_CLIENT link remote: 94.23.145.51:80
Avec une boucle infini. Je vois vraiment pas d'où peut venir exactement le problème.. Ca serait vraiment dommage que ça soit qu'une question de TCP et d'UDP
Hors ligne
Bonsoir ...
Lors de votre test avec le proxy, vous avez tenté de vous connecter à IE ou sur un autre serveur VPN !?
Avez-vous un identifiant et un mot de passe pour l'utilisation du proxy !? Si oui, vous sont-ils demandés !?
Et pour le VPN, votre identifiant et mot de passe vous sont-ils demandés !?
Dans le fichier de configuration de NL ou / et IE pouvez-vous remplacer le "verb 1" par un "verb 3" pour avoir un complément d'information concernant ce qu'il se passe lors de la transaction !?
D'avance, merci.
Cordialement, David.
Hors ligne
Thu Dec 06 18:08:39 2012 TCP connection established with 94.23.145.51:443
Dernière modification par LebArmy75 (2012-12-11 19:53:30)
Hors ligne