Skip navigation
Cisco Learning Home > Connections > Recursos Educativos (Español) > Discussions

_Communities

6475 Views 6 Replies Latest reply: Dec 3, 2009 2:54 AM by Paul Stewart - CCIE Security, CCSI RSS

Currently Being Moderated

Problema con VPN Site-to-Site y Tunnel GRE

Nov 27, 2009 9:03 AM

Juan Manuel Rodriguez 3 posts since
Aug 8, 2009

Hola a todos, les describo el problema:

 

Tengo dos sitios conectados como se muestra en el archivo adjunto. Los equipos son routers 2801 los cuales tienen habilitado EIGRP a traves de los tuneles de IPSEC (INTERNET) y GRE (enlace dedicado punto a punto). He realizado pruebas de conectividad (ping) desde la red 192.168.4.0 hacia las demas redes remotas (192.168.1.0, 192.168.3.0, etc) y funciona correctamente al igual que el si realizo ping por nombre. Existe un DNS Server (Win 2003) en la red 192.168.3.0 y todas las workstations (maquinas de usuario) resuelven dicho servidor sin problemas con  el nslookup, pero no puedo agregar una maquina que esta en la red 192.168.4.0 al dominio. Al realizar un Remote Desktop desde un workstation (Win XP) de la red .4 hacia un server en la red .3(Win 2003) nunca aparece la ventana de autenticacion, sucede igual si hago el Remote Desktop desde una maquina en la red .3 hacia un server en la red .4, sin embargo si realizo un Remote Desktop desde una workstation en .4 hacia un workstation en .3 el trafico todo funciona correctamente. Primero pense que podria ser un problema de Active Directory o de Dominio pero cuando elimino los routers 2801 de la red y utilizo solo el enlace dedicado (solicitandole al ISP que enrute las redes) todo funciona correctamente, con esto me refiero a que sin los routers 2801 puedo agregar maquinas al dominio y y puedo hacer cualquier tipo de Remote Desktop.

 

Espero que me puedan ayudar.

Attachments:
  • Paul Stewart  -  CCIE Security, CCSI 6,989 posts since
    Jul 18, 2008

    Lo siento, pero yo no hablo español. Así que pido disculpas si la traducción no es exacta.

    Mi impresión inicial es que hay un descubrimiento de ruta MTU problema en alguna parte (pmtud). Si desea probar mi teoría, la caída de los TCP MSS en algún lugar del camino, colocando el siguiente comando en una interfaz, tal vez la interfaz de túnel (ip tcp adjust-mss 1200). Eso es un poco extremista, pero si mi pensar que puede permitir RDP de trabajo. Si es así, se aseguraría de que no hay comandos como "IP inalcanzable" que se enfrentan a su red interna. Las cosas pueden ser más complicado dependiendo del lugar donde las restricciones son MTU. Basado en el diagrama, creo que la restricción de MTU sería en los paquetes de salir de su 2800 hacia el proveedor de servicios. Si el 2800 se están produciendo ICMP inalcanzable, asegúrese de que los paquetes ICMP no se filtra antes de llegar a los anfitriones de punto final. Espero que esto ayude.

  • Esteban Quiros 6 posts since
    May 27, 2009

    Hola Manual.

     

    En realidad cuando se trata de un GRE over IPSEC o cualquier site-to-site tunnel las dos redes pueden ser perfectamente parte del mismo dominio, incluso si asi lo deseo los usuarios de la red 3.0 pueden resolver nombres y ser parte del dominio del domain controller en 4.0, entiendo que no recibe ventana de authentication entonces me preocupa el hecho que no haya connectividad, primero tratemos de hacerle ping al servidor por IP, luego por nombre y por ultimo el nombre sin el FQDN, si esto funciona puede ser simplemente el puerto 3389 siendo bloqueado en algun despositivo a lo largo de la red.

     

    Por ultimo como sugirio Paul en su ultima nota, reducir el TCP MSS en la Interface que comunica al otro Router, el comando se aplica dentro de la interface y sugiero primero tratar con 1250, y con 1200 si asi es posible, espero que este correo le sea de ayuda si aun tiene problemas no se moleste en preguntar

  • Paul Stewart  -  CCIE Security, CCSI 6,989 posts since
    Jul 18, 2008
    Currently Being Moderated
    4. Nov 30, 2009 2:26 PM (in response to Esteban Quiros)
    Re: Problema con VPN Site-to-Site y Tunnel GRE

    My initial impression is that there is a path MTU discovery problem somewhere (pmtud). To test my theory, I would adjust the TCP MSS somewhere in the path.  To do so place the command (ip tcp adjust-mss 1200) on an interface in the path, perhaps the tunnel interface . That's a bit extreme, but if I think that may allow RDP working. If so, would ensure that no commands like "IP unreachable" facing your internal network. This can prevent IP Unreachables that are necessary when IP Packets get to lowered MTU areas of your network.  So inward facing interfaces must be able to generat unreachables for MTU Discover to work correctly.  Things can get complicated depending on where the constraints are with MTU. Based on the diagram, I think the restriction would MTU on packets leaving your 2800 to the service provider. If the 2800 is generating ICMP unreachable, make sure that ICMP is not filtered before reaching the endpoint hosts.

     

    I have seen these exact symptons and that can certainnly be caused buy this Path MTU discovery not working correctly (PMTUD).

     

    Hope this helps.

  • Paul Stewart  -  CCIE Security, CCSI 6,989 posts since
    Jul 18, 2008

    I'm a bit confused on this.  It certainly sounds like what I have seen with PMTUD issues in the past.  It seems that you stated you could ping across.  I would watch closely and make sure the IP address that replies is the same one you pinged.  In some cases with nat configured, you can ping the private address, and you see the public address respond.  This is doe to the vpn traffic not be exempted from the NAT commands.  This will break most communication, but ping appears to work (unless you look really closely).  Also, if there is port address translation or static nat to the IP addresses you are working with, special care may have to be taken to make sure the responses are not being translated.  You might even just do a debug ip nat on the router(s) just to make sure something unexpected isn't going on.  Since this is GRE, this is much less likely than a traditional vpn using crypto map to a public interface, but that is about the only other thing I can think of right now..

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)