Cómo prescindir del hairpin-nat

Hoy os vengo a traer un tema que me ha salido casi sin querer, pero que creo que merece la pena compartir con vosotros. Y vine a ser lo que propone el título del post, cómo prescindir de la regla de hairpin nat. Esta regla, se encarga de permitirnos usar un dominio público para poder acceder a una máquina local, desde dentro de nuestra propia red. Es decir, si tenemos por ejemplo un NAS o cualquier otro dispositivo en la red local que publica un dominio DDNS, es fácil que tengamos una regla en el NAT permitiendo que, cuando yo invoque esa URL pública desde dentro de la red, se resuelva la máquina local correspondiente, y tenga acceso a ese dominio de igual forma desde dentro o fuera de la red. En mi caso, la regla era algo así (vosotros tendréis versiones más o menos simplificadas de la misma regla)
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment=hairpin-nat dst-address=192.168.88.100 \
    out-interface-list=LAN protocol=tcp src-address=192.168.88.0/24

Es decir, todo lo que venga de mi red local, vía tcp y con destino esa máquina, cámbiale la IP de origen de la petición y le plantas la IP pública, que es lo que a fin de cuentas hace el masquerade. Eso luego hará que la petición entre por la segunda regla de NAT que tengáis cada uno, abriendo el puerto concreto de acceso a ese equipo, y que todo funcione, da igual si lo llamas desde dentro o desde fuera.

Pues bien, el problema con las reglas de hairpin-nat, también conocido como nat loopback es siempre el mismo: si queremos afinar mucho la regla para acotar el tráfico que pasa por ella, se convertirá en algo compleja y rebuscada; y probablemente no nos funcione para todo lo que queremos. Y, si la ponemos más genérica, del tipo a la que hay documentada en el manual de tips&tricks (todo lo que se origine en la red, y con destino la red), la regla capturará tráfico innecesario que no debería pasar por ahí.

Y ¿cómo nos la quitamos en cuestión? Pues de una manera tan chorra que casi me da vergüenza contarlo: usando la reserva de direcciones estáticas en el DNS. De esta manera, si mi dominio registra un nas.pericopalotes.com como el nombre ddns para apuntar al NAS de mi casa, es tan sencillo como dar de alta esa entrada en la caché del DNS, para que todo empiece a funcionar sin necesidad de tener ninguna regla de hairpin-nat. ¿Por qué? pues porque esa entrada la apuntaremos a la IP privada del aparato en cuestión, y cuando solicitemos ese dominio desde nuestro local, no estaremos resolviendo nuestra IP pública, sino directamente la privada de ese chisme. De esa manera, los certificados SSL seguirán funcionando, el candadito se seguirá viendo bien en la petición https y todo quedará "cmo en caca". Total, para qué vamos a salir a internet o a un DNS público para resolver algo de lo que sabemos a ciencia cierta su IP.

La entrada estática en el DNS del router, sería algo así:
Código:
/ip dns static
add address=192.168.88.100 name=nas.pericopalotes.com

De igual forma, si usáis adguard o pi-hole, podéis hacer exactamente lo mismo en el apartado "Local DNS -> DNS Records", si estáis entregando este DNS como primario, en lugar de hacerlo en el router (o hacerlo en ambos sitios, si queréis un backup)

1630656814490.png


De esta manera tan simple podéis prescindir de la regla de hairpin-nat, y resolver localmente vuestros dominios públicos a velocidad del rayo.

Saludos!
 
Está de masterclass tenía poco. Fue más casualidad que otra cosa.

Saludos!
Pues me ha venido genial ese tip, porque tengo un webserver en el NAS y he visto que ahora el navegador si reconoce el certificado Let's Encrypt que tengo en mis páginas. Gracias!!

S@lu2.
 
@pokoyo cómo quedaría entonces la apertura de puertos? Recuerdo que para usar los del hairpin nat había que abrir los puertos de una forma un tanto maquiavélica, por lo que, si prescindimos del hairpin nat y añadimos la regla en la caché del DNS, la apertura de puertos se haría de forma normal? ¿Funcionaría la forma de abrir puertos descritas en la sección del hairpin nat de tips&tricks?

Y otra preguntilla, aunque creo saber la respuesta. ¿Cómo afectaría esto a una conexión desde VPN? Entiendo que funcionaría igual, porque en la VPN resuelves de igual forma los DNS...

Saludos!
 
La apertura de puertos quedaría igual, de la misma manera que sin hairpin abres cualquier otro puerto. No obstante, y según la manera que publiqué en el manual de tips&tricks para hacer hairpin, la única posible diferencia es usar o no el dst-address-list=public-ip como filtro adicional, lo cual sigo pensando que es buena práctica usarlo, de manera idéntica, y sinceramente me gusta más que la opción de filtrar por in-interface=X. No obstante, pasas a depender de la resolución de tu IP pública, y ya sabemos lo que pasó ayer con los DDNS de mikrotik.

Si para el segmento de la vpn tienes aceptado ese rango del pool vpn en el chain de input (o la conexión metida en la lista LAN, como hacíamos para las L2TP), podrás usar el router como resolver dns y te quedaría idéntico.

Saludos!
 
La apertura de puertos quedaría igual, de la misma manera que sin hairpin abres cualquier otro puerto. No obstante, y según la manera que publiqué en el manual de tips&tricks para hacer hairpin, la única posible diferencia es usar o no el dst-address-list=public-ip como filtro adicional, lo cual sigo pensando que es buena práctica usarlo, de manera idéntica, y sinceramente me gusta más que la opción de filtrar por in-interface=X. No obstante, pasas a depender de la resolución de tu IP pública, y ya sabemos lo que pasó ayer con los DDNS de mikrotik.

Si para el segmento de la vpn tienes aceptado ese rango del pool vpn en el chain de input (o la conexión metida en la lista LAN, como hacíamos para las L2TP), podrás usar el router como resolver dns y te quedaría idéntico.

Saludos!

Ahí es donde voy, que abrir los puertos cómo está descrito en el hairpin-nat te hace que dependas de resolver tu DynDNS, y hacerlo de la manera tradicional no dependes de resolver tu ip pública.

Si esto es así, la verdad es que a mi, personalmente, me gusta más la manera tradicional, por no depender de dyndns que pueden caerse y, al menos, en casa no notar ningún problema.
 
Ahí es donde voy, que abrir los puertos cómo está descrito en el hairpin-nat te hace que dependas de resolver tu DynDNS, y hacerlo de la manera tradicional no dependes de resolver tu ip pública.

Si esto es así, la verdad es que a mi, personalmente, me gusta más la manera tradicional, por no depender de dyndns que pueden caerse y, al menos, en casa no notar ningún problema.
Correcto.

Saludos.
 
También puedes crear la lista “public-ip” vía script. Si quieres, te paso un par de ejemplos de cómo sacarla a partir de conexiones dinámicas tipo dhcp y PPPoE. Me tocó montarlo por esa vía cuando monté la segunda conexión WAN. Si lo necesitas, dime.

Saludos!
 
Buenas,
tengo unos scripts corriendo en un HEX S que actualizan clientes ddns, tal como se detalla en el hilo de "tips&tricks". Creé la regla de hairpin nat, para poder acceder a los mismos equipos desde la red local, resolviendo la direccion ddns, pero no funciona. Esto es posible? o debe realizarse como explicas en este hilo @pokoyo ? He hecho un export de la configuración y creo que debe estar un poco sucia", después de haber implementado bastantes líneas de código para incluir nuevas funcionalidades.

Cualquier ayuda es bienvenida, ya que estoy aprendiendo mas aquí que en el curso de MTCNA que realicé hace unos años ;). Gracias de antemano
 
Buenas,
tengo unos scripts corriendo en un HEX S que actualizan clientes ddns, tal como se detalla en el hilo de "tips&tricks". Creé la regla de hairpin nat, para poder acceder a los mismos equipos desde la red local, resolviendo la direccion ddns, pero no funciona. Esto es posible? o debe realizarse como explicas en este hilo @pokoyo ? He hecho un export de la configuración y creo que debe estar un poco sucia", después de haber implementado bastantes líneas de código para incluir nuevas funcionalidades.

Cualquier ayuda es bienvenida, ya que estoy aprendiendo mas aquí que en el curso de MTCNA que realicé hace unos años ;). Gracias de antemano
Pásame el export sólo del NAT, que te digo como hacerlo. Es perfectamente posible hacer la regla, esto es solo una “ñapa” para evitarla.

Saludos!
 
Hola @Maya62 !

El NAT que me mandas por privaddo... es una locura!

Si necesitas acceder a todos esos servicios desde fuera, monta una VPN!!! No expongas de esa manera los puertos, que más temprano que tarde tendrás un susto (si llegas tú, llega cualquiera desde internet). Justo para eso existen las conexiones VPN, te recomiendo les eches un vistazo a los manuales que tenemos en el foro al respecto. Una simple L2TP/IPSec, que se monta en dos minutos, te ahorra abrir ninguno de estos puertos de cara al exterior, salvo que tengas que exponer un webserver o algo así, no lo necesitas.

Te resumo cómo implementar la regla de hairpin NAT, tal y como está en el manual

Primero creamos el loopback, para que todo tráfico con origen nuestra red y destino nuestra propia red, que pase por el NAT, se cambie IP privada por IP pública
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment=hairpin-nat dst-address=\
192.168.1.0/24 src-address=192.168.1.0/24

Luego, si has seguido la guía, deberías tener una lista "public-ip" con tu IP pública. El resto de reglas, para que funcione el hairpin como debe, han de ir con ese filtro, en lugar de con el filtro de in-inteface=pppoe-out1

Un ejemplo sería este:
Código:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address-list=public-ip dst-port=33900 \
protocol=tcp to-addresses=192.168.1.238 to-ports=33900

Saludos!
 
Joe pokoyo, eres un crack. Y no tanto por la idea, sino lo pedagógico que eres explicándolo, que ayudas a que se entienda facilmente y aprendamos todos. Mil gracias, a mi me viene realmente bien. Os pongo un ejemplo:

Tengo un receptor de satélite que hace streaming por IP de lo que recibe vía sat. De esta forma se puede ver el satélite en una tablet o en la casa de la playa. Para cuando estaba en casa, tenía que tener una lista separada, con dirección local en vez de la dirección externa. Ahora ya me basta con una única lista de canales.

Como mucho (y corrígeme si me equivoco pokoyo) de esta forma, el contenido pasa por el router, y usando la lista de canales con la dirección local del receptor de sat, todo se quedaría en el switch.
 
Joe pokoyo, eres un crack. Y no tanto por la idea, sino lo pedagógico que eres explicándolo, que ayudas a que se entienda facilmente y aprendamos todos. Mil gracias, a mi me viene realmente bien. Os pongo un ejemplo:

Tengo un receptor de satélite que hace streaming por IP de lo que recibe vía sat. De esta forma se puede ver el satélite en una tablet o en la casa de la playa. Para cuando estaba en casa, tenía que tener una lista separada, con dirección local en vez de la dirección externa. Ahora ya me basta con una única lista de canales.

Como mucho (y corrígeme si me equivoco pokoyo) de esta forma, el contenido pasa por el router, y usando la lista de canales con la dirección local del receptor de sat, todo se quedaría en el switch.
Con este método solo vas al router a resolver la IP del dominio ddns. Una vez te informan de que es una ip local, el resto lo manejas a nivel de capa2 (switch), vía la tabla ARP (relación entre ip local y dirección física MAC)

Saludos!
 
Hoy os vengo a traer un tema que me ha salido casi sin querer, pero que creo que merece la pena compartir con vosotros. Y vine a ser lo que propone el título del post, cómo prescindir de la regla de hairpin nat. Esta regla, se encarga de permitirnos usar un dominio público para poder acceder a una máquina local, desde dentro de nuestra propia red. Es decir, si tenemos por ejemplo un NAS o cualquier otro dispositivo en la red local que publica un dominio DDNS, es fácil que tengamos una regla en el NAT permitiendo que, cuando yo invoque esa URL pública desde dentro de la red, se resuelva la máquina local correspondiente, y tenga acceso a ese dominio de igual forma desde dentro o fuera de la red. En mi caso, la regla era algo así (vosotros tendréis versiones más o menos simplificadas de la misma regla)
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment=hairpin-nat dst-address=192.168.88.100 \
    out-interface-list=LAN protocol=tcp src-address=192.168.88.0/24

Es decir, todo lo que venga de mi red local, vía tcp y con destino esa máquina, cámbiale la IP de origen de la petición y le plantas la IP pública, que es lo que a fin de cuentas hace el masquerade. Eso luego hará que la petición entre por la segunda regla de NAT que tengáis cada uno, abriendo el puerto concreto de acceso a ese equipo, y que todo funcione, da igual si lo llamas desde dentro o desde fuera.

Pues bien, el problema con las reglas de hairpin-nat, también conocido como nat loopback es siempre el mismo: si queremos afinar mucho la regla para acotar el tráfico que pasa por ella, se convertirá en algo compleja y rebuscada; y probablemente no nos funcione para todo lo que queremos. Y, si la ponemos más genérica, del tipo a la que hay documentada en el manual de tips&tricks (todo lo que se origine en la red, y con destino la red), la regla capturará tráfico innecesario que no debería pasar por ahí.

Y ¿cómo nos la quitamos en cuestión? Pues de una manera tan chorra que casi me da vergüenza contarlo: usando la reserva de direcciones estáticas en el DNS. De esta manera, si mi dominio registra un nas.pericopalotes.com como el nombre ddns para apuntar al NAS de mi casa, es tan sencillo como dar de alta esa entrada en la caché del DNS, para que todo empiece a funcionar sin necesidad de tener ninguna regla de hairpin-nat. ¿Por qué? pues porque esa entrada la apuntaremos a la IP privada del aparato en cuestión, y cuando solicitemos ese dominio desde nuestro local, no estaremos resolviendo nuestra IP pública, sino directamente la privada de ese chisme. De esa manera, los certificados SSL seguirán funcionando, el candadito se seguirá viendo bien en la petición https y todo quedará "cmo en caca". Total, para qué vamos a salir a internet o a un DNS público para resolver algo de lo que sabemos a ciencia cierta su IP.

La entrada estática en el DNS del router, sería algo así:
Código:
/ip dns static
add address=192.168.88.100 name=nas.pericopalotes.com

De igual forma, si usáis adguard o pi-hole, podéis hacer exactamente lo mismo en el apartado "Local DNS -> DNS Records", si estáis entregando este DNS como primario, en lugar de hacerlo en el router (o hacerlo en ambos sitios, si queréis un backup)

Ver el adjunto 85857

De esta manera tan simple podéis prescindir de la regla de hairpin-nat, y resolver localmente vuestros dominios públicos a velocidad del rayo.

Saludos!
Hola!!!

Llevo un tiempo leyéndote porque, como reciente propietario de un Mikrotik RB4011, y viniendo de routers más "domésticos", he necesitado leer mucho para entender más o menos (más menos que más ;) ) como funciona el "bicho", y, la verdad, es que tus posts me parecen geniales para empezar a entender la filosofía del routeros.

Respecto a tu post para evitar el Hairpin NAT, lo veo práctico si tienes cada servicio con un nombre DNS diferente, pero si utilizas el mismo nombre DNS (p.e.: micasa.dominio.com) para varios servicios en diferentes máquinas, ¿no se complica un poco el prescindir del Hairpin?

Lo dicho, enhorabuena por el trabajo y gracias por todo.
 
Hola!!!

Llevo un tiempo leyéndote porque, como reciente propietario de un Mikrotik RB4011, y viniendo de routers más "domésticos", he necesitado leer mucho para entender más o menos (más menos que más ;) ) como funciona el "bicho", y, la verdad, es que tus posts me parecen geniales para empezar a entender la filosofía del routeros.

Respecto a tu post para evitar el Hairpin NAT, lo veo práctico si tienes cada servicio con un nombre DNS diferente, pero si utilizas el mismo nombre DNS (p.e.: micasa.dominio.com) para varios servicios en diferentes máquinas, ¿no se complica un poco el prescindir del Hairpin?

Lo dicho, enhorabuena por el trabajo y gracias por todo.
Sí, es un apaño. Para algo más complejo, montaría un nginx con un proxy reverso, y puedes montar un dominio con un wildcard que coja todo lo que le llega al nginx. Pero ya necesitas algo más, otra máquina aparte del router para montarlo.

Y esto no es más que un workaround, si lo quieres hacer bien, tienes que usar el hairpin NAT, que para eso está.

Saludos!
 
Hoy os vengo a traer un tema que me ha salido casi sin querer, pero que creo que merece la pena compartir con vosotros. Y vine a ser lo que propone el título del post, cómo prescindir de la regla de hairpin nat. Esta regla, se encarga de permitirnos usar un dominio público para poder acceder a una máquina local, desde dentro de nuestra propia red. Es decir, si tenemos por ejemplo un NAS o cualquier otro dispositivo en la red local que publica un dominio DDNS, es fácil que tengamos una regla en el NAT permitiendo que, cuando yo invoque esa URL pública desde dentro de la red, se resuelva la máquina local correspondiente, y tenga acceso a ese dominio de igual forma desde dentro o fuera de la red. En mi caso, la regla era algo así (vosotros tendréis versiones más o menos simplificadas de la misma regla)
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment=hairpin-nat dst-address=192.168.88.100 \
    out-interface-list=LAN protocol=tcp src-address=192.168.88.0/24

Es decir, todo lo que venga de mi red local, vía tcp y con destino esa máquina, cámbiale la IP de origen de la petición y le plantas la IP pública, que es lo que a fin de cuentas hace el masquerade. Eso luego hará que la petición entre por la segunda regla de NAT que tengáis cada uno, abriendo el puerto concreto de acceso a ese equipo, y que todo funcione, da igual si lo llamas desde dentro o desde fuera.

Pues bien, el problema con las reglas de hairpin-nat, también conocido como nat loopback es siempre el mismo: si queremos afinar mucho la regla para acotar el tráfico que pasa por ella, se convertirá en algo compleja y rebuscada; y probablemente no nos funcione para todo lo que queremos. Y, si la ponemos más genérica, del tipo a la que hay documentada en el manual de tips&tricks (todo lo que se origine en la red, y con destino la red), la regla capturará tráfico innecesario que no debería pasar por ahí.

Y ¿cómo nos la quitamos en cuestión? Pues de una manera tan chorra que casi me da vergüenza contarlo: usando la reserva de direcciones estáticas en el DNS. De esta manera, si mi dominio registra un nas.pericopalotes.com como el nombre ddns para apuntar al NAS de mi casa, es tan sencillo como dar de alta esa entrada en la caché del DNS, para que todo empiece a funcionar sin necesidad de tener ninguna regla de hairpin-nat. ¿Por qué? pues porque esa entrada la apuntaremos a la IP privada del aparato en cuestión, y cuando solicitemos ese dominio desde nuestro local, no estaremos resolviendo nuestra IP pública, sino directamente la privada de ese chisme. De esa manera, los certificados SSL seguirán funcionando, el candadito se seguirá viendo bien en la petición https y todo quedará "cmo en caca". Total, para qué vamos a salir a internet o a un DNS público para resolver algo de lo que sabemos a ciencia cierta su IP.

La entrada estática en el DNS del router, sería algo así:
Código:
/ip dns static
add address=192.168.88.100 name=nas.pericopalotes.com

De igual forma, si usáis adguard o pi-hole, podéis hacer exactamente lo mismo en el apartado "Local DNS -> DNS Records", si estáis entregando este DNS como primario, en lugar de hacerlo en el router (o hacerlo en ambos sitios, si queréis un backup)

Ver el adjunto 85857

De esta manera tan simple podéis prescindir de la regla de hairpin-nat, y resolver localmente vuestros dominios públicos a velocidad del rayo.

Saludos!
Gracias por el TIP, un placer como siempre leer tus comentarios @pokoyo
 
Arriba