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

    NAT Port Forwarding no funciona (SOLVED)

    Scheduled Pinned Locked Moved Español
    20 Posts 4 Posters 5.2k 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.
    • A
      amnarl
      last edited by

      Mi estimado ese nat esta mal realizado por un pequeño detalle la regla en wan debe ser asignada automaticamente por el nat a mi parecer creo que usted la toco si lo hizo bien al principio el destino en la regla de wan debe ser la ip interna del servidor web bien sea en lan u otra subred…

      Configure nuevamente y haga las pruebas....

      OJO!!! Si usted esta detras de un proveedor que posee firewall como normalmente sucede debe poder tener como abrir puertos en el mismo o desactivarlo de lo contrario solo con un nat no podra hacer esto

      Configuracion y puesta en marcha de servers incluyendo pfsense en areas de produccion, para administrar y proveer servicios . Servicio tecnico presencial y online. Reparacion y mantenimiento de computadores. Instalacion y actualizacion de sistemas (Linux, Windows,Os/2) Conectividad a internet en zonas del Estado Lara donde no hay red cableada.
      http://www.linkedin.com/pub/amnarlyei-goitia/66/b2/722

      1 Reply Last reply Reply Quote 0
      • R
        rodria
        last edited by

        Si el NAT está mal hecho, lo debe haber hecho mal pfSense  ;D porque yo no he credo reglas, el único cambio que se hizo fue en la descripción del comentario, no en nada técnico… además, cuando la regla se creó hice la prueba antes de tocar nada, la identificación la hice después para hacer el screenshot y se entendiera las reglas en las gráficas.

        Saludos.

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

          Tal como se ve en http://nsae02.casimages.net/img/2014/12/03/141203032547295152.png cuando se hace un NAT Port Forward se crea automáticamente la regla de paso en WAN, usando la Descripción:

          En el NAT
          Description: Test HTTP
          Filter rule association: Rule NAT Test HTTP

          En Rules NAT
          Description: NAT Test HTTP

          Una vez creado el NAT, si se trastea con los NAT o con las reglas en WAN puede llegar a perderse esta asociación.

          Por las imágenes que subiste parece que lo explicado NO concuerda, por el motivo que sea.

          Ah, ya veo…

          @rodria:

          Por cierto, para que no vayan a confundir… el "Filter Rule Association" tiene otro nombre, porque modifiqué el nombre para identificarlo mejor, y ya había hecho el screenshot de la WAN, pero en sí, es la misma regla.

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

            Por favor, tramos de red usados en pfSense.

            Tienes un comentario "preocupante" en las reglas LAN. Cuando se refiere a 172.16.98.123 pones VIP. ¿Qué direccionamiento IP tiene tu LAN net?

            Sin saber los tramos de red usados, es decir tu topología de red, complicado ayudarte.

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

              Adicionalmente, en Diagnostics - Command Prompt puedes hacer:

              pfctl -s nat

              para ver los NAT activos.

              1 Reply Last reply Reply Quote 0
              • R
                rodria
                last edited by

                Vamos por partes :) :)

                Efectivamente había aclarado lo de los screenshot, porque sabría que habría confusión :)

                Para corregir dudas, yo eliminé la regla NAT,  la WAN se eliminó automáticamente al eliminar el NAT, pero igual fui a Rules y verifiqué que ya no estuviese, y efectivamente se eliminó, luego volví a generar mi regla NAT  SIN  tocar la descripción en ambas reglas, osea, todo de cajita… sé que no es necesario, pero para asegurarme en la LAN puse una regla para que ese "servidor WEB" piblicado (pruebas) no tuviese ninguna excusa para no salir hacia internet (colocar la regla no afecta en nada el portforwarding) y también verifiqué que estuviese activada la casilla de la regla webGUI redirect para evitar conflictos con el puerto 80 y NADA.

                Como esta WAN es un ADSL que tengo a modo de pruebas (como el nuevo pfSense) tengo que verificar con el proveedor que no tenga activado el "#$%&#"# firewall que ellos le colocan a todas las cuentas ADSL, cuando logre contactarlos y ver que esté desactivado el FW del proveedor pruebo y comento...

                1 Reply Last reply Reply Quote 0
                • R
                  rodria
                  last edited by

                  Como he explicado antes, mi red es una red de pruebas, no hay problemas con identificar el segmento…

                  ISP (190.x.x.x.) ---->  pfSense (172.16.98.204)    Gateway 190.x.x.1

                  LAN      172.16.98.0/24   
                  Server  172.16.98.123      Gateway  172.16.98.204
                  Cisco SW y Gateway de la RED      172.16.98.1  menos del Web Server

                  El "servidor" es mi máquina Linux/Debian que tiene instalado apache... y le cambié el Gateway apuntando al pfSense como lo indicaba el troubleshooting.

                  Saludos.

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

                    ¿Estás probando desde fuera el acceso al servidor web por nombre o por IP?

                    Prueba primero por la IP pública, entiendo que es la que toma tu WAN.

                    Esto no tiene mayor problema. Si no funciona es que hay algún lío.

                    Evidentemente, como ya dices, la puerta del servidor web tiene que ser la LAN de pfSense.

                    No sé si tienes algo especial en el switch, al decir que la puerta para toda tu red (excepto para el webserver) es otra.

                    Verifica con traceroute desde el webserver si realmente vas por donde toca.

                    Como esta WAN es un ADSL que tengo a modo de pruebas (como el nuevo pfSense) tengo que verificar con el proveedor que no tenga activado el "#$%&#"# firewall que ellos le colocan a todas las cuentas ADSL, cuando logre contactarlos y ver que esté desactivado el FW del proveedor pruebo y comento…

                    Pues que no tengas puertos cortados al publicarlos en internet…

                    1 Reply Last reply Reply Quote 0
                    • R
                      rodria
                      last edited by

                      Yep… tengo otra VLAN en producción con el enlace Metro Ethernet por donde pruebo acceder al Web Server...

                      lynx 190.x.x.x

                      y Nada

                      La prueba del traceroute ya la había hecho, no recuerdo si lo comenté... pero llega a una dirección 172.16.40.x del proveedor y allí queda bloqueada, por eso estoy esperando respuesta del proveedor a ver si me tienen filtrado los puertos, porque ya lo sufrí una vez en mi casa y pude eliminar el FW del servicio ADSL usando mi login y pass, pero como este ADSL es corporativo, hay otros procedimientos (que ilógico).

                      5  caf-dist-00-gi1-0-0.701.dist.cantv.net (201.249.228.34)  4.234 ms  4.229 ms  4.744 ms
                        6  10.150.0.153 (10.150.0.153)  7.890 ms  5.943 ms  6.398 ms
                        7  10.150.0.166 (10.150.0.166)  138.607 ms  137.483 ms *
                        8  172.16.40.245 (172.16.40.245)  5.067 ms  5.300 ms  5.098 ms
                        9  * * *
                      10  * * *
                      11  * * *
                      12  * * *

                      Saludos

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

                        Que una traza no llegue al final significa simplemente que el destino no responde a la traza.

                        En Linux tenemos la suerte de poder decidir cómo hacer la traza. Por defecto es UDP.

                        Prueba por TCP:

                        sudo traceroute -T www.xtec.cat

                        Añadir que lo importante en lo que dije antes es si se sale o no a internet por la puerta esperada (pasando por pfSense).

                        1 Reply Last reply Reply Quote 0
                        • R
                          rodria
                          last edited by

                          Gracias por responder.

                          Si había probado por TCP, la respuesta es la misma.

                          De Salida el traceroute:

                          traceroute to google.com (74.125.229.131), 30 hops max, 60 byte packets
                          1  172.16.98.204 (172.16.98.204)  0.258 ms  0.242 ms  0.227 ms
                          2  * * *
                          3  * * *
                          4  10.150.0.165 (10.150.0.165)  149.075 ms  150.036 ms  150.982 ms
                          5  10.150.0.97 (10.150.0.97)  151.977 ms  153.797 ms  154.411 ms
                          6  * * *
                          7  * * *

                          Como verás, estoy haciendo este trace de salida desde el "servidor"  172.16.98.123  y efectivamente llega al 172.16.98.204 que es el pfSense (su Gateway), luego al ISP a sus diferentes routers… hasta que llega a google.

                          Sigo esperando que Redes me de las credenciales para entrar a la cuenta del ISP y ver si tiene activado el firewall, porque la verdad "me doy..." :D (como decía Kiko el del Chavo del 8).

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

                            ¡De nada!

                            Si no llegas a google.com con TCP efectivamente tienes algo que corta.

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

                              Si estas usando conexion de cantv en venezuela por defecto trae activo el firewall de cantv este lo desactiva teniendo las credenciales para accesar por oficina virtual cantv.net y es alli donde puedes desactivarlo completa y efectivamente del resto tus publicaciones de servicios en internet no se veran de ninguna forma.

                              Configuracion y puesta en marcha de servers incluyendo pfsense en areas de produccion, para administrar y proveer servicios . Servicio tecnico presencial y online. Reparacion y mantenimiento de computadores. Instalacion y actualizacion de sistemas (Linux, Windows,Os/2) Conectividad a internet en zonas del Estado Lara donde no hay red cableada.
                              http://www.linkedin.com/pub/amnarlyei-goitia/66/b2/722

                              1 Reply Last reply Reply Quote 0
                              • R
                                rodria
                                last edited by

                                Sí, eso lo se, por eso dije que tenía que desactivar el firewall, el problema es que yo no soy el administrador de contrato de los enlaces, eso lo lleva el dpto. de redes, y ellos son los que hacen esa tarea, yo hago el requerimiento y ellos ejecutan (lo del firewall lo se, porque yo lo desactivé en mi cuenta personal de casa, hace ya unos cuantos años) afortunadamente ayer tuvieron la delicadez de llamarme y decirme que habían procedido con el requerimiento y "desactivaron" el firewall, sin embargo, sigo teniendo el mismo problema, voy a tener que solicitar una conexión del enlace dedicado para probar si es problema del ADSL o hay algo muy muy extraño en este pfSense, porque el de mi casa funciona sin problemas… ( o los de redes me mintieron y no desactivaron nada :D y como no tengo las credenciales para verificar que efectivamente el FW de ABA esté desactivado, estoy frito LOL )

                                1 Reply Last reply Reply Quote 0
                                • pttP
                                  ptt Rebel Alliance
                                  last edited by

                                  Preguntonta  ;D

                                  Realizaste una captura de paquetes en la WAN del pfSense, para verificar si los "paquetes" llegan a la misma ?

                                  Digo, para descartar falla/error en el pfSense… y/o confirmar que el problema está "upstream"

                                  1 Reply Last reply Reply Quote 0
                                  • R
                                    rodria
                                    last edited by

                                    Hola

                                    Sí, como no tengo tcpdump en pfSense, use "diagnoses packet capture" y los paquetes se quedaban en la dirección privada del proveedor que les había comentado anteriormente.

                                    Como ya "resolví" el dilema les comento el "problema".

                                    Mi proveedor del enlace dedicado es CANTV, el mismo proveedor del ADSL de pruebas (aclarando dudas).

                                    Cuando estaba probando el NAT, usaba el enlace dedicado para verificar el NAT del pfSense que está pegado al ADSL y nunca veía el Web Server de prueba, siendo dos enlaces totalmente diferentes, pues no me "funcionaba" el NAT, entonces con tantos intentos y "sniffeos" etc. siempre mi problema estaba en el "NAT" interno del proveedor de servicios por lo que decidí hacer otra prueba.

                                    Me hice un tunnel SSH a un servidor que tengo en USA y configuré el socks en un navegador y pude navegar al webserver, desde el mismo server de USA hice la solicitud al webserver usando lynx, y obviamente pude ver el webserver… osea.. me estaba rompiendo la cabeza y molestándolos por un problema de "nateo" (creo más que es enrutamiento) interno en el proveedor de servicios...
                                    Todo funciona bien, el problema estaba y está en el ISP., que por cierto, sigo sin poder navegar al webserver usando el enlace dedicado; pero bueeee... todo resuelto.

                                    Saludos.

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