El servidor `srv05` actúa como puente entre la red LAN local `192.168.88.0/24` y la red VPN de Zerotier `10.241.0.0/16`, usando la interfaz `ztkse3ixxp`.

El objetivo era permitir que nodos de la VPN accedan a dispositivos dentro de la LAN hogareña, como por ejemplo un Raspberry Pi.

• ✅ `srv05` tiene IP `192.168.88.33` asignada a `lxcbr0`
• ✅ `ztkse3ixxp` está UP y tiene una IP válida `10.241.x.x`
• ✅ El Mikrotik tiene una ruta estática:

10.241.0.0/16 via 192.168.88.33

• ✅ El Mikrotik permite forwarding en ambos sentidos:

10.241.0.0/16 <--> 192.168.88.0/24

• ✅ Desde una máquina en la LAN se puede pingear a hosts de la VPN
• ✅ El `iptables` de `srv05` tiene reglas de FORWARD adecuadas:

sudo iptables -L FORWARD -n -v --line-numbers

-A FORWARD -s 10.241.0.0/16 -d 192.168.88.0/24 -i ztkse3ixxp -o lxcbr0 -j ACCEPT
-A FORWARD -s 192.168.88.0/24 -d 10.241.0.0/16 -i lxcbr0 -o ztkse3ixxp -m state --state RELATED,ESTABLISHED -j ACCEPT

Desde la VPN no se podía acceder a la LAN (el tráfico era dropeado en `srv05`). Se verificó el tráfico con:

sudo iptables -I FORWARD 1 -j LOG --log-prefix "FORWARD TRACE: " --log-level 4
tail -f /var/log/syslog | grep "FORWARD DROP:"

Se encontró que el paquete llegaba por `ztkse3ixxp` y salía por `lxcbr0`, pero era dropeado.

Existía una regla obsoleta en `iptables -t nat`:

-A POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.84

Esa IP ya no estaba asignada a ninguna interfaz, lo que provocaba un SNAT inválido y rompía el tráfico.

1. Se eliminó la regla inválida:

sudo iptables -t nat -L POSTROUTING -n --line-numbers
sudo iptables -t nat -D POSTROUTING <número de línea>

1. Verificación posterior:

sudo iptables -t nat -S

1. Se comprobó que el tráfico funciona incluso sin SNAT, dado que:
   • El Mikrotik enruta correctamente.
   • No se necesita ocultar el origen.
   • Es mejor para trazabilidad (los logs muestran la IP real del origen).

ip a                    # Ver interfaces y direcciones
ip r                    # Ver rutas
ip route get <IP>       # Ruta efectiva hacia un destino

sudo iptables -L FORWARD -v -n --line-numbers
sudo iptables -t nat -L POSTROUTING -n --line-numbers
sudo iptables -t nat -S
sudo iptables -S

sudo apt install iptables-persistent
sudo iptables-save | sudo tee /etc/iptables/rules.v4 > /dev/null

Evitar tener múltiples reglas `SNAT` que afecten la misma subred y salida. Documentar cambios en el Mikrotik (rutas, firewall) para trazabilidad.

El host `srv05` actúa como gateway entre la red VPN de Zerotier (`10.241.0.0/16`) y la red LAN del homelab (`192.168.88.0/24`). Para habilitar esta conectividad, se configuraron reglas de IPTables tanto en la tabla `filter` como en `nat`, y se verificó el ruteo en el router Mikrotik.

# Tabla filter
-A FORWARD -s 10.241.0.0/16 -d 192.168.88.0/24 -j ACCEPT
-A FORWARD -s 192.168.88.0/24 -d 10.241.0.0/16 -j ACCEPT

# Tabla nat
-A POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.33

• Sin necesidad de SNAT si el Mikrotik tiene ruta estática: Si el router Mikrotik sabe que puede alcanzar `10.241.0.0/16` vía `192.168.88.33`, no hace falta la regla SNAT. Sin embargo, puede ser útil para debugging o si el router impone restricciones por subred.
• Reglas basadas en subredes en lugar de interfaces: Esto hace más robusta la configuración frente a cambios de nombres de interfaces.
• La dirección `192.168.88.84` usada en versiones anteriores fue deprecada. Revisar la tabla NAT con `iptables -t nat -S` y eliminar reglas obsoletas.
• `ip a` y `ip r` son comandos útiles para verificar interfaces y rutas actuales.

Agregar una regla temporal al inicio de la cadena FORWARD para ver todo el tráfico que pasa (no solo el dropeado):

sudo iptables -I FORWARD 1 -j LOG --log-prefix "FORWARD TRACE: " --log-level 4

Esto logueará *todo* el tráfico que pase por FORWARD, no solo lo que se dropea. Ideal para observar si el tráfico llega pero no coincide con alguna regla `ACCEPT`.

Ver los logs:

tail -f /var/log/syslog | grep "FORWARD TRACE:"

Once you've found the issue, remember to remove the logging rule to avoid excessive log entries:

sudo iptables -D FORWARD -j LOG --log-prefix "FORWARD TRACE: " --log-level 4

sysctl net.ipv4.ip_forward
sudo sysctl -w net.ipv4.ip_forward=1

Para hacerlo persistente:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

sudo iptables -t nat -S

Eliminar entradas incorrectas:

sudo iptables -t nat -D POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.84

ip route

Debe haber rutas activas hacia ambas redes (`10.241.0.0/16` y `192.168.88.0/24`), y las interfaces deben estar UP (`ip a`).

• Debe existir una ruta estática:

`10.241.0.0/16 → vía 192.168.88.33`

• Forwarding habilitado entre LAN y VPN.
• NAT deshabilitado o con reglas explícitas de aceptación.

Este anexo forma una guía de referencia rápida para resolver problemas de enrutamiento y NAT entre una red VPN virtualizada y un entorno de red de contenedores.