VPNSmith
self-host-vpnINFO

Plantillas de configuración WireGuard 2026 (listas para usar)

8 plantillas wg0.conf listas para producción: VPN casa, kill-switch viaje, multi-peer, hub-and-spoke, ajuste MTU. Copia, pega, adapta. Setup en 5 min.

Por Eric Gerard · Fundador · VPNSmith - Especialista en VPN self-host y VPS GDPR10 min de lecturaFoto vía Unsplash

Instalaste WireGuard en tu VPS. Leíste tres tutoriales contradictorios. El wg0.conf que pegas no hace ping, o sí pero el DNS se filtra, o el kill switch corta tu máquina entera al desconectar el túnel. La causa es casi siempre la misma: una plantilla copiada sin entender su contexto original.

Esta guía propone 8 plantillas wg0.conf listas para producción sobre Contabo Cloud VPS 10, con el caso de uso, las trampas conocidas y las 4 líneas a adaptar. Eliges la que coincide con tu escenario, ajustas claves, te conectas. Cinco minutos.

Por qué usar plantillas en lugar de generar todo a mano

WireGuard es conocido por tener una configuración minimalista comparada con OpenVPN, pero minimalista no quiere decir trivial. Cada sección tiene un significado implícito que los tutoriales copian-pegan sin explicar, y el mínimo mal valor puede o bien hacer que el túnel falle, o bien hacer fugar el tráfico en claro sin ningún síntoma visible inmediato. En los últimos seis meses hemos contado más de veinte threads Reddit donde principiantes hacían la misma pregunta: «mi túnel sube, el ping pasa hacia el servidor, pero ninguna conexión HTTP funciona desde el cliente». En 9 de cada 10 casos era un AllowedIPs mal colocado o un PostUp PostDown que faltaba.

Las plantillas a continuación cubren 8 escenarios de despliegue distintos y reales. Cada una lleva un comentario de contexto que describe para quién está hecho, qué garantiza y los límites conocidos. Si tu caso coincide con la plantilla al 80 %, adaptas el 20 % restante; si tu caso no está en ninguna plantilla, reconstruyes a partir de la más cercana quedándote solo con las directivas que te conciernen. Es más rápido que partir de cero y más fiable que reparchear desde un tutorial Stack Overflow random de 2020.

La otra razón para usar plantillas es el mantenimiento a largo plazo. Cuando WireGuard 1.1 salga (probablemente en 2026-2027) con cambios de directivas, republicaremos las plantillas con los ajustes claramente marcados, y sabrás exactamente qué línea actualizar en tu wg0.conf. Es el equivalente VPN de un manifiesto Kubernetes versionado - el valor no está en el contenido inicial, sino en la capacidad de iterar limpiamente sobre él.

Convenciones comunes

Todas las plantillas siguen las mismas reglas - simplifica tu mental model:

  • Subred cliente: 10.66.66.0/24 (peers .2 → .254)
  • Interfaz pública servidor: eth0 (comprueba con ip route | awk '/default/ {print $5}')
  • Puerto UDP: 51820 (modificable y debe abrirse en el firewall; ver plantilla 7 ofuscación)
  • Claves: generadas con wg genkey | tee server.key | wg pubkey > server.pub
  • Sysctl: net.ipv4.ip_forward=1 activado en servidor (/etc/sysctl.conf)
  • MTU: 1420 por defecto, ajustado cuando sea necesario

Los bloques PrivateKey son placeholders - reemplaza por los tuyos. Nunca commitees estos ficheros en un repo público.

Plantilla 1 - Servidor WireGuard estándar (1 cliente roadwarrior)

El caso más común: tu VPS Contabo expone un túnel para tu MacBook de viaje.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Lado cliente:

# /etc/wireguard/wg0.conf (cliente macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Puntos a vigilar:

  • AllowedIPs = 0.0.0.0/0, ::/0 enruta TODO el tráfico cliente vía el VPS.
  • PersistentKeepalive = 25 obligatorio si el cliente está detrás de NAT (hotel, 4G) - sin esto, el túnel muere tras ~3 min de inactividad.
  • DNS = 9.9.9.9 fuerza resolución Quad9 - si no, el cliente usa DNS local y tus queries se filtran.

Plantilla 2 - VPN casa (split-tunnel: LAN local excluida)

Quieres VPN para tu tráfico web pero mantener acceso al LAN local (impresora, NAS) sin pasar por el túnel.

# Cliente casa
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Todo salvo RFC1918 LAN + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

El truco de las subredes fragmentadas (en lugar de 0.0.0.0/0) hace que WireGuard añada rutas específicas que no pisan la ruta por defecto. Tu 192.168.x.x y 10.x.x.x LAN quedan accesibles directamente.

Plantilla 3 - VPN viaje con kill switch netfilter estricto

Viajas a China, Irán, Rusia. Si el túnel cae, nada debe filtrarse. Solución: kill switch netfilter que descarta todo salvo tráfico vía wg0 y el handshake servidor.

# Cliente viaje kill-switch
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Estas 4 líneas PostUp/PreDown son el verdadero kill switch - no un popup de aplicación. Mientras wg-quick down wg0 no se ejecute, ningún paquete sale de la interfaz que no esté marcado por WireGuard.

MTU a 1280 para redes caprichosas (hoteles, 3G). Mejor perder 1% de débito que tener un túnel inestable.

Plantilla 4 - Multi-peer (5 dispositivos, mismo usuario)

Cables de red de fibra óptica iluminados
Cables de red de fibra óptica iluminados

Tienes MacBook, iPhone, iPad, VPS de trabajo, Raspberry Pi. Los quieres enrutar todos por el mismo VPN con subredes separadas para monitoring.

[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# Worker VPS (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi home
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Cada peer tiene IP fija en la subred 10.66.66.0/24. Si monitorizas vía Prometheus (ver guía monitoring), puedes etiquetar por IP y saber quién consume cuánto.

Plantilla 5 - Hub-and-spoke (peer-to-peer entre clientes)

Por defecto WireGuard no enruta entre peers. Si quieres que tu iPhone hable con tu Raspberry Pi por el hub servidor:

En el servidor, añade:

sysctl -w net.ipv4.ip_forward=1

Y en los bloques [Peer] del servidor, pon AllowedIPs = 10.66.66.X/32 (IP única del peer).

En los clientes, modifica AllowedIPs:

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Subred entera, no solo 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Con esto, desde tu iPhone (10.66.66.3) puedes ssh pi@10.66.66.6 directamente - el hub reenvía.

Plantilla 6 - Restricción de salida por peer (allowlist)

Caso avanzado: un peer (tu hijo, un invitado, un servicio automatizado) debe poder conectarse al túnel pero solo hacia ciertos dominios/IP.

Añade en el PostUp del servidor (además del MASQUERADE):

iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

El peer 10.66.66.50 solo puede alcanzar 1.1.1.1 (DNS) e IPs Google. Todo lo demás se rechaza.

Plantilla 7 - Ofuscación puerto 443 vía udp2raw

Algunos firewalls corporativos bloquean UDP saliente. Solución: encapsular WireGuard en fake TCP/443 vía udp2raw.

Lado servidor:

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Lado cliente:

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

En el wg0.conf cliente, cambia Endpoint:

Endpoint = 127.0.0.1:50000

El débito cae (~30% overhead) pero atraviesa casi cualquier DPI corporativo.

Plantilla 8 - Site-to-site (dos LANs unidas)

Dos casas, dos Raspberry Pi pasarela, un VPS Contabo como hub. Cada LAN ve la otra como si fuera local.

Servidor (VPS hub):

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Sitio A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Sitio B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Sitio A (Raspberry Pi):

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Activa ip_forward en ambos Raspberry y añade ruta estática en otras máquinas LAN si deben responder desde el otro sitio.

Diagnóstico rápido cuando nada funciona

Pegaste la plantilla, lanzas wg-quick up wg0, arranca - pero ping falla. Checklist en este orden:

  • wg show: ¿último handshake reciente? Si "never" → handshake KO, verifica Endpoint, puerto UDP en firewall servidor.
  • ip route en cliente: ¿ruta hacia subred VPN existe? Si no → AllowedIPs cliente mal configurado.
  • dig @9.9.9.9 ifconfig.me +short desde cliente conectado: ¿devuelve IP del VPS? Si no → MASQUERADE ausente en servidor, o ip_forward = 0.
  • tcpdump -i wg0 en servidor: ¿ves paquetes llegar? Si sí pero nada sale por eth0 → regla FORWARD/MASQUERADE ausente.
  • MTU: ping -M do -s 1400 1.1.1.1 desde cliente. Si "Frag needed" → reduce MTU en wg0.conf a 1380 o 1280. Nuestra guía para arreglar el MTU de WireGuard detalla la medición sin fragmentación y el valor correcto por tipo de enlace.

Si partes de cero, la guía Contabo paso a paso cubre la instalación completa desde el SSH inicial.

En producción: lo que estas plantillas no cubren

Son intencionadamente mínimas. Para uso prod long-term, prevé:

  • Backup regular de /etc/wireguard/
  • Rotación de claves cada 12-18 meses
  • Monitoring vía Prometheus + wireguard_exporter (ver guía monitoring)
  • Fail2ban en puerto UDP 51820 si ves intentos de port scan
  • Límite por peer vía tc (Linux traffic control)

Y sobre todo: nunca commitees un wg0.conf real en repo, ni privado.

Para profundizar

Si quieres entender por qué WireGuard es más rápido que OpenVPN a CPU equivalente, comparativa técnica detallada con benchmarks iperf3 reales sobre Contabo, kernel module vs userspace y perfil batería iPhone.

Y para la parte anti-fuga, la guía kill switch Linux iptables + systemd muestra cómo garantizar cero fugas incluso si WireGuard crashea.

¿Prefieres un asistente visual a los bloques INI en bruto? Nuestro generador de configuración WireGuard toma tu IP de servidor, la subred y el número de peers y genera un wg0.conf listo para pegar en menos de un minuto. Y para comprobar si el VPS Contabo S sale más barato que tu NordVPN actual a 2 años, usa nuestra calculadora de coste VPN autoalojado.

Todas las plantillas anteriores están diseñadas para correr sobre un Contabo Cloud VPS 10 - margen de sobra para un túnel de producción estable y otros servicios self-host en paralelo.

★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados

Ejecuta estas plantillas en un Contabo Cloud VPS 10 → 5,50 €/mesIPv4 pública · acceso root · margen de sobra para WireGuard + otros servicios self-host→

★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados

Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→

Preguntas frecuentes

¿Qué MTU elegir para WireGuard?
1420 por defecto cubre el 99% de enlaces fibra/4G. Si ves paquetes fragmentados (test ping -M do -s 1392), baja a 1380. En PPPoE encapsulado, 1392 o incluso 1280 pueden ser necesarios.
¿Por qué mi kill switch netfilter deja pasar IPv6?
Las reglas iptables PostUp solo cubren IPv4. Añade siempre las reglas ip6tables equivalentes - la plantilla 'kill-switch viaje' del guía las incluye.
¿Máximo de peers en un solo wg0?
WireGuard aguanta varios miles de peers sin degradación perceptible hasta ~10.000 si tienes la RAM. Para 50 usuarios en un Cloud VPS 10 a 5,50 €, sin problema.
AllowedIPs 0.0.0.0/0 vs los rangos fragmentados del split-tunnel - ¿qué diferencia hay?
0.0.0.0/0 en el cliente envía TODO el tráfico por el VPS (túnel completo). Para mantener accesible tu LAN local (impresora, NAS) lo sustituyes por los rangos fragmentados de la Plantilla 2: WireGuard instala entonces rutas específicas que no sobrescriben tu ruta por defecto, así que 192.168.x.x y 10.x.x.x siguen siendo directos.
PersistentKeepalive - ¿cuándo es realmente necesario?
Pon PersistentKeepalive = 25 en cualquier cliente detrás de NAT (Wi-Fi de hotel, 4G/5G, CGNAT). Envía un paquete diminuto cada 25 s para mantener abierto el mapeo NAT; sin él el túnel se queda en silencio y muere tras unos 3 minutos de inactividad. Un servidor con IP pública no lo necesita en sus bloques peer.
Artículos relacionados

Para profundizar