Lecciones aprendidas y comandos de diagnóstico rápido. Leer esta página primero ante cualquier problema de "no conecta" o "no llega el tráfico".
| Qué revisar | Dónde | Comando |
|---|---|---|
| Estado del túnel y handshakes | LXC 105 | wg show |
| Reglas de firewall interno del túnel | LXC 105 | nft list chain ip filter FORWARD |
| Reglas de firewall del datacenter | Host Proxmox | cat /etc/pve/firewall/cluster.fw |
| Reglas NAT/DNAT | Host Proxmox | iptables -t nat -L -n -v |
| Firewall específico de una VM/LXC | Host Proxmox | cat /etc/pve/firewall/<ID>.fw |
ufw de un LXC específico |
Host Proxmox | pct exec <ID> -- ufw status |
| Ver tráfico entrante en tiempo real | LXC 105 | tcpdump -i eth0 udp port 51820 -n |
| IP pública actual (comparar con IPSET) | Cualquier PC | https://ifconfig.me |
ufw / Windows Firewall)cluster.fw + <ID>.fw por VM) — aplica a TODO el tráficonft sobre wg0) — aplica SOLO al tráfico que pasa por el túnel WireGuardSi abres un puerto nuevo en un servidor pero necesitas acceso a él también vía WireGuard, hay que agregar la regla equivalente en la capa 3. Si se olvida, el servicio funciona en LAN directa pero falla específicamente cuando WireGuard está conectado — síntoma confuso porque parece intermitente.
Caso real: el panel de Nginx Proxy Manager (puerto 81) funcionaba sin WireGuard pero se bloqueaba con WireGuard encendido, hasta agregar la regla
nftcorrespondiente en el LXC 105.
Ver detalle completo en WireGuard — Configuración. Resumen: usar 192.168.100.105 como origen en reglas, nunca 10.20.20.0/24.
Se diagnosticó casi una hora un "bloqueo" de SQL Server que en realidad era que SQL Server nunca tuvo el protocolo TCP/IP habilitado (común en instalaciones default de SQL Express) — el puerto 1433 no tenía nada escuchando. El firewall estaba correctamente configurado desde el principio.
Orden correcto de diagnóstico, de adentro hacia afuera:
netstat -an | findstr <PUERTO> (Windows) o ss -tlnp | grep <PUERTO> (Linux) en el propio servidor — ¿el servicio SÍ escucha ahí?<ID>.fw), si está activonft en LXC 105) — solo si aplicaTest-NetConnection <IP> -Port <PUERTO> ejecutado desde la misma IP de destino da un falso negativo confuso (tráfico loopback, nunca sale a la red real). Siempre verifica el campo SourceAddress del resultado — si es igual a RemoteAddress, estás probando en la máquina equivocada.
hwaddr=Ver Bug de NAT con firewall=1 para el detalle completo.
Docker crea sus propias cadenas de iptables (DOCKER, DOCKER-USER, DOCKER-FORWARD) y una regla MASQUERADE para su red interna (172.17.0.0/16) — instalarlo por accidente en el host puede interferir con las reglas DNAT/MASQUERADE de WireGuard, RustDesk, nginx-proxy, etc.
Si pasa por accidente, limpieza completa:
docker compose down -v
apt purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
apt autoremove -y
rm -rf /var/lib/docker /etc/docker
# Limpiar cadenas residuales en filter
iptables -D FORWARD -j DOCKER-USER 2>/dev/null
iptables -D FORWARD -j DOCKER-FORWARD 2>/dev/null
iptables -F DOCKER; iptables -F DOCKER-USER; iptables -F DOCKER-BRIDGE; iptables -F DOCKER-CT; iptables -F DOCKER-FORWARD; iptables -F DOCKER-INTERNAL
iptables -X DOCKER; iptables -X DOCKER-USER; iptables -X DOCKER-BRIDGE; iptables -X DOCKER-CT; iptables -X DOCKER-FORWARD; iptables -X DOCKER-INTERNAL
# Limpiar cadena residual en nat (quitar referencias en OUTPUT/POSTROUTING antes de borrar la cadena)
iptables -t nat -L OUTPUT -n --line-numbers | grep -i docker # identificar línea, luego:
iptables -t nat -D OUTPUT <linea>
iptables -t nat -L POSTROUTING -n --line-numbers | grep -i docker # identificar línea, luego:
iptables -t nat -D POSTROUTING <linea>
iptables -t nat -F DOCKER; iptables -t nat -X DOCKER
netfilter-persistent save
Siempre verificar después que las reglas DNAT/MASQUERADE propias sigan intactas y probar WireGuard + acceso público antes de dar por cerrado.
iptables -t nat) se persisten con netfilter-persistent save — si agregas un DNAT nuevo, no olvides correr esto después.nft dentro del LXC 105 se persisten con nft list ruleset > /etc/nftables.conf — no olvides regenerarlo después de cualquier cambio./etc/pve/firewall/*.fw se guardan automáticamente (viven en el filesystem cluster de Proxmox), solo hace falta pve-firewall compile para aplicarlos.