← Volver al inicio

Split Tunneling en WireGuard con AllowedIPs

En WireGuard el parámetro AllowedIPs funciona como filtro ACL y tabla de enrutamiento a la vez. NetRoute Pro genera la cadena AllowedIPs lista desde los dominios de cualquier sitio — no necesitas comandos ip route adicionales, solo edita el config del peer y recarga.

Sintaxis del comando

Sintaxis:

AllowedIPs = <CIDR1>, <CIDR2>, <CIDR3>

Ejemplo:

AllowedIPs = 1.1.1.0/24, 8.8.8.0/24, 162.159.0.0/16

Añade a la sección [Peer] de wg0.conf. Documentado en el quickstart oficial de WireGuard.

Requisitos previos

Paso 1. Genera AllowedIPs en NetRoute Pro

  1. Abre el sitio web objetivo en Chrome
  2. Lanza la extensión NetRoute Pro
  3. Selecciona la plataforma WireGuard
  4. Haz clic en Analyze Website
  5. Copia la línea AllowedIPs generada
Consejo: activa optimización RIPE BGP en la extensión — reemplaza IPs individuales con prefijos BGP anunciados reales, dando rutas estables que no se rompen cuando Cloudflare/Fastly rotan IPs. Importante: RIPE BGP devuelve todos los prefijos anunciados por el AS — para CDN multi-tenant (Cloudflare AS13335, AWS AS16509, DigitalOcean AS14061) son decenas de miles de IPs cubriendo sitios sin relación. Usa optimización BGP para AS single-tenant; mantén /24 CIDR para CDN compartidos.

Paso 2. Pega en config del peer

Linux (wg-quick)

Edita el archivo de configuración, normalmente /etc/wireguard/wg0.conf. En la sección [Peer] reemplaza el valor de AllowedIPs:

[Interface]
PrivateKey = <tu-clave-privada>
Address = 10.8.0.2/24

[Peer]
PublicKey = <clave-publica-servidor>
Endpoint = vpn.example.com:51820
AllowedIPs = 104.21.32.0/24, 172.67.0.0/16, 162.159.128.0/19
PersistentKeepalive = 25

Windows / macOS (GUI)

  1. Abre la app WireGuard
  2. Selecciona tu túnel y pulsa Edit tunnel
  3. Modifica la línea AllowedIPs en la sección [Peer]
  4. Pulsa Save

Android / iOS

  1. Abre la app WireGuard
  2. Pulsa tu túnel para editarlo
  3. Modifica el campo Allowed IPs
  4. Pulsa Save explícitamente — la app a veces resetea cambios al salir

Paso 3. Reinicia el túnel

DNS leak — lectura obligatoria

WireGuard mediante AllowedIPs enruta tráfico por IP. No enruta DNS. Tu navegador sigue preguntando al resolver del sistema (normalmente del ISP, vía DHCP) por example.com — sólo el tráfico IP resultante pasa por el túnel. El ISP ve qué sitios visitas aunque los datos estén cifrados.

Tres opciones, según el modelo de amenazas:

  1. Ocultar DNS del ISP totalmente (split-DNS via wg-quick). Añade una línea DNS = en [Interface] — wg-quick la aplica al levantar el túnel: 
    [Interface]
PrivateKey = ...
Address    = 10.0.0.2/24
DNS        = 10.0.0.1, ~example.com, ~another-site.com
    Las entradas ~dominio hacen que systemd-resolved use el DNS de la VPN sólo para esos dominios (split-DNS). Sin ellas, todo el DNS pasa por la VPN.
  2. Reducir visibilidad para el ISP (DoH/DoT público). Usa un resolver público para todo: 
    DNS = 1.1.1.1, 1.0.0.1
    El ISP deja de ver consultas de dominio; Cloudflare sí.
  3. Aceptar la fuga. Omite la línea DNS — sólo se cifra el tráfico, los lookups quedan en el resolver por defecto. Aceptable si sólo quieres desbloquear contenido.

Verifica con dnsleaktest.com o browserleaks.com/dns — el resolver mostrado debe ser el de tu VPN o DoH elegido, no el del ISP.

Fugas de IP a nivel de navegador (WebRTC)

Aun con el split tunneling correctamente configurado a nivel de SO, JavaScript en una página puede usar WebRTC (STUN/ICE) para descubrir tu IP local y pública reales, eludiendo la VPN. Esto es por diseño (los P2P de vídeo/audio necesitan direcciones directas), no un bug — pero es una fuga que la VPN no puede prevenir a nivel de red.

Fuga por IPv6 dual-stack

Las entradas AllowedIPs de WireGuard son específicas de la familia de direcciones. Si sólo listaste prefijos IPv4, el tráfico al mismo dominio por IPv6 (preferido por la mayoría de sitios modernos según RFC 6724) elude el túnel y sale por la ruta v6 por defecto del ISP.

Dos soluciones:

Fail-closed (kill switch)

Cuando el túnel WireGuard cae (cambio de red, parada manual, fallo de ruteo), el kernel elimina las rutas asociadas a la interfaz wg — y el tráfico a los CIDR antes tunelizados se filtra por la ruta por defecto. Usa los hooks PostUp/PostDown de wg-quick para reglas de firewall vinculadas al ciclo del túnel:

[Interface]
PrivateKey = ...
Address    = 10.0.0.2/24

