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

    Rutas estáticas

    Scheduled Pinned Locked Moved Español
    12 Posts 3 Posters 7.3k 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.
    • B
      beniSB
      last edited by

      Buenos días a todos,
      soy un principiante en pfSense y estoy teniendo problemas al realizar pruebas en un pequeño laboratorio que tengo montado. Les adjunto una imagen del esquema que tengo:

      http://subefotos.com/ver/?7588cfd248f94e40c07943de86dd1de7o.jpg

      En dicho diagrama el pfSense con la IP: 172.16.20.121 tiene como gateway predeterminado el router con IP: 172.16.20.1, mientras que el pfSense con IP: 172.16.20.120 tiene como gateway predeterminado el router con IP: 172.16.20.2.

      Como ven en la imagen por debajo de esos pfSense hay una subred con una serie de equipos.
      Quiero que las dos redes que estan por debajo de los pfSense sean visibles entre sí y que cada una de esas redes salga a internet por gateways distintos. Ante esto lo que tengo configurado es:

      • El gateway de los equipos de cada una de las subredes es el propio pfSense.
      • Cada pfSense tiene asignado su gateway predeterminado (172.16.20.120 –> 172.16.20.2 y 172.16.20.121 --> 172.16.20.1).
      • En cada pfSense he creado una ruta estática que dice lo siguiente:

      * Network:  192.168.200.0/24 Gateway: 172.16.20.121  Interface: WAN
            * Network:  192.168.100.0/24 Gateway: 172.16.20.120  Interface: WAN

      - Está todo permitido, tanto en LAN como en WAN.
        - Los firewalls de los equipos de las subredes están desactivados.

      El problema es que el pfSense se está saltando la ruta estática que tengo puesta en cada uno de ellos, ya que no llego a ninguna de las Ip´s de las otras subredes.
      Si le hago un "traceroute" en cualquiera de las subredes me envía directamente al gateway predeterminado que tiene configurado el pfSense y por tanto se salta la ruta estática.

      ¿Sabrían ayudarme a solucionar el problema?. ¿Hay que utilizar de alguna forma especial "La política de enrutado en pfSense" para este tipo de casos?.

      En cualquier caso, muchas gracias de antemano.

      Saludos,

      1 Reply Last reply Reply Quote 0
      • belleraB
        bellera
        last edited by

        NO rutas estáticas con subredes pertenecientes a pfSense

        Equipo izquierdo

        Añade puerta para interfase WAN 172.16.20.120

        Añade regla por delante en LAN para destino 192.168.100.0/24 yendo por puerta 172.16.20.120

        Equipo derecho

        Añade puerta para interfase WAN 172.16.20.121

        Añade regla por delante en LAN para destino 192.168.200.0/24 yendo por puerta 172.16.20.121

        Ya dirás cómo te fue.

        7588cfd248f94e40c07943de86dd1de7o.jpg
        7588cfd248f94e40c07943de86dd1de7o.jpg_thumb

        1 Reply Last reply Reply Quote 0
        • B
          beniSB
          last edited by

          Muchas gracias por tu pronta respuesta,

          acabo de probar lo que me has comentado y sigo sin poder acceder entre subredes:

          He realizado lo que indicaste anteriormente, que por lo que entendí es:
            - Quito la ruta estática en cada pfSense.
            - Añado un nuevo gateway en cada pfSense para cada IP de la WAN con la IP del pfSense contrario.
            - Creo una regla en cada pfSense (las he puesto la primera) en el interfaz LAN para cada destino indicando en cada caso la subred destino y como gateway el pfsense contrario:
                        * Para 172.16.20.120 –> Destino 192.168.200.0/24  Gateway --> 172.16.20.121
                        * Para 172.16.20.121 --> Destino 192.168.100.0/24  Gateway --> 172.16.20.120

          Y sigo sin salir del problema. No entiendo que estoy haciendo mal...  :-[
          Algo se me escapa.

          PD: el traceroute hacia cada una de las subredes sigo indicando que salen por los gateways por defecto (172.16.20.1 y 172.16.20.2).

          Muchas gracias nuevamente.

          1 Reply Last reply Reply Quote 0
          • belleraB
            bellera
            last edited by

            @beniSB:

            • Para 172.16.20.120 –> Destino 192.168.200.0/24  Gateway --> 172.16.20.121
                            * Para 172.16.20.121 --> Destino 192.168.100.0/24  Gateway --> 172.16.20.120

            No. El origen tiene que ser LAN net (o cualquiera) en cada regla.

            Y, además, tienes que desmarcar Block Private Networks en cada WAN, pues están recibiendo tráfico de la WAN contraria.

            1 Reply Last reply Reply Quote 0
            • A
              acriollo
              last edited by

              Hola Bellera,

              tengo un caso parecido.  El caso que tengo yo es que "colgue" un pfsense con una IP de la LAN configurada en la WAN2 de mi equipo y la WAN1 conectado a un ADSL.

              Puedo ver los equipos que estan atras del pfsense sobre la LAN ( enviando ping desde un host de la red wan2 ) , pero el trafico que estoy sacando de la LAN hacia la red principal ( conectada por WAN2) me lo esta enmascarando el pfsense.  He agregado una regla para que el trafico hacia la red de la WAN2 proveniente de la LAN lo deje pasar directamente por la WAN2, pero aun asi me lo sigue enmascarando con la IP de la WAN2.

              Que necesito modificar para que el trafico entre mi LAN y la red de la WAN2 pase sin enmascarar ? habilitar el advanced nat y quitar el nateo de la wan2?

              Gracias de antemano

              1 Reply Last reply Reply Quote 0
              • A
                acriollo
                last edited by

                Aqui tengo un pequeño diagrama.

                No es el diseño de red mas adecuado , pero me permitiio salir del paso ya que no tenia otra interface dispoibile en el pFsense para conectar esta sucursal que esta conec
                tada via inalambrica.

                saludos

                Drawing1.jpg

                1 Reply Last reply Reply Quote 0
                • A
                  acriollo
                  last edited by

                  diagrama equivocado

                  Drawing1.jpg
                  Drawing1.jpg_thumb

                  1 Reply Last reply Reply Quote 0
                  • belleraB
                    bellera
                    last edited by

                    Si quieres desenmascarar, efectivamente, tienes que poner NAT Outbound en modo manual y escribir tus reglas de NAT saliente.

                    Piensa que los NAT se ejecutan según orden. Por tanto, puedes no NATear para destinos que pertenezcan a la subred de la WAN y NATear después para cualquier destino.

                    1 Reply Last reply Reply Quote 0
                    • A
                      acriollo
                      last edited by

                      Gracias.
                      Entonces habilito el advanced nat.

                      Pensaba que colocando una regla de paso para ese destino podria hacer que no pasara por el nat pero veo que no es así.

                      Saludos de puebla en mexico

                      1 Reply Last reply Reply Quote 0
                      • B
                        beniSB
                        last edited by

                        Buenos días nuevamente,
                        gracias una vez más pero puse las reglas tal y como indicaste (Block Private Networks ya lo tenía desmarcado) y sigo igual  :'(

                        Adjunto pantallazos de reglas LAN, configuración WAN y Gateways. No tengo rutas estáticas.
                        Aunque no lo he mencionado antes la versión que estoy utilizando en ambos equipos es la 2.1. Release (amd64).

                        ¿Alguna sugerencia adicional?.

                        Muchas gracias.

                        LAN_121.JPG
                        LAN_121.JPG_thumb
                        LAN_120.JPG
                        LAN_120.JPG_thumb
                        WAN_121.JPG
                        WAN_121.JPG_thumb
                        WAN_120.JPG
                        WAN_120.JPG_thumb
                        Gateways_121.JPG
                        Gateways_121.JPG_thumb
                        Gateways_120.JPG
                        Gateways_120.JPG_thumb

                        1 Reply Last reply Reply Quote 0
                        • B
                          beniSB
                          last edited by

                          Al final he podido solucionar el problema.
                          Simplemente activando la casillas "Bypass firewall rules for traffic on the same interface" dentro de SYSTEM –> ADVANCED --> FIREWALL/NAT --> STATIC ROUTING FILTERING se soluciona.

                          Al parecer si no está activa, cualquier ruta estática activa es desechada por el firewall (si no he entendido mal).
                          En cualquier caso, ya lo tengo solucionado.

                          Muchas gracias José Luis por tu apoyo y aportaciones al foro.

                          Un saludo.

                          1 Reply Last reply Reply Quote 0
                          • belleraB
                            bellera
                            last edited by

                            Static route filtering Bypass firewall rules for traffic on the same interface
                            This option only applies if you have defined one or more static routes. If it is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be desirable in some situations where multiple subnets are connected to the same interface.

                            Interesante opción que no recordaba. ¡Touché!

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.