• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

VPN 2 Sites lan to lan y Road Warrior: CLientes VPN sin conexión con la 2ª RED

Scheduled Pinned Locked Moved Español
10 Posts 3 Posters 2.0k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I
    ITS
    last edited by Oct 23, 2014, 4:20 PM

    Buenas tardes,
    soy nuevo con el software PFsense y estoy haciendo pruebas en un entorno preproductivo con el fin de implementarlo en producción, actualmente dispongo de un Pfsense montado con 2 tarjetas de red en cada site, un tunel con OpenVPN con servidor en modo Peer to Peer que une las dos oficinas remotas, funciona perfectamente la comunicación entre ambas oficinas, y también he configurado un acceso VPN para clientes externos en los dos sites, los dos accesos funcionan perfectamente pero, cuando se conecta un cliente solamente tiene acceso a la red local de la oficina a la que se ha conectado, no consigo que el cliente VPN disponga de conectividad hacia el site remoto, la configuración de red es la siguiente:

    OFICINA PRINCIPAL:          172.16.8.0/24
    OFICINA REMOTA:              172.16.7.0/24
    TUNEL PEER TO PEER:        192.168.1.0/24
    RED PARA CLIENTES VPN:    192.168.0.0/24 (ROAD WARRIOR).

    La idea es que todos los clientes que se conecten indistintamente en un site u otro, lleguen a las dos redes locales (Oficina principal y oficina remota). he leido sus posts y mucha documentación y he aplicado las rutas con push route… etc. El cliente cuando se conecta dispone de las rutas, tanto para la red 10.0.8.0/24 como para la 10.0.7.0/24 pero no consigo llegar a la red remota. las reglas del Firewall son las estandar por defecto, tanto para la LAN, WAN y OPENVPN.

    Si un cliente VPN se conecta a la Oficina Principal, tiene red hacia la 10.0.8.0/24 pero no a la 10.0.7.0/24, ocurre lo mismo si se conecta a la oficina remota, no consigue llegar a la red de la oficina principal.

    Agradecería que me ayuden con el problema, de antemano muchas gracias, si se necesitan datos adicionales o capturas de pantalla, indcádmelo.

    PD: PFsense sinceramente es una maravilla, estoy revisando la documentación que se aporta en esto foro y también desde la página y aportes del Sr. Ballera, formidable trabajo por parte de todos!

    Gracias nuevamente.

    1 Reply Last reply Reply Quote 0
    • G
      georgeman
      last edited by Oct 24, 2014, 5:57 AM

      Seguramente los clientes roadwarrior no tengan las rutas necesarias.

      Agrega lo siguiente a la configuración avanzada del servidor roadwarrior de la oficina principal, y viceversa:

      push "route 172.16.7.0 255.255.255.0";

      De esta manera, los roadwarriors ahora sabrán que tienen que rutear esa subnet a traves de la VPN.

      Saludos!

      If it ain't broke, you haven't tampered enough with it

      1 Reply Last reply Reply Quote 0
      • I
        ITS
        last edited by Oct 24, 2014, 2:33 PM

        Hola Georgeman,
        antes de nada, gracias por la respuesta! He agregado las rutas tal y como me indicas y el resultado es el mismo;

        En la oficina principal he agregado push "route 172.16.7.0 255.255.255.0";

        y en la secundaria push "route 172.16.8.0 255.255.255.0";

        He compronado que las rutas se heredan correctamente en el CLiente VPN (windows 8) con route print. para las dos subredes mencionadas hacia el mismo GW del tunel, sin embargo sigo sin poder hacer ping a la subred de la oficina remota. lo he pribado en los dos Pfsense y sucede lo mismo. También he probado a crear una entrada en la pestaña client specific Overrides con el Common Name del certificado que utilizo con el usuario que hago pruebas de conexión VPN y añadiendo la ruta con iroute 172.16.7.0 255.255.255.0, pero tampoco funciona.

        Para el Servidor OPenVPN Peer to Peer utilizo el puerto UDP 1195 y para el RoadWarrior el 1194. La configuración de los NATs es la estandar que genera el PFSENSE cuando creas los servidores, es la siguiente:

        WAN
        –----
        PROTO  SOURCE  PORT  DESTINATION    PORT  GETWAY  QUEUE
        IP4udp  *              *        wan adress      1194  *              none
        IP4udp  *              *        wan adress      1195  *              none

        LAN

        PROTO  SOURCE  PORT  DESTINATION    PORT  GETWAY  QUEUE
        IP4*      LAN NET  *        *                      *        *              none

        OPENVPN

        PROTO  SOURCE  PORT  DESTINATION    PORT  GETWAY  QUEUE
        IP4*      LAN NET  *        *                      *        *              none

        Son correctas las reglas del FW? Es necesario agregar alguna adicional? creo que he hecho todo tipo de pruebas, pero no consigo que se vean.

        Espero vuestros comentarios, gracias de antemano!

        Saludos,

        1 Reply Last reply Reply Quote 0
        • A
          acriollo
          last edited by Oct 25, 2014, 1:01 AM

          Yo tengo algo similar pero con dos redes que estan como remote access.

          En una red tengo a los ruteadores de mis clientes que se conectan a mi server de openvpn para que pueda accesarlos para hacer tareas de soporte.

          Por otro lado tengo un servidor para que yo o alguien mas se conecte desde su PC o tableta para de esta manera dar acceso a los recursos locales y para accesar a los ruteadores de los clientes.

          Lo unico que tengo adicional es una regla que da acceso de la red de soporte a la red de clientes. Pero como no tengo dispositivos atras de los routers de los clientes que necesite accesar pues no tengo tanto problema, pero creo que se podria solucionar.

          Ademas claro de los push de las rutas de los otras redes.

          Que regla tienes en tu firewall del lado de la interface OpenVPN ?

          Verifica que los routers tengan en las reglas para la interface openvpn lo necesario para pasar el trafico requerido

          1 Reply Last reply Reply Quote 0
          • A
            acriollo
            last edited by Oct 25, 2014, 1:03 AM

            Veo que tienes una regla en el firewall e interface openvpn que dice que si el trafico viene de la red lan hacia cualquier lado qe la deje pasar.  Pero que pasa si el trafico es de otra interface o en este caso de otra red ?

            Creo que deberias de probar con cualquier origen y despues si te funciona delimitar a las redes que desees pasar.

            Suerte.

            1 Reply Last reply Reply Quote 0
            • I
              ITS
              last edited by Oct 27, 2014, 8:39 AM

              Buenos días Acriollo,
              gracias por los comentarios, la regla en el FW para el acceso OpenVPN la tengo abierta para cualquier origen, la tenía así desde un inicio, al copiar y pegar no lo modifiqué en el post, disculpad… así es como está la regla:

              OPENVPN

              PROTO  SOURCE  PORT  DESTINATION    PORT  GETWAY  QUEUE
              IP4*      *            *        *                      *        *              none

              necesito ayuda, lo he probado de muchas formas y el resultado es el mismo, no se donde puede estar el problema, todo parece indicar que es tema de FW pero no veo donde puede estar, gracias.

              Saludos,

              1 Reply Last reply Reply Quote 0
              • I
                ITS
                last edited by Oct 27, 2014, 10:39 AM

                Hola,
                Entiendo que es un escenario muy comun, varias sedes unidas con acceso vpn para clientes externos con servicios centralizados en una sede (mail Server, etc)… en una empresa donde trabajé lo teníamos así montado, se trataba de una MPLS, electrónica Cisco, concentrador VPN, una única entrada para los clientes VPN estaba en la sede central, donde se conectaban  los clientes VPN, pero, con acceso a todas las subredes... en este caso, quiero disponer de accesos VPN Clients en todas las sedes, pero obviamente con acceso a todas las subredes, entiendo que este esquema se tenga implementado en muchos casos...

                Gracias

                Saludos,

                1 Reply Last reply Reply Quote 0
                • I
                  ITS
                  last edited by Oct 27, 2014, 12:24 PM

                  Por cierto, para el servidor Remote Access utilizo un certificado concreto, y para el peer to peer otro, es así como debe de estar configurado?

                  Gracias y saludos,

                  1 Reply Last reply Reply Quote 0
                  • A
                    acriollo
                    last edited by Oct 29, 2014, 2:32 AM

                    puedes pegar aqui una pantalla de los tracerts y de las tablas de ruteo de los equipos involucrados ?

                    1 Reply Last reply Reply Quote 0
                    • I
                      ITS
                      last edited by Nov 10, 2014, 11:34 PM

                      Hola Acriollo,
                      Disculpa la demora de la respuesta, he estado desconectado estas últimas semanas, se trataba de un problema con las rutas, ya tengo acceso a la oficina remota desde los clientes VPN, faltaba añadir una ruta en el Pfsense de la oficina remota correspondiente con la red del tunel Road Warrior de la oficina principal, con esto ya está OK. Ahora queda conectar más delegaciones y validar que enrutan correctamente los tuneles y que son accesibles todas las redes, entiendo que no haya problemas. Si alguien tiene el mismo problema, no duden en contactarme por este medio, con mucho gusto aportaré mis anotaciones.

                      Muchas gracias a todos por el apoyo, espero poder aportar información con proximas implementaciones.

                      Saludos,

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        This community forum collects and processes your personal information.
                        consent.not_received