# Fail-closed: descarta tráfico a los CIDR tunelizados a menos que vaya por %i (este túnel)
PostUp = iptables -I OUTPUT ! -o %i -d 1.1.1.0/24 -j REJECT
PostUp = iptables -I OUTPUT ! -o %i -d 8.8.8.0/24 -j REJECT
PostDown = iptables -D OUTPUT ! -o %i -d 1.1.1.0/24 -j REJECT
PostDown = iptables -D OUTPUT ! -o %i -d 8.8.8.0/24 -j REJECT

%i se sustituye por el nombre real de la interfaz (p.ej. wg0). Con el túnel arriba, el tráfico va por él; al bajarlo con wg-quick down, las reglas se quitan. Si el túnel se cae sin ejecutar PostDown, los CIDR siguen bloqueados — modo de fallo seguro (bloquea, no filtra).

Avanzado: Table = off

Por defecto wg-quick instala una ruta por cada CIDR de AllowedIPs en la tabla principal. Definir Table = off bajo [Interface] le dice a wg-quick que no instale rutas automáticamente — tú gestionas el ruteo con PostUp/PostDown. Útil cuando necesitas ruteo por políticas (por IP origen, marca, proceso), una tabla de ruteo personalizada o integración con frr/bird/quagga.

[Interface]
PrivateKey = ...
Address    = 10.0.0.2/24
Table      = off       # no auto-instalar rutas

# Gestiona tus rutas — ejemplo de policy routing:
PostUp = ip route add 1.1.1.0/24 dev %i table 100
PostUp = ip rule  add from 192.168.1.100 lookup 100
PostDown = ip rule  del from 192.168.1.100 lookup 100
PostDown = ip route flush table 100

La mayoría no necesita esto — el comportamiento por defecto (auto-instalar rutas desde AllowedIPs) es lo que la salida de NetRoute Pro espera.

Verificar

Comprueba que los cambios se aplicaron:

sudo wg show

Verás el peer con los AllowedIPs aplicados. Desde un cliente, comprueba el enrutamiento:

ip route get 104.21.32.1    # Linux
tracert example.com         # Windows

Problemas comunes

Las páginas se cuelgan o cargan a medias (agujero negro de PMTU)

Síntoma: una página empieza a cargar, llegan los primeros KB, luego se congela; o algunos sitios funcionan y otros se quedan. Es un clásico path MTU black hole — los paquetes grandes se fragmentan en el camino, las respuestas ICMP “fragmentation needed” las descarta un firewall upstream, y el emisor retransmite a ciegas.

El MTU por defecto de WireGuard es 1420 (o 1280 por IPv6). En PPPoE el enlace real es 1492; en 4G/LTE suele ser 1400; en algunos CGNAT 1280. Baja el MTU en [Interface]:

[Interface]
MTU = 1380     # prueba 1380; baja a 1280 / 1200 si las páginas siguen colgándose

En routers que reenvían a través del túnel (cliente WG en un router con LAN), además fija el MSS de TCP para que los clientes downstream no superen el PMTU:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

Se perdió toda la conexión a internet

Eliminaste 0.0.0.0/0 del AllowedIPs pero los prefijos listados no cubren las subredes que quieres usar. Añade las subredes específicas o regenera con más dominios en NetRoute Pro.

Android: el túnel se queda en "connecting" infinito

La app no guardó la configuración. Edita de nuevo y pulsa Save explícitamente antes de salir.

Error: AllowedIPs has invalid format

Revisa comas, espacios y saltos de línea en la cadena. AllowedIPs debe estar en una sola línea con prefijos separados por coma, p.ej. 10.0.0.0/8, 192.168.1.0/24.

Ruta añadida pero el tráfico no va por el túnel

Archivo de configuración de ejemplo

Plantilla lista para editar con comentarios. Reemplaza las rutas de ejemplo con la salida de NetRoute Pro para tus sitios.


# Example WireGuard peer config with split tunneling.
# Generated by NetRoute Pro: https://alexander2k.github.io/netroute-site/
#
# AllowedIPs in [Peer] section doubles as both an ACL and routing table.
# Only the listed networks are sent through the tunnel — everything else
# uses the default route. Replace placeholders with your real keys/addresses.

[Interface]
PrivateKey = YOUR_CLIENT_PRIVATE_KEY
Address    = 10.0.0.2/24
DNS        = 1.1.1.1

[Peer]
PublicKey           = YOUR_SERVER_PUBLIC_KEY
Endpoint            = your.vpn.server:51820
PersistentKeepalive = 25

# Networks to route via VPN — add/remove based on NetRoute Pro output.
AllowedIPs = 1.1.1.0/24, 8.8.8.0/24, 162.159.0.0/16

# To route everything via VPN, use: AllowedIPs = 0.0.0.0/0, ::/0
# Apply with: sudo wg-quick down wg0 && sudo wg-quick up wg0

Consejo: ¿Necesitas un config sin estas líneas de comentarios? En las opciones de NetRoute Pro desactiva «Incluir comentarios en archivos exportados» — la extensión exportará solo los comandos de rutas. Útil para routers que no toleran comentarios.

Ver todos los ejemplos en GitHub →

Documentación oficial

¿Listo para probar?

NetRoute Pro — extensión gratuita de Chrome para generar rutas desde cualquier sitio web.

Instalar extensión