MANUAL: Mikrotik, cómo hacer port forward vía túnel (bypass LTE CG-NAT)

Hoy os vengo a mostrar un manual muy sencillito y rápido de implementar, para solucionar un problema con el que todos nos podemos encontrar en algún momento: cómo hacerle un bypass a un CG-NAT, teniendo un túnel site to site ya montado. El problema es el siguiente:

Tenemos a nuestro amigo Eustaquio, que acaba de comprarse un router LTE de Mikrotik, con idea de darle wifi a sus cabras (no sabemos el porqué, pero necesitan wifi los animalitos). Como está en medio del monte y allí no llega la fibra, nuestro amigo adquiere un router LTE y le planta la primera SIM con una tarifa de datos que encuentra. Hasta ahí, todo normal, compra el chisme, lo echa a andar, y las cabras tienen wifi más pronto de lo que tardó nuestro amigo en pronunciar la marca del cacharro sin atragantarse.

Echando una cerveza con su colega Ataulfo, este último le comenta que, ya que el pisuerga pasa por Valladolid, por qué no montar una webcam y controlar a las alimañas que acechan a las pacíficas cabras de nuestro amigo Eustaquio cuando no está él allí, al quite con la vara. Ataulfo, que es más bien sobrao, le suelta un "esto se hace con la punta del cayao, que me lo montó a mi primo a mi en casa para ver al gato". Total, que lo convence, y nuestro amigo Eustaquio se monta la webcam. Y aquí viene el problema: por mucho que abre puertos, Eustaquio no tiene narices a acceder a la cámara en remoto.

Rebuscando, se da cuenta de que hay una cosa llamada CG-NAT que le han puesto a su conexión LTE, y no hay manera de que esa conexión le entregue una IP pública; la IP que le entrega la conexión LTE es siempre privada. Le ha dado mil vueltas, pero no hay manera. Busca y rebusca en internet y llega a este foro, donde aprende que puede unir dos routers con un túnel site to site usando wireguard, además de comunicar las cabras con su casa vía OSPF. Entonces, se acuerda de que él ya tiene otro Mikrotik en casa, cosa que le viene que ni pintao para eso de los túneles, y se pregunta: ¿si los uno con un túnel estos dos equipos, será posible aprovechar la IP pública de casa para llegar a la webcam? Total, que tirando de libretilla y boli, acaba con el siguiente dibujo (me tomé yo la molestia de pasárselo a limpio)

1656529193874.png

Eustaquio está casi casi, a puntito. Ha montado WG, dándose cuenta de que la conexión no puede ser bidireccional (ha de levantarla siempre el router LTE, por aquello del CG-NAT), ha montado OSPF y ahora accede a las cabras en remoto (WTF!), pero sigue sin poder ver a los bichos. Y se pregunta, como desde la subred de casa llego a las cabras sin problema, ¿será tan fácil como abrir un puerto con una regla de dst-nat, aunque la IP de destino sea de otra subred, ya que de "llegar" ya se encarga OSPF? Nuestro amigo, que tiene su red local en la 192.168.88.0/24 y la subred del router LTE en la 192.168.89.0/24, crea la siguiente regla de NAT en el router de casa:
Código:
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=8080 in-interface-list=WAN protocol=tcp to-addresses=\
    192.168.89.100 to-ports=80

Y se da cuenta de que, aparentemente, "funciona", porque la regla recibe tráfico cuando él hace http://serial.sn.mynetname.net:8080. Sin embargo... aquello no responde, y las cabras no se ven desde casa, bajo la comodidad del aire acondicionado (al pobre le va a tocar un viaje al monte).

Para ayudar a nuestro amigo Eustaquio, le vamos a plantear dos opciones:

La rápida

Para ello, crearemos una regla adicional de masquerade en el route que tiene IP pública, justo detrás de la regla de dst-nat que abre el puerto, que convierta la IP pública desde la que nos llega la petición original, en una IP local del router, tal que OSPF haga el resto. Imaginemos que la IP de destino es la misma que hemos dicho antes, 192.168.89.100, perteneciente a la subred del router LTE
Código:
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.89.100

La bien hecha​

La rápida funciona, pero tiene una pega: vamos a perder la IP de origen desde donde nos venía la petición. ¿cómo hacemos entonces? Lo primero que tenemos que entender es lo que está pasando: cuando una petición viene de fuera y se acaba enrutando al rotuter LTE, llegar llega, pero retornar no retorna, puesto que no intenta volver por donde vino (el túnel wireguard) sino por el gateway por defecto (la interfaz lte). Lo que necesitamos conseguir es justo eso: que esa petición vuelva por donde vino, por el túnel.
Para ello, el router de casa lo dejamos como está, con la ruta de dst-nat para el port forwarding, y nos movemos al router LTE:

Lo primero, creamos una nueva routing table, para el tráfico de retorno vía túnel
Código:
/routing table
add disabled=no fib name=tunel

Y creamos una nueva ruta por defecto, que diga que lo que venga por esa routing table, se vaya por la interfaz wireguard (o la IP del otro lado del túnel). En el ejemplo, 172.16.0.1 es la IP del túnel wireguard en el router de casa (el otro extremo)
Código:
/ip route
add gateway=172.16.0.1 routing-table=tunel

Y creamos dos reglas: la primera marca las conexiones que entren por el túnel, con destino la IP de la webcam. La segunda usa la marca creada en la primera regla para marcar el routing y soltar el tráfico en la nueva routing table que hemos creado:
Código:
/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address=192.168.89.100 \
    in-interface=wg-sts-home new-connection-mark=through-tunnel
add action=mark-routing chain=prerouting connection-mark=through-tunnel in-interface=bridge \
    new-routing-mark=tunel

Y, con esto y un bizcocho, le hemos hecho a Eustaquio un hombre, capaz de vigilar sus cabras desde donde le dé la gana.

Saludos!
 
Última edición:
Hoy os vengo a mostrar un manual muy sencillito y rápido de implementar, para solucionar un problema con el que todos nos podemos encontrar en algún momento: cómo hacerle un bypass a un CG-NAT, teniendo un túnel site to site ya montado. El problema es el siguiente:

Tenemos a nuestro amigo Eustaquio, que acaba de comprarse un router LTE de Mikrotik, con idea de darle wifi a sus cabras (no sabemos el porqué, pero necesitan wifi los animalitos). Como está en medio del monte y allí no llega la fibra, nuestro amigo adquiere un router LTE y le planta la primera SIM con una tarifa de datos que encuentra. Hasta ahí, todo normal, compra el chisme, lo echa a andar, y las cabras tienen wifi más pronto de lo que tardó nuestro amigo en pronunciar la marca del cacharro sin atragantarse.

Echando una cerveza con su colega Ataulfo, este último le comenta que, ya que el pisuerga pasa por Valladolid, por qué no montar una webcam y controlar a las alimañas que acechan a las pacíficas cabras de nuestro amigo Eustaquio cuando no está él allí, al quite con la vara. Ataulfo, que es más bien sobrao, le suelta un "esto se hace con la punta del cayao, que me lo montó a mi primo a mi en casa para ver al gato". Total, que lo convence, y nuestro amigo Eustaquio se monta la webcam. Y aquí viene el problema: por mucho que abre puertos, Eustaquio no tiene narices a acceder a la cámara en remoto.

Rebuscando, se da cuenta de que hay una cosa llamada CG-NAT que le han puesto a su conexión LTE, y no hay manera de que esa conexión le entregue una IP pública; la IP que le entrega la conexión LTE es siempre privada. Le ha dado mil vueltas, pero no hay manera. Busca y rebusca en internet y llega a este foro, donde aprende que puede unir dos routers con un túnel site to site usando wireguard, además de comunicar las cabras con su casa vía OSPF. Entonces, se acuerda de que él ya tiene otro Mikrotik en casa, cosa que le viene que ni pintao para eso de los túneles, y se pregunta: ¿si los uno con un túnel estos dos equipos, será posible aprovechar la IP pública de casa para llegar a la webcam? Total, que tirando de libretilla y boli, acaba con el siguiente dibujo (me tomé yo la molestia de pasárselo a limpio)


Eustaquio está casi casi, a puntito. Ha montado WG, dándose cuenta de que la conexión no puede ser bidireccional (ha de levantarla siempre el router LTE, por aquello del CG-NAT), ha montado OSPF y ahora accede a las cabras en remoto (WTF!), pero sigue sin poder ver a los bichos. Y se pregunta, como desde la subred de casa llego a las cabras sin problema, ¿será tan fácil como abrir un puerto con una regla de dst-nat, aunque la IP de destino sea de otra subred, ya que de "llegar" ya se encarga OSPF? Nuestro amigo, que tiene su red local en la 192.168.88.0/24 y la subred del router LTE en la 192.168.89.0/24, crea la siguiente regla de NAT en el router de casa:
Código:
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=8080 in-interface-list=WAN protocol=tcp to-addresses=\
    192.168.89.100 to-ports=80

Y se da cuenta de que, aparentemente, "funciona", porque la regla recibe tráfico cuando él hace http://serial.sn.mynetname.net:8080. Sin embargo... aquello no responde, y las cabras no se ven desde casa, bajo la comodidad del aire acondicionado (al pobre le va a tocar un viaje al monte).

Para ayudar a nuestro amigo Eustaquio, le vamos a plantear dos opciones:

La rápida

Para ello, crearemos una regla adicional de masquerade en el route que tiene IP pública, justo detrás de la regla de dst-nat que abre el puerto, que convierta la IP pública desde la que nos llega la petición original, en una IP local del router, tal que OSPF haga el resto. Imaginemos que la IP de destino es la misma que hemos dicho antes, 192.168.89.100, perteneciente a la subred del router LTE
Código:
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.79.243

La bien hecha​

La rápida funciona, pero tiene una pega: vamos a perder la IP de origen desde donde nos venía la petición. ¿cómo hacemos entonces? Lo primero que tenemos que entender es lo que está pasando: cuando una petición viene de fuera y se acaba enrutando al rotuter LTE, llegar llega, pero retornar no retorna, puesto que no intenta volver por donde vino (el túnel wireguard) sino por el gateway por defecto (la interfaz lte). Lo que necesitamos conseguir es justo eso: que esa petición vuelva por donde vino, por el túnel.
Para ello, el router de casa lo dejamos como está, con la ruta de dst-nat para el port forwarding, y nos movemos al router LTE:

Lo primero, creamos una nueva routing table, para el tráfico de retorno vía túnel
Código:
/routing table
add disabled=no fib name=tunel

Y creamos una nueva ruta por defecto, que diga que lo que venga por esa routing table, se vaya por la interfaz wireguard (o la IP del otro lado del túnel). En el ejemplo, 172.16.0.1 es la IP del túnel wireguard en el router de casa (el otro extremo)
Código:
/ip route
add gateway=172.16.0.1 routing-table=tunel

Y creamos dos reglas: la primera marca las conexiones que entren por el túnel, con destino la IP de la webcam. La segunda usa la marca creada en la primera regla para marcar el routing y soltar el tráfico en la nueva routing table que hemos creado:
Código:
/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address=192.168.89.100 \
    in-interface=wg-sts-home new-connection-mark=through-tunnel
add action=mark-routing chain=prerouting connection-mark=through-tunnel in-interface=bridge \
    new-routing-mark=tunel

Y, con esto y un bizcocho, le hemos hecho a Eustaquio un hombre, capaz de vigilar sus cabras desde donde le dé la gana.

Saludos!
Una vez más, para quitarse el sombrero….
 
Buenas @pokoyo , me podrias explicar porque el in-interface=bridge en la segunda regla?

add action=mark-routing chain=prerouting connection-mark=through-tunnel in-interface=bridge \
new-routing-mark=tunel
 
Buenas @pokoyo , me podrias explicar porque el in-interface=bridge en la segunda regla?

add action=mark-routing chain=prerouting connection-mark=through-tunnel in-interface=bridge \
new-routing-mark=tunel
Porque es el tráfico que viene de tu LAN.

Saludos!
 
Una duda un poco tonta...

Sería viable este escenario con un router cualquiera (un hap lite por ejemplo) acoplándole un módem usb 3G/4G?? (Nunca he usado un mikrotik con un dongle usb así que a lo mejor aquí ya está el problema).

Es para un amigo :p jajaja
 
Una duda un poco tonta...

Sería viable este escenario con un router cualquiera (un hap lite por ejemplo) acoplándole un módem usb 3G/4G?? (Nunca he usado un mikrotik con un dongle usb así que a lo mejor aquí ya está el problema).

Es para un amigo :p jajaja
Sí, claro. Si el módem es compatible y el mikrotik lo reconoce, sin problema.

Saludos!
 
Arriba