Connexion coupée après 3 min

novembre 2013 modifié dans Support technique
Bonjour,

Je suis utilisateur de Frozenway depuis à peu près un an, pour jouer à Battlefield3/4 sur le réseau du campus de Paris-Saclay. Ca marchait bien (bonne connexion, parfois quelques sautes de ping, dans l'ensemble, c'est ok), mais je rencontre depuis peu un problème assez agacant :

-Je me connecte normalement avec Frozenway
-J'arrive à aller en ligne, même à jouer pendant à peu près 3 min
-Puis la connexion se coupe.
Peu importe le protocole ou le serveur FW choisi, ca fait pareil.

J'ai fait des essais de ping :
- pendant les 3 mins initiales, réponse en ~20ms de google
- après, j'ai : "Réponse de *IP passerelle reseau* : impossible de joindre le reseau de destination.

Je précise également que pour se connecter sur le réseau, il faut entrer manuellement son adresse IP, celle de la passerelle et celle des DNS ; il y a également un proxy. Lorsque l'on renseigne ledit proxy dans les options de Frozenway, la connexion se fait parfaitement.


J'en appelle donc à vos connaissances réseaux pour m'aider à y voir clair :
- est ce la passerelle qui bugge ?
- est ce la passerelle qui détecte le trafic Frozenway et le coupe ? Auquel cas, y a t-il moyen de mieux le camoufler ?
- est ce un pb encore plus en amont ?

Merci d'avance !


EDIT : le journal :

FrozenWay version 1.6.5
----------------------------------
Server: premium-03-fr-04
Proxy: 129.104.247.2:8080
Protocol: HTTP
----------------------------------
Sun Nov 24 22:30:55 2013 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013

Sun Nov 24 22:30:55 2013 Control Channel Authentication: using 'D:/Logiciels/FrozenWay 1.6.5/etc/keys/auth.key' as a OpenVPN static key file
Sun Nov 24 22:30:55 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 24 22:30:55 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 24 22:30:55 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Nov 24 22:30:55 2013 Attempting to establish TCP connection with [AF_INET]127.0.0.1:61175
Sun Nov 24 22:30:55 2013 TCP connection established with [AF_INET]127.0.0.1:61175
Sun Nov 24 22:30:55 2013 TCPv4_CLIENT link local: [undef]
Sun Nov 24 22:30:55 2013 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:61175

Sun Nov 24 22:30:55 2013 TLS: Initial packet from [AF_INET]127.0.0.1:61175, sid=3b425e72 c388e1b7
Sun Nov 24 22:30:55 2013 VERIFY OK: depth=1, C=FR, ST=France, L=Paris, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com
Sun Nov 24 22:30:55 2013 VERIFY OK: nsCertType=SERVER
Sun Nov 24 22:30:55 2013 VERIFY OK: depth=0, C=FR, ST=France, O=FrozenWay, OU=FrozenWay, CN=FrozenWay, emailAddress=admin@frozenway.com

Sun Nov 24 22:30:55 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Nov 24 22:30:55 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 24 22:30:55 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Nov 24 22:30:55 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 24 22:30:55 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Nov 24 22:30:55 2013 [FrozenWay] Peer Connection Initiated with [AF_INET]127.0.0.1:61175

Sun Nov 24 22:30:58 2013 SENT CONTROL [FrozenWay]: 'PUSH_REQUEST' (status=1)
Sun Nov 24 22:30:58 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.4.0.1,dhcp-option WINS 10.4.0.1,route 10.4.0.1,topology net30,socket-flags TCP_NODELAY,ifconfig 10.4.2.134 10.4.2.133'
Sun Nov 24 22:30:58 2013 OPTIONS IMPORT: --socket-flags option modified
Sun Nov 24 22:30:58 2013 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 24 22:30:58 2013 OPTIONS IMPORT: route options modified
Sun Nov 24 22:30:58 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 24 22:30:58 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sun Nov 24 22:30:58 2013 open_tun, tt->ipv6=0
Sun Nov 24 22:30:58 2013 TAP-WIN32 device [FrozenWay] opened: \\.\Global\{E06D03F4-E260-4050-99D8-06883F16DB45}.tap
Sun Nov 24 22:30:58 2013 TAP-Windows Driver Version 9.9
Sun Nov 24 22:30:58 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.4.2.134/255.255.255.252 on interface {E06D03F4-E260-4050-99D8-06883F16DB45} [DHCP-serv: 10.4.2.133, lease-time: 31536000]
Sun Nov 24 22:30:58 2013 Successful ARP Flush on interface [19] {E06D03F4-E260-4050-99D8-06883F16DB45}

Sun Nov 24 22:31:03 2013 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Sun Nov 24 22:31:03 2013 C:\Windows\system32\route.exe ADD 10.4.0.1 MASK 255.255.255.255 10.4.2.133
Sun Nov 24 22:31:03 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Sun Nov 24 22:31:03 2013 Route addition via IPAPI succeeded [adaptive]
Sun Nov 24 22:31:03 2013 Initialization Sequence Completed

IPv4 routing table :
0.0.0.0 0.0.0.0 129.104.215.254 129.104.212.28 9999
0.0.0.0 0.0.0.0 10.4.2.133 10.4.2.134 30
10.4.0.1 255.255.255.255 10.4.2.133 10.4.2.134 30
10.4.2.132 255.255.255.252 10.4.2.134 10.4.2.134 286
10.4.2.134 255.255.255.255 10.4.2.134 10.4.2.134 286
10.4.2.135 255.255.255.255 10.4.2.134 10.4.2.134 286
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 306
127.0.0.1 255.255.255.255 127.0.0.1 127.0.0.1 306
127.255.255.255 255.255.255.255 127.0.0.1 127.0.0.1 306
129.104.201.51 255.255.255.255 129.104.215.254 129.104.212.28 20
129.104.201.53 255.255.255.255 129.104.215.254 129.104.212.28 20
129.104.212.0 255.255.252.0 129.104.212.28 129.104.212.28 276
129.104.212.28 255.255.255.255 129.104.212.28 129.104.212.28 276
129.104.215.255 255.255.255.255 129.104.212.28 129.104.212.28 276
129.104.247.2 255.255.255.255 129.104.215.254 129.104.212.28 20
224.0.0.0 240.0.0.0 127.0.0.1 127.0.0.1 306
224.0.0.0 240.0.0.0 129.104.212.28 129.104.212.28 276
224.0.0.0 240.0.0.0 10.4.2.134 10.4.2.134 286
255.255.255.255 255.255.255.255 127.0.0.1 127.0.0.1 306
255.255.255.255 255.255.255.255 129.104.212.28 129.104.212.28 276
255.255.255.255 255.255.255.255 10.4.2.134 10.4.2.134 286

Réponses

  • Salut,

    Est-ce que tu dois garder une page Web ouverte pour garder Internet actif ?

    Il n'y a pas de déconnexion sur le journal, peux tu donner le journal après une déconnexion intempestive (attend que le journal change).
  • novembre 2013 modifié
    En fait Frozenway ne se déconnecte pas, c'est pour ça que le journal ne le montre pas. Dans l'interface du logiciel, il est toujours considéré comme connecté. Seulement, après un certain temps donc, impossible de charger une page web, et la requête ping donne la fameuse réponse "impossible de rejoindre le reseau de destination".

    Autre info : j'ai essayé un autre vpn, que l'on ne citera pas içi :-) Disons simplement qu'il est basé en Angleterre.
    Ils utilisent le soft OpenVPN, qu'ils disent de télécharger içi :
    http://openvpn.net/index.php/access-server/download-openvpn-as-sw/357.html

    En me connectant sur les serveurs qu'ils proposent, port 443 (les autres port ne marchent pas), je n'ai pas ce problème d'expiration de la connexion comme avec Frozenway. (Ceci dit leur serveurs doivent être blindés, et leur ping est bien bien pourri).

    Et pourtant, avec Frozenway en OpenVPN, ça ne marche pas...

    Dernière info : j'ai l'impression que plus je mets de trafic réseau, plus vite ça va couper. Par ex: si je commence à charger des pages web directement après avoir établi la connexion, alors ca plantera très vite. Par contre, si je ne fais que des requêtes pings, alors ca peut mettre 10 min à planter. Peut être un genre de "cap" mis par le proxy ?


    Edit : j'ai compris le sens de ta première question en lisant un autre fil de discussion ; je n'ai pas besoin de garder de fenêtre ouverte pour que ma connexion reste active.
Connectez-vous ou Inscrivez-vous pour répondre.