NAT Port Forwarding no funciona (SOLVED)
-
Excelente, mi problema está en:
3. Client machine is not using pfSense as its default gateway
Gracias!!! como es pruebas, no me percaté de esto, modifico el GW y pruebo…
Saludos.
-
Probado y sigue sin funcionar.
Probé desde la red local http://172.16.98.123 y veo bien el Web Server
Ya el Web Server tiene configurado el pfSense como Default Gateway, y veo internet sin problemas desde el We3b Server debido a la regla permisiva que está en la LAN.
Probé con otro enlace llegar al Webserver con la direción WAN y nada.Alguna otra idea? porque se me acabaron a mi :D y ya revisé todas las opciones del Troubleshooting.
Saludos
-
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
-
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.
-
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 HTTPEn Rules NAT
Description: NAT Test HTTPUna 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…
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.
-
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.
-
Adicionalmente, en Diagnostics - Command Prompt puedes hacer:
pfctl -s nat
para ver los NAT activos.
-
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...
-
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 ServerEl "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.
-
¿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…
-
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
-
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).
-
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).
-
¡De nada!
Si no llegas a google.com con TCP efectivamente tienes algo que corta.
-
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.
-
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 )
-
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"
-
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.
