Forum Linux.debian/ubuntu Connection VPN Cisco (vpnc) ubuntu 10.4 freebox

Posté par (page perso) .
Tags : aucun
0
1
déc.
2010

Bonjour les moules,
Je m'arrache les cheveux depuis quleques mois sur ce sujet, qui de plus m'empêche de télétravailler sérieusement. En y répondant, vous me sauverez de la calvitie et m'économiserez des euros de gasoil. Euh, ferez un geste pour la planète. J'expose donc les symptômes:
Pour me connecter au vpn de ma société, j'utilise vpnc:

vpnc version 0.5.3
...
Supported DH-Groups: nopfs dh1 dh2 dh5
Supported Hash-Methods: md5 sha1
Supported Encryptions: null des 3des aes128 aes192 aes256
Supported Auth-Methods: psk psk+xauth hybrid(rsa)

ou le clickodrôme NetworkManager fourni avec ubuntu/gnome. (NetworkManager Applet 0.8).

La connection s'établit et tient 30 à 40 secondes, avant de se blo
Ça bloque également le trafic internet normal.

J'ai pas mal joué avec les différentes configs et je déserspérais de la situation, et puis j'ai essayé d'ailleurs que chez moi (un connection wifi sur un boitier ne passant pas par du xDSL). Et là, miracle, ça marche super.

Je me dis donc que cela doit venir de la freebox (testé derrière d'autres freebox avec le même résultat décevant, mais pas d'autres opérateurs/box). Je me suis assigné une IP fixe et forwardé le port TCP 1723. La box est en mode routeur, j'ai plusieurs machines derrière. J'ai fouillé le grand ternet mais je reste broucouille.

Une idée ? Une piste ? Une solution ? 100 balles ? Un mars ?
  • # pas compris

    Posté par . Évalué à 3.

    pourquoi tu aurais besoin d'une IP fixe sur ton reseau et d'un renvoi de port vers ta machine...

    alors que c'est toi qui essaie de te connecter vers l'exterieur...

    à tout hasard, tu n'aurais pas garder le wifi et le filaire actif en meme temps ?
    du coup ton PC ne sait plus par quelle porte sortir pour aller quelque part ?
    • [^] # Re: pas compris

      Posté par (page perso) . Évalué à 2.

      Je suis une quiche en réseaux, donc j'essaye un peu tous les trucs qui me semblent avoir un rapport avec mon problème. C'est une méthode algorithmique très en pointe appellée le petit bonheur la chance qui donne des résulats presque aussi bons que la méthode la rache (TM). Enfi bref, je viens d'essayer un sudo ifconfig eth2 down, ça ne change rien. À tout hasard, voici le résultat d'un ifconfig:
      eth1      Link encap:Ethernet  HWaddr 00:1f:3c:2c:7d:2c  
                inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
                inet6 addr: fe80::21f:3cff:fe2c:7d2c/64 Scope:Link
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:317806 errors:0 dropped:0 overruns:0 frame:0
                TX packets:249718 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000 
                RX bytes:358326990 (358.3 MB)  TX bytes:37372648 (37.3 MB)
      
      lo        Link encap:Local Loopback  
                inet addr:127.0.0.1  Mask:255.0.0.0
                inet6 addr: ::1/128 Scope:Host
                UP LOOPBACK RUNNING  MTU:16436  Metric:1
                RX packets:50822 errors:0 dropped:0 overruns:0 frame:0
                TX packets:50822 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:0 
                RX bytes:6617608 (6.6 MB)  TX bytes:6617608 (6.6 MB)
      
      virbr0    Link encap:Ethernet  HWaddr c6:31:f8:29:dd:35  
                inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
                inet6 addr: fe80::c431:f8ff:fe29:dd35/64 Scope:Link
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                TX packets:178 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:0 
                RX bytes:0 (0.0 B)  TX bytes:35789 (35.7 KB)
      
      L'interface filaire eth2 est bien désactivée puisqu'elle n'apparaît pas. D'un autre côté je ne vois pas pourquoi il n'y aurait conflit entre le filaire et le wifi que chez moi et pas chez mon collègue, sachant que c'est la même machine, les deux fois par wifi. Et surtout pourquoi ça marche pendant 30 secondes avant de tout bloquer. J'en suis venu à faire des scripts pour découper mes commandes svn par bouts de 35 secondes:
      #!/bin/bash
      sudo vpnc-disconnect
      while true 
      do
              killall -9 svn
              svn cleanup
              find . -name log -exec rm '{}' \;
              sudo vpnc-connect XXX
              $* &
              sleep 35
              sudo vpnc-disconnect
      done
      
      
      Ce qui est particulièrement sale et pas anodin pour svn, en témoigne le nettoyage systématique que je dois faire à chaque tour. Sans parler des services autres que svn dont j'ai besoin. Bref, je sèche.
  • # Manque probablement des ports ...

    Posté par (page perso) . Évalué à 2.

    Il y a certainement le port UDP 500 à gérer pour l'IKE de l'IPSEC.
    • [^] # Re: Manque probablement des ports ...

      Posté par (page perso) . Évalué à 1.

      J'ai lu ça quelque part en effet. Je viens de tester. Pas d'effet. Ma conf freebox :
      IP freebox	 192.168.0.254
      DHCP X
       
      Début DHCP 192.168.0.10 
      Fin DHCP	    192.168.0.50  
       
      Ip DMZ	192.168.0.0  
      Ip du Freeplayer	192.168.0.0  
       
      Réponse au ping	X
      Proxy WOL (Wake On Lan) 0
      UPNP activé	X
       
      Redirections de ports:	
      Port	Protocole	Destination	Port	 
      1723	TCP	192.168.0.1	1723
      500	UDP	192.168.0.1	500
       
      J'ai bon ? sachant que j'ai mis mon laptop en IP fixe 192.169.0.1
  • # DPD?

    Posté par . Évalué à 3.

    As-tu désactivé le DPD?

    Le lien suivant pointe sur un problème ressemblant au tiens et propose une solution :

    http://www.novell.com/communities/node/6352/fixing-vpnc-disc(...)
    • [^] # Re: DPD?

      Posté par (page perso) . Évalué à 1.

      Oui, j'ai déjà ça dans mon vpnc.conf :
      DPD idle timeout (our side) 0
  • # MTU

    Posté par . Évalué à 2.

    Peut-être une histoire de MTU différent entre les réseaux testés.
    Voilà juste une piste comme ça. J'ai déjà eu des bizarreries en utilisant OpenVPN au-dessus d'une connection FreeWifi avec un MTU de 1500 (par défaut). En mettant le mtu à 1460, c'est beaucoup mieux.
    • [^] # Re: MTU

      Posté par (page perso) . Évalué à 1.

      Merci de ta réponse.
      Le MTU était déjà à 1460, je l'ai baissé à 1300, sans effet notable.
      J'ai suivi la procédure suivante, on y voit 9 pings qui passent puis les suivants perdus :


      $sudo vpnc-connect esterel

      Connect Banner:
      | Warning ! You are now connected to XXX Private Network.
      |

      VPNC started in background (pid: 21958)...
      $ sudo ifconfig tun0 mtu 1300
      $ ifconfig tun0
      tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:192.168.20.30 P-t-P:192.168.20.30 Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1300 Metric:1
      RX packets:6 errors:0 dropped:0 overruns:0 frame:0
      TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:500
      RX bytes:858 (858.0 B) TX bytes:542 (542.0 B)

      $ ping fauve
      PING fauve.XXXX (192.168.10.5) 56(84) bytes of data.
      64 bytes from fauve.XXXX (192.168.10.5): icmp_seq=1 ttl=127 time=45.5 ms
      [...]
      64 bytes from fauve.XXXX (192.168.10.5): icmp_seq=9 ttl=127 time=45.6 ms
      ^C
      --- fauve.XXXX ping statistics ---
      15 packets transmitted, 9 received, 40% packet loss, time 14046ms
      rtt min/avg/max/mdev = 45.172/45.779/47.007/0.578 ms
  • # une idée, peut-etre...

    Posté par . Évalué à 3.

    la durée du bail DHCP de ta machine quand elle est derriere une freebox.

    si le bail est tres court, il est renouvelé souvent
    => les routes et les DNS aussi

    il ne faudrait pas la route "au travers du vpn" saute car la carte reseau reprend sa route par defaut en renouvellant son bail.
    • [^] # Re: une idée, peut-etre...

      Posté par (page perso) . Évalué à 2.

      Il y a un bail DHCP même si j'ai une IP fixe ?
      • [^] # Re: une idée, peut-etre...

        Posté par . Évalué à 3.

        une vraie IP fixe, c'est quand tu regles ta machine pour avoir
        telle IP
        tel masque
        telle route

        si c'est le DHCP qui fixe ton IP, oui, y a toujours un bail
        car ta machine va continuer d'interroger le reseau pour verifier qu'elle ne doit pas rendre l'IP
        • [^] # Re: une idée, peut-etre...

          Posté par (page perso) . Évalué à 1.

          Mmmh, ça veut dire que avoir un bail DHCP permanent de suffit pas ? (Pour référence, un exemple de config freebox :
          [http://www.freenews.fr/local/cache-vignettes/L400xH613/4-ea3(...)] )
          Et que dans les paramètres de ma machine, je dois virer DHCP pour le passer en mode manuel ?
          Merci du conseil, j'essaye tout ça ce soir.
          • [^] # Re: une idée, peut-etre...

            Posté par . Évalué à 2.

            le bail permanent, ca fait juste que la freebox ne donne pas cette adresse à n'importe qui (elle reserve cette adresse IP à cette adresse MAC)
            • [^] # Re: une idée, peut-etre...

              Posté par (page perso) . Évalué à 1.

              C'est pas un bail permanent, le serveur fournit la même adresse ip correspondant à l'adresse mac déclarée. Les tentatives de renouvelement du bail commencent à parir de la moitié de la durée de celui-ci.

              Système - Réseau - Sécurité Open Source

  • # Route par défaut

    Posté par . Évalué à 1.

    Vérifie que le NetworkManager a bien ajouté une route statique vers la passerelle VPN (par la commande "route" de la ligne de commande une fois la connexion VPN établie).

    J’ai déjà constaté que l’application d’une nouvelle route peut prendre un peu de temps sous Linux (normalement quelques secondes pas 30 ou 40) pour les connections déjà établies. Si la route statique vers la passerelle VPN n’est pas ajoutée, la connexion vers celle-ci passe par l’ancienne route par défaut, puis après un certain temps par la nouvelle ajoutée par NetworkManager (ce qui ne peut pas marcher car cela revient à faire passer les paquets à destination de la passerelle VPN par la connexion VPN).

    C’est juste une idée comme ça.
    • [^] # Re: Route par défaut

      Posté par (page perso) . Évalué à 1.

      Ah, il semble que mon problème aie quelque chose à voir avec ça. Mes routes avant la connection :
      monnier@kilo:~$ route
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      192.168.0.0     *               255.255.255.0   U     2      0        0 eth1
      192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
      link-local      *               255.255.0.0     U     1000   0        0 eth1
      default         192.168.0.254   0.0.0.0         UG    0      0        0 eth1
      
      Je me connecte :
      monnier@kilo:~$ sudo vpnc-connect esterel
      Connect Banner:
      | Warning ! You are now connected to Esterel Technologies Private Network.
      | 
      VPNC started in background (pid: 5285)...
      
      Nouvelle table de routes, listée instantanément :
      monnier@kilo:~$ route
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      vldomsrv.estere *               255.255.255.255 UH    0      0        0 tun0
      twins.esterel-t *               255.255.255.255 UH    0      0        0 tun0
      reverse.complet 192.168.0.254   255.255.255.255 UGH   0      0        0 eth1
      192.168.3.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.0.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.0.0     *               255.255.255.0   U     2      0        0 eth1
      192.168.10.0    *               255.255.255.0   U     0      0        0 tun0
      192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
      link-local      *               255.255.0.0     U     1000   0        0 eth1
      default         192.168.0.254   0.0.0.0         UG    0      0        0 eth1
      
      J'attends 30 s que la connection tombe:
      monnier@kilo:~$ ping fauve
      PING fauve.esterel-technologies.com (192.168.10.5) 56(84) bytes of data.
      64 bytes from fauve.esterel-technologies.com (192.168.10.5): icmp_seq=1 ttl=127 time=41.7 ms
      [...]
      64 bytes from fauve.esterel-technologies.com (192.168.10.5): icmp_seq=9 ttl=127 time=41.2 ms
      ^C
      --- fauve.esterel-technologies.com ping statistics ---
      13 packets transmitted, 9 received, 30% packet loss, time 12026ms
      rtt min/avg/max/mdev = 41.219/44.031/51.503/3.409 ms
      
      Nouvelle commande route, qui met plusieurs dizaines de secondes à s'afficher ( ! )
      monnier@kilo:~$ route
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      192.168.10.24   *               255.255.255.255 UH    0      0        0 tun0
      192.168.10.28   *               255.255.255.255 UH    0      0        0 tun0
      213.30.139.86   192.168.0.254   255.255.255.255 UGH   0      0        0 eth1
      192.168.3.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.0.0     *               255.255.255.0   U     0      0        0 tun0
      192.168.0.0     *               255.255.255.0   U     2      0        0 eth1
      192.168.10.0    *               255.255.255.0   U     0      0        0 tun0
      192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
      link-local      *               255.255.0.0     U     1000   0        0 eth1
      default         192.168.0.254   0.0.0.0         UG    0      0        0 eth1
      
      Elle semble identique, sauf que les noms de machines ont été résolus en IP. Je ne comprends pas pourquoi elle met systématiquement longtemps à s'afficher une fois que j'ai perdu le lien avec mon VPN.
      • [^] # route -n

        Posté par (page perso) . Évalué à 1.

        Tout est dans le titre

        Système - Réseau - Sécurité Open Source

      • [^] # Re: Route par défaut

        Posté par . Évalué à 1.

        C’est plus tordu que prévu.

        Pour moi, le problème vient de la route suivante :
        192.168.0.0 * 255.255.255.0 U 0 0 0 tun0car elle est prioritaire sur la route (métrique plus faible) :
        192.168.0.0 * 255.255.255.0 U 2 0 0 eth1
        Les paquets à destination de 192.168.0.0/255.255.255.0 passent prioritairement par tun0 (le VPN). Hors ta passerelle par défaut (192.168.0.254) (qui est également la passerelle vers la passerelle VPN (213.30.139.86 ou reverse.complet)) est joignable par cette route. Les paquets à destination de la passerelle VPN sont routés par le VPN (ce qui ne peut pas marcher).

        Immédiatement après l’établissement de la connexion VPN, essaye un truc du genre :route del -net 192.168.0.0 netmask 255.255.255.0 dev tun0Ne maîtrisant pas vraiment NetworkManager, je ne peux pas t’aider pour trouver une solution durable.
        • [^] # Re: Route par défaut

          Posté par . Évalué à 2.

          J’ai répondu un peu trop vite. Si cette route est ajoutée, c’est qu’elle doit servir à quelque chose. En la supprimant, tu risque de ne pas voir toutes les machines situées derrières le VPN.

          Au niveau de la Freebox, essaye de changer ton adresse de réseau pour être 192.168.100.0/255.255.255.0. La Freebox devient alors 192.168.100.254 et ta machine 192.168.100.1.
          Si après cette modification, tu as toujours ton problème de double route, essaye d’ajouter la commande :route add -host 192.168.0.254 dev eth1ou (en fonction de l’adresse de la Freebox) :route add -host 192.168.100.254 dev eth1
          Tu ne verra plus ton réseau local, mais est-ce grave ?
          • [^] # Re: Route par défaut

            Posté par (page perso) . Évalué à 1.

            \o/ ÇA MARCHE !
            Quelle quiche, j'avais pas remarqué les adresses réseau cibles et destinations étaient sur le même sous réseau. Mais les moules ont un oeil de lynx (étrange animal, non ?)

            Merci à tous ceux qui se sont penchés sur le problème. À moi les joies du télétravail devant la cheminée tandis que le reste des Yvelines joue à Holliday On Ice sur les routes enneigées ! Si vous êtes dans la région, et que ça vous dit, ça vaut largement une paire de bières ...
      • [^] # Re: Route par défaut

        Posté par . Évalué à 2.

        Elle semble identique, sauf que les noms de machines ont été résolus en IP. Je ne comprends pas pourquoi elle met systématiquement longtemps à s'afficher une fois que j'ai perdu le lien avec mon VPN.
        C’est l’inverse, les adresses IP ne sont plus résolue (résolution inverse) en nom de domaine, car tu ne peux plus joindre le DNS de ton fournisseur d’accès. Ces tentatives de connexion infructueuses expliquent le temps pris pour afficher les routes.
        • [^] # Un grand classique

          Posté par (page perso) . Évalué à 2.

          Cela ressemble fortement à un clash d'adressage réseau.

          Système - Réseau - Sécurité Open Source

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.