VPN de oficina + VLAN: conectar segmentos de forma segura sin aplanar la red

El modelo mental: la VPN es un router, no un pasillo mágico

Las VLAN sirven para separar dominios de broadcast y crear límites administrativos. Las VPN sirven para transportar tráfico a través de una red no confiable o inconveniente.
Combínalas mal y no obtienes “acceso remoto seguro”. Obtienes “un camino más hacia todo”, con menos ojos encima.

Si recuerdas una cosa: un cliente VPN de acceso remoto es un host en una nueva interfaz. Necesita enrutamiento, DNS y políticas de firewall igual que cualquier otro host.
Tratarlo como “dentro” es la forma de aplanar la red sin siquiera notarlo.

Cómo suele verse el “aplanamiento”

• Los clientes VPN obtienen una dirección en una subred “confiable” que puede enrutar a todas las VLAN.
• Las reglas de firewall indican “VPN → LAN permitir” porque un ticket pidió “hacer que funcione”.
• El túnel dividido (split tunneling) está deshabilitado “por seguridad”, así que cada usuario remoto se convierte en un router en bucle a través de tu oficina.
• Nadie puede responder “qué usuario VPN accedió a qué servicio VLAN” sin adivinar.

El objetivo no es hacer la vida miserable a los usuarios VPN. El objetivo es que su acceso sea deliberado: redes específicas, puertos específicos, identidades específicas, con registros que resistan la luz del día.

Algunos datos (y un poco de historia) que cambian decisiones

1. Las VLAN nacieron de IEEE 802.1Q (finales de 1990) como forma de segmentación lógica en infraestructura de switching compartida. Nunca se pensaron como un sistema de control de acceso por sí solas.
2. IPsec fue diseñado para redes hostiles, pero en despliegues empresariales frecuentemente se usan políticas “permitir cualquier cosa” porque negociar “qué debe permitirse” es socialmente más difícil que la criptografía.
3. Los primeros accesos remotos VPN a menudo puenteaban capa 2 (dispositivos TAP, “modo bridge”), lo que hacía felices al descubrimiento de Windows y a protocolos legacy—y infelices a los equipos de seguridad más tarde.
4. NAT se convirtió en el estándar accidental para redes domésticas, por eso las VPN suelen pelearse con espacio RFC1918 superpuesto en 2025.
5. El split tunneling precede al moderno “Zero Trust” por décadas. No es automáticamente inseguro; es inseguro cuando no controlas la postura del dispositivo y la política de egreso.
6. La segmentación de red históricamente vino de necesidades de fiabilidad tanto como de seguridad: limitar tormentas de broadcast y aislar fallos fue un motor práctico mucho antes de que el ransomware llenara las presentaciones.
7. 802.1X NAC (autenticación por puerto) intentó convertir “¿quién está en este puerto?” en una pregunta de primera clase. Muchas organizaciones todavía no lo despliegan porque exige disciplina operativa.
8. El pensamiento “VPN dentro del perímetro” es un vestigio de cuando “dentro” significaba “empleados en escritorios corporativos”. BYOD y SaaS convirtieron eso en folclore.

La conclusión: las VLAN son límites, las VPN son transporte. La seguridad sucede en la política de enrutamiento, reglas de firewall, identidad y registro. No en buenas intenciones.

Objetivos de diseño que evitan la “red plana por accidente”

1) Alcance explícito: menos rutas, no más esperanza

Tu VPN solo debería anunciar lo que un grupo de usuarios necesita. Si el cliente puede enrutar a todas las VLAN, alguien lo intentará eventualmente. A veces por accidente, a veces no.
Un diseño limpio usa empujes de rutas por grupo, o AllowedIPs por peer (WireGuard), o al menos firewall por pool de direcciones.

2) Hacer cumplir la segmentación en capa 3/4 (y a veces 7)

Las VLAN mantienen el switching ordenado. Los firewalls mantienen el negocio ordenado. Pon la aplicación de políticas donde puedas registrarla, revisarla y probarla: en el límite inter‑VLAN y en el ingreso de la VPN.
“Pero el switch soporta ACLs” es cierto—y también la forma en que terminas con reglas que nadie puede auditar.

3) No conviertas la VPN en un tránsito hacia toda Internet a menos que lo planees

El túnel completo VPN a veces es necesario (entornos regulados, control estricto de egreso, viajes hostiles). Pero es una elección costosa:
ancho de banda, latencia, carga en el firewall de la oficina y los inevitables tickets de “Zoom va lento”.
Si haces túnel completo, diseña para ello: capacidad, QoS y controles de egreso claros.

4) Haz visible la identidad en los registros

“10.9.0.23 accedió a 10.20.30.40” es pobre. Quieres “alice@corp en dispositivo X accedió a finance-api en puerto 443.”
Eso requiere autenticación VPN ligada a identidad (SAML/OIDC/RADIUS) y registros que incluyan usuario, IP asignada y tiempos de sesión.

5) Haz que los solapamientos y el crecimiento sean aburridos

La proliferación de VLAN ocurre. También las fusiones y adquisiciones. Planifica tu espacio de direcciones para poder añadir segmentos sin renumerar, y evita solapamientos con redes domésticas comunes.
Si tu LAN es 192.168.0.0/16, te mereces el dolor futuro que estás por tener.

Broma #1: “Permitiremos VPN → LAN por ahora” es como “malabarearé con motosierras hasta que se vaya el auditor.” Funciona hasta el momento en que deja de funcionar.

Arquitecturas recomendadas (y cuándo usarlas)

Patrón A: la VPN aterriza en una VLAN dedicada “usuarios VPN” + enrutamiento estricto

Este es el caballo de batalla. Los usuarios VPN obtienen un pool de IP que mapea a una VLAN dedicada o interfaz enrutada (no tiene que ser una VLAN, pero suele serlo).
El enrutamiento inter‑VLAN desde ese segmento se controla mediante política de firewall.

Cuándo usar: La mayoría de oficinas, especialmente cuando tienes múltiples VLAN internas (corp, servidores, VoIP, impresoras, IoT, guest).

Por qué es bueno: Un punto de estrangulamiento. Un lugar para registrar. Puedes aplicar políticas distintas a usuarios VPN respecto a clientes locales en la misma VLAN “corp”.

Modo de fallo: Alguien se impacienta y añade “VPN → any allow” porque un servicio interno usa un rango de puertos efímeros y nadie quiso arreglar la app.

Patrón B: acceso por aplicación vía proxy inverso / bastión (sin acceso general a VLAN)

No todo necesita acceso a nivel de red. Las apps web internas pueden publicarse detrás de un proxy con control de identidad. SSH puede pasar por un bastión con certificados de corta duración.
RDP puede ser intermediado.

Cuándo usar: Entornos altamente regulados, organizaciones remotas por defecto o cuando la “red interna” es mayormente legacy y no confías en ella.

Por qué es bueno: Puedes dejar de fingir que “acceso de red” equivale a “acceso a la app.” No es así.

Modo de fallo: Los equipos lo eluden exponiendo puertos al azar “temporalmente.” Temporal es la unidad de tiempo más larga en TI.

Patrón C: VPN sitio a sitio entre oficinas con enrutamiento consciente de VLAN

Sitio a sitio es otro animal: dos dominios de enrutamiento, generalmente endpoints estables y presión para que todo hable con todo.
No lo hagas. Enruta solo las subredes necesarias entre sitios y mantén reglas de firewall inter‑sitio tan estrictas como toleres.

Cuándo usar: Sucursales, almacenes, tiendas, plantas.

Modo de fallo: Subredes solapadas (ambos sitios usan 10.0.0.0/24) y alguien “lo arregla” con NAT que luego rompe Kerberos, logging y troubleshooting.

Patrón D: segmentación basada en VRF + VPN por VRF

Si tienes un equipo de red serio y equipamiento que lo soporte, los VRF son la versión adulta de “muchas VLAN”.
Puedes ejecutar tablas de enrutamiento separadas (corp, OT, guest) y conectar la terminación VPN al VRF correcto con filtrado de rutas estricto.

Cuándo usar: Entornos medianos a grandes, o donde hay redes OT/ICS que no deben mezclarse.

Modo de fallo: El filtrado de rutas se convierte en “una excepción más” y de pronto tus VRF son un museo de compromisos pasados.

Enrutamiento + firewall: las reglas que realmente importan

Decide dónde sucede el enrutamiento inter‑VLAN

Elige uno: el switch central (SVIs), o un firewall/router. Si enrutas en el switch, todavía necesitas aplicación de políticas en algún sitio.
El modelo operativo más limpio es: el switch hace el forwarding L2/3, el firewall hace cumplir la política en los límites (vía enlaces enrutados, ACLs o diseños “firewall-on-a-stick”).

Mi sesgo: si te importa la segmentación como seguridad, aplícala en un firewall con registro. Los ACLs del switch están bien como barreras, no como tu historia principal de seguridad.

Política de ingreso VPN: trátala como una VLAN hostil

Los dispositivos remotos son variables. Incluso laptops corporativos pasan tiempo en Wi‑Fi de hotel, redes domésticas y cafeterías con portales cautivos diseñados por el caos.
Así que tu subred VPN debería tratarse más como “semi‑confiable” que como “LAN corp”.

• Permitir VPN → DNS (tus resolvers), NTP y las apps internas requeridas.
• Bloquear VPN → redes de gestión (switch, firewall, gestión de hipervisores) por defecto.
• Bloquear VPN → VLANs de usuarios a menos que tengas un caso de uso justificado (herramientas de helpdesk, etc.).
• Registrar denegaciones como alerta temprana. Luego afina para reducir ruido.

La publicidad de rutas es un control de seguridad

Los firewalls son tu última línea. El enrutamiento es tu primera línea. Si empujas rutas de cada subred a cada cliente, estás invitando al movimiento lateral.
En WireGuard, AllowedIPs es tanto “qué rutas instala el cliente” como “qué subredes de origen acepta el servidor.” Es poderoso. Úsalo.

Sé intencional con el split tunneling

Split tunnel significa que solo las subredes internas pasan por la VPN; el resto va directo. El riesgo no es “Internet.” El riesgo es un endpoint comprometido que puede hablar con ambos mundos.
Lo mitigas con comprobaciones de postura del dispositivo, seguridad endpoint y restringiendo lo que la VPN puede alcanzar.

Túnel completo significa que todo pasa por tu oficina. El riesgo es que tu oficina se convierta en el cuello de botella de todos y tus registros en una mina de privacidad y cumplimiento.
Elige según requisitos de control de egreso, no por miedo.

Una cita, porque sigue siendo cierta

La esperanza no es una estrategia. — idea parafraseada a menudo atribuida a ingenieros y operadores en círculos de confiabilidad

(No, no voy a apostar la seguridad de producción a la procedencia exacta de un eslogan. Tampoco deberías hacerlo tú.)

DNS, identidad y por qué pensar solo en IP falla

DNS: hazlo aburrido y consistente

Los usuarios VPN necesitan resolución de nombres que coincida con la realidad on‑prem, o acabarás con hosts shadow en archivos y IPs misteriosas en marcadores.
Usa DNS dividido: dominios internos resuelven vía resolvers internos; nombres públicos vía resolvers normales (o tu salida controlada si usas túnel completo).

Además: decide si los clientes VPN pueden resolver nombres internos a los que no pueden llegar. En entornos estrictos, podrías impedirlo intencionalmente para reducir reconocimiento.

Identidad: enlaza el acceso a quién, no solo a dónde

La segmentación VLAN es “dónde.” La VPN añade “cómo llegaste aquí.” Aún necesitas “quién”.
Si la autenticación de tu VPN es solo una PSK compartida, tienes una bomba de tiempo. Usa autenticación por usuario con MFA, certificados/llaves de corta duración y autorización basada en grupos.

Observabilidad: registros que respondan preguntas de seguridad

Quieres poder responder:

• ¿Qué usuario tenía la IP 10.90.0.14 a las 14:32?
• ¿Qué destinos internos contactó esa sesión?
• ¿Fue denegado por la política, y por qué?
• ¿Era este tráfico normal para su rol?

Si tu stack actual no puede responder eso sin una caza manual, arréglalo antes de expandir el alcance de la VPN.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son chequeos reales que puedes ejecutar durante el diseño y la respuesta a incidentes. Cada uno incluye: comando, qué significa la salida y la decisión que tomas.
Asume gateway/firewall VPN basado en Linux donde sea relevante; adapta a tu plataforma.

Tarea 1: Confirmar la interfaz VPN y la dirección asignada

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
vlan20@eth1      UP             10.20.0.1/24
vlan30@eth1      UP             10.30.0.1/24
wg0              UP             10.90.0.1/24

Significado: wg0 es tu interfaz VPN; el pool de clientes VPN es 10.90.0.0/24.

Decisión: Trata 10.90.0.0/24 como su propio segmento en la política de firewall. No lo mezcles con “LAN”.

Tarea 2: Verificar qué rutas deben alcanzar los clientes VPN

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.20.0.0/24 dev vlan20 proto kernel scope link src 10.20.0.1
10.30.0.0/24 dev vlan30 proto kernel scope link src 10.30.0.1
10.90.0.0/24 dev wg0 proto kernel scope link src 10.90.0.1

Significado: El gateway enruta entre VLAN20, VLAN30 y la subred VPN.

Decisión: Si no quieres que los clientes VPN lleguen a VLAN30, no te fíes de “lo bloquearemos después”. Elimina el empuje de rutas a clientes y añade denegaciones en el firewall.

Tarea 3: Comprobar peers de WireGuard y AllowedIPs (alcance de rutas)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: Jkq...redacted...
  listening port: 51820

peer: w9h...redacted...
  preshared key: (hidden)
  endpoint: 198.51.100.25:53644
  allowed ips: 10.90.0.23/32, 10.20.10.0/24
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 5.44 GiB sent

Significado: Este usuario puede originar tráfico como 10.90.0.23 y se le permite alcanzar (y/o enrutar) 10.20.10.0/24, dependiendo de tu topología.

Decisión: Ajusta allowed ips al mínimo necesario. Evita dar a un peer subredes amplias “por conveniencia”.

Tarea 4: Confirmar que el reenvío IP está habilitado en el gateway

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El sistema enruta entre interfaces.

Decisión: Si esperabas que el gateway fuera un endpoint estricto (sin enrutamiento), deshabilita el reenvío y rediseña. Si esperabas enrutamiento, mantenlo activado y aplica política de firewall.

Tarea 5: Inspeccionar la política por defecto del firewall (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iif "eth0" tcp dport 22 accept
    iif "eth0" udp dport 51820 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop
  }
}

Significado: Drop por defecto. La VPN puede alcanzar puertos TCP específicos en VLAN20, puede hacer DNS y está bloqueada explícitamente de VLAN30.

Decisión: Esta es la forma que quieres: listas de permisos explícitas, listas de negación explícitas cuando hacen falta y un deny por defecto que puedas explicar.

Tarea 6: Confirmar que la VPN no está haciendo NAT accidentalmente hacia la “LAN” confiable

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oif "eth0" masquerade
  }
}

Significado: Solo el tráfico hacia Internet se mascara por eth0. El tráfico interno VLAN no se está enmascarando.

Decisión: Evita NAT entre VPN y VLAN internas a menos que te veas forzado por subredes solapadas. NAT oculta identidad y complica el registro.

Tarea 7: Validar que el acceso inter‑VLAN está realmente bloqueado (desde un cliente VPN)

cr0x@server:~$ nc -vz 10.30.0.10 22
nc: connect to 10.30.0.10 port 22 (tcp) failed: Operation timed out

Significado: La conexión no se completa; probablemente bloqueada por la política del firewall (o enrutamiento/host caído).

Decisión: Confirma en los logs del firewall. Si ves “drop wg0→vlan30”, estás haciendo cumplir la segmentación correctamente.

Tarea 8: Verificar que el acceso a la app permitida funcione (y no sea más amplio de lo necesario)

cr0x@server:~$ nc -vz 10.20.0.50 5432
Connection to 10.20.0.50 5432 port [tcp/postgresql] succeeded!

Significado: El cliente VPN puede alcanzar el servicio Postgres en el puerto aprobado.

Decisión: Si este es el único acceso requerido, mantenlo así de restringido. Si la app necesita más puertos, documéntalos y considera un proxy a nivel de aplicación en lugar de ampliar la red.

Tarea 9: Comprobar PMTU y riesgo de fragmentación (clásico asesino de rendimiento VPN)

cr0x@server:~$ ping -M do -s 1360 10.90.0.1 -c 3
PING 10.90.0.1 (10.90.0.1) 1360(1388) bytes of data.
1368 bytes from 10.90.0.1: icmp_seq=1 ttl=64 time=22.1 ms
1368 bytes from 10.90.0.1: icmp_seq=2 ttl=64 time=21.7 ms
1368 bytes from 10.90.0.1: icmp_seq=3 ttl=64 time=21.9 ms

--- 10.90.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Significado: Una carga de 1360 bytes con DF establecido tiene éxito. Eso sugiere que tu MTU efectiva es al menos ~1388 en ese trayecto.

Decisión: Si esto falla, baja el MTU de la interfaz VPN (o arregla PMTUD). No “optimices” ignorando MTU; te optimizará a ti en forma de tickets.

Tarea 10: Capturar tráfico en la interfaz VPN para ver qué pasa realmente

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.90.0.23 and tcp port 5432 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:44:01.121901 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [S], seq 381909112, win 64240, options [mss 1360,sackOK,TS val 101 ecr 0,nop,wscale 7], length 0
12:44:01.138221 IP 10.20.0.50.5432 > 10.90.0.23.49212: Flags [S.], seq 21188218, ack 381909113, win 65160, options [mss 1460,sackOK,TS val 55 ecr 101,nop,wscale 7], length 0
12:44:01.138309 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [.], ack 1, win 502, options [nop,nop,TS val 102 ecr 55], length 0

Significado: SYN/SYN-ACK/ACK completa. El camino de red funciona; si la app sigue “caída”, probablemente sea autenticación, DNS o error de usuario—no enrutamiento.

Decisión: Deja de cambiar reglas de firewall. Escala a los propietarios de la app/servicio con pruebas.

Tarea 11: Confirmar la ruta de resolución DNS para nombres internos

cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Significado: El DNS para la interfaz VPN apunta a un resolvedor interno y el dominio de búsqueda está configurado.

Decisión: Si los usuarios VPN no resuelven *.corp.example, arregla las opciones DHCP para la VPN o la configuración que el cliente VPN recibe. No digas a los usuarios que “usen IPs”. Así es como los errores escalan a incidentes.

Tarea 12: Comprobar qué conexiones están activas y si están atascadas

cr0x@server:~$ ss -tnp | sed -n '1,12p'
State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
ESTAB   0       0        10.90.0.1:5432        10.90.0.23:49212   users:(("postgres",pid=2214,fd=7))
SYN-RECV 0      0        10.20.0.50:443        10.90.0.23:51044   users:(("nginx",pid=1893,fd=15))

Significado: La sesión DB establecida está sana. El SYN-RECV indica handshakes TCP medio abiertos—a menudo asimetría de firewall, problemas de ruta de retorno o MTU.

Decisión: Investiga la simetría de ruta y el seguimiento de estado del firewall; comprueba rutas de retorno desde 10.20.0.50 hacia 10.90.0.0/24.

Tarea 13: Verificar rutas de retorno desde una VLAN de servidor interna

cr0x@server:~$ ip route get 10.90.0.23 from 10.20.0.50 iif vlan20
10.90.0.23 from 10.20.0.50 iif vlan20
  via 10.20.0.1 dev vlan20 src 10.20.0.50 uid 0
    cache

Significado: Las respuestas desde VLAN20 irán vía el gateway en 10.20.0.1, que puede enrutar a wg0.

Decisión: Si esto apunta a otro router, tienes enrutamiento asimétrico. Arregla la puerta por defecto o añade una ruta estática. No lo “arregles” con NAT a menos que te guste depurar a ciegas.

Tarea 14: Revisar contadores del firewall para ver qué se está descartando

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop counter packets 1842 bytes 122004
  }
}

Significado: El tráfico de VPN a VLAN30 se está descartando, y no es hipotético—hay contadores.

Decisión: Decide si esto es esperado (bueno: previenes movimiento lateral) o indica una dependencia mal documentada (malo: la app realmente necesita VLAN30). En cualquier caso, ahora tienes evidencia.

Tarea 15: Medir CPU del gateway VPN y cuellos de botella criptográficos

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw)  12/28/2025  _x86_64_  (8 CPU)

01:02:11 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
01:02:12 PM  all  12.5  0.0  38.1   0.0    0.0  31.4    0.0    0.0    0.0   18.0
01:02:12 PM    3  10.0  0.0  44.0   0.0    0.0  42.0    0.0    0.0    0.0    4.0

Significado: Alto %soft y %sys sugiere que el procesamiento de paquetes está caliente; una CPU está casi saturada. Esto puede limitar el throughput.

Decisión: Considera habilitar multiqueue/ajuste de NIC, mover la terminación VPN a hardware más potente o usar una implementación en kernel. No culpes al “ISP” hasta que mires aquí.

Tarea 16: Revisar presión de conntrack (problema con firewalls stateful)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 183742
net.netfilter.nf_conntrack_max = 262144

Significado: Estás al ~70% de la capacidad de conntrack. Los picos pueden causar descartes y comportamientos extraños.

Decisión: Aumenta tamaños de conntrack y/o reduce flujos innecesarios (especialmente si haces túnel completo). Si estás full‑tunneling el streaming de todos, pagas el precio en estados.

Guía rápida de diagnóstico

Cuando la combinación VPN + VLAN “más o menos funciona” y todos proponen cambios aleatorios en el firewall, haz esto en su lugar.
El objetivo es encontrar el cuello de botella en minutos, no después de una semana de folklore.

Primero: aisla la clase de fallo

1. ¿Es alcanzabilidad? ¿Puede el cliente hacer ping a la IP del gateway VPN? ¿Puede alcanzar una IP de servicio interno conocida en un puerto conocido?
2. ¿Es resolución de nombres? ¿Resuelve el DNS interno? ¿Resuelve a la IP correcta para el segmento del usuario?
3. ¿Es política? ¿Los contadores/logs del firewall muestran descartes para esa IP origen y destino?
4. ¿Es rendimiento? ¿Pings pequeños funcionan pero transferencias grandes se estancan? Piensa MTU, CPU, conntrack y rutas asimétricas.

Segundo: comprueba la simetría de enrutamiento

1. Desde el gateway: existe ruta al VLAN destino.
2. Desde el VLAN destino: existe ruta de retorno a la subred VPN vía el mismo gateway.
3. En firewalls: el seguimiento de estado ve ambas direcciones en la misma caja.

Tercero: confirma las rutas instaladas en el cliente VPN

La mayoría de tickets “la VPN no llega al subnet X” son “el cliente nunca instaló la ruta a X” o “el cliente tiene una ruta más específica a una red local.”
Aquí es donde el solapamiento RFC1918 muerde.

Cuarto: prueba MTU temprano

Los problemas de MTU en VPN hacen perder tiempo porque se disfrazan de “lentitud aleatoria” y “algunos sitios funcionan, otros no.”
Ejecuta pings con DF y tamaños crecientes hasta hallar el techo, luego ajusta MTU intencionalmente.

Quinto: mira la capacidad en el punto de terminación

CPU alta en softirq, conntrack cerca del máximo, drops en los anillos de NIC o un proceso VPN monohilo en espacio de usuario pueden limitar el throughput.
Si haces túnel completo, asume que ahora eres un ISP. Actúa en consecuencia.

Errores comunes: síntoma → causa raíz → arreglo

1) “Los usuarios VPN pueden acceder a todo en todas las VLAN”

Síntoma: Revisión de seguridad encuentra que el pool VPN puede alcanzar impresoras, hipervisores y IPs de gestión al azar.

Causa raíz: La subred VPN tratada como “LAN confiable” y permitida a través de reglas de enrutamiento inter‑VLAN.

Arreglo: Coloca a usuarios VPN en una zona de política dedicada; cambia a política forward deny por defecto; allowlista solo puertos y destinos necesarios.

2) “Algunas apps internas funcionan, otras cuelgan o van muy lentas”

Síntoma: SSH funciona, pero transferencias de archivos se estancan; HTTPS carga parcialmente; RDP se congela.

Causa raíz: Fallo MTU/PMTUD sobre la VPN, a menudo con overhead de encapsulación y ICMP fragmentation-needed bloqueado.

Arreglo: Permite tipos ICMP relevantes; baja MTU de la interfaz VPN; prueba con pings DF; evita doble encapsulación donde sea posible.

3) “Ayer funcionaba; hoy solo una VLAN es inalcanzable desde la VPN”

Síntoma: La VPN puede alcanzar el VLAN de servidores pero no el VLAN corp, o viceversa.

Causa raíz: La ruta de retorno cambió (nuevo core switch, movimiento VRRP, ruta estática eliminada). El enrutamiento asimétrico rompe firewalls stateful.

Arreglo: Asegura que la puerta por defecto del VLAN destino devuelva tráfico vía el gateway/firewall VPN; añade rutas explícitas; evita enrutar alrededor del punto de aplicación de políticas.

4) “Después de habilitar túnel completo, Internet en la oficina fue terrible”

Síntoma: Todos se quejan y las gráficas muestran CPU del firewall y conteos de sesiones explotando.

Causa raíz: El túnel completo convirtió tu concentrador VPN en gateway de egreso sin planificación de capacidad; conntrack y tablas NAT se saturan.

Arreglo: Vuelve a túnel dividido con controles de postura, o escala el concentrador y la ruta de egreso; añade QoS; controla qué puede transitar.

5) “Los clientes VPN no pueden alcanzar subredes internas desde casa”

Síntoma: Subredes de oficina se solapan con routers domésticos; las rutas del cliente apuntan local en vez de a la VPN.

Causa raíz: Colisión en la planificación de direcciones (p. ej., la oficina usa 192.168.1.0/24).

Arreglo: Mejor: evita solapamientos mediante buena planificación corporativa (no uses rangos domésticos comunes).
Si lo heredas, último recurso es NAT por cliente en la VPN o renumeración. NAT funciona pero complica identidad, registros y algunos protocolos.

6) “DNS resuelve, pero los usuarios llegan al servicio equivocado”

Síntoma: El nombre resuelve a una IP alcanzable pero no es el entorno previsto (prod vs staging, oficina vs nube).

Causa raíz: Mala configuración de split DNS; dominios de búsqueda que provocan resoluciones FQDN inesperadas; múltiples zonas internas con registros inconsistentes.

Arreglo: Estandariza zonas DNS internas; configura explícitamente DNS de la VPN; audita dominios de búsqueda; registra consultas DNS desde el pool VPN para detectar temprano.

7) “Añadimos una ruta estática y ahora algo más falló”

Síntoma: Tras cambios de rutas, aparecen problemas extraños de conectividad entre VLANs.

Causa raíz: Filtrado de rutas entre VRFs o rutas más específicas accidentales que hacen que el tráfico evada la política del firewall.

Arreglo: Mantén el enrutamiento simple; documenta la intención de rutas; usa filtros de ruta; verifica con traceroute y contadores del firewall.

Tres mini-historias corporativas de la vida real

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía “buena segmentación”: VLAN separadas para usuarios, servidores, gestión, VoIP y Wi‑Fi de invitados.
Trabajadores remotos se conectaban por VPN, obtenían una IP y todo “simplemente funcionaba”. Lo celebraron como un éxito.

La suposición equivocada fue sutil: “Los usuarios VPN están básicamente en la VLAN de usuarios.” No lo estaban. Estaban en un pool VPN que el firewall trataba como “LAN”, porque alguien copió un conjunto de reglas antiguo.
Así, los clientes VPN podían enrutar al VLAN de gestión, que existía mayormente porque a los auditores les gustaba el diagrama.

Luego el portátil de un contratista se infectó fuera del sitio. Nada cinematográfico—solo un infostealer de commodity con descubrimiento de red incorporado.
Cuando el portátil se conectó por VPN, empezó a sondear. La interfaz de gestión de un hipervisor respondió. Luego un switch. Luego un dispositivo de backup con UI web.

El resultado no fue “apocalipsis ransomware instantáneo”, pero fue grave: reutilización de credenciales se convirtió en intentos de acceso no autorizados, y el escaneo ruidoso disparó alertas IDS que el equipo nunca había probado a ese volumen.
La respuesta a incidentes se centró en una pregunta: “¿Por qué un usuario VPN puede ver esto?”

Arreglarlo fue casi aburrido: crear una zona VPN dedicada, deny por defecto en forward, allowlist solo puertos de app necesarios y añadir denegaciones explícitas a gestión.
Lo vergonzoso fue la línea del postmortem: la segmentación existía en el papel, pero la VPN la eludía por completo.

Mini-historia 2: La optimización que salió mal

Otra organización decidió que el split tunneling era “inseguro”, así que pasaron a acceso remoto con túnel completo.
Todo el tráfico de internet de los laptops remotos se forzó a pasar por el firewall de la oficina, filtrado, registrado y NATeado por una única conexión ISP.

La primera semana pareció bien—porque el despliegue empezó con un grupo pequeño de ingenieros disciplinados que mayormente usaban SSH y herramientas internas.
La segunda semana incluyó al equipo de ventas, videoconferencias y un montón de pestañas del navegador reproduciendo desde vídeos de entrenamiento hasta activos grandes del CRM.

El firewall no se cayó. Simplemente se volvió el reloj de arena más caro del mundo. La CPU subió en softirq, conntrack se acercó al máximo y la latencia se convirtió en conversación diaria.
Los usuarios empezaron a alternar la VPN para poder trabajar, lo que destruyó el control que el equipo de seguridad quería.

El contragolpe no fue que el túnel completo sea siempre incorrecto. Fue que lo trataron como un cambio de política, no como un cambio arquitectónico.
No planificaron capacidad, no modelaron el tráfico y no definieron qué “internet remoto” debía permitirse transitar.

La solución fue volver al split tunnel con listas de permisos internas estrictas más comprobaciones de postura del dispositivo, y un perfil separado “viaje de alto riesgo” que usaba túnel completo cuando realmente hacía falta.
La gran victoria fue cultural: la organización dejó de creer que había un modo de VPN que lo resolvía todo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía con múltiples VLAN y una VPN de acceso remoto hizo algo poco popular: mantuvo una matriz viva de “quién puede acceder a qué”, ligada a objetos de firewall y grupos VPN.
Cada solicitud de cambio tenía que especificar el servicio destino, puerto y propietario del negocio. Sin propietario, sin acceso. La gente se quejó. En silencio.

Una mañana, un VLAN de servidores internos empezó a ver picos extraños de tráfico este‑oeste. No enormes, pero consistentes.
El monitoreo detectó patrones nuevos de conexiones desde la subred VPN hacia rangos de servidores que no formaban parte de ninguna lista de acceso aprobada.

El de guardia no tuvo que adivinar. Los logs del firewall mapearon la IP VPN origen a una identidad de usuario, los contadores de denegación mostraron bloqueos repetidos a una subred de gestión, y la matriz de acceso mostró que ese usuario no tenía razón válida para estar allí.
Deshabilitaron el acceso VPN de ese usuario y rotaron unas credenciales por precaución.

El análisis posterior sugirió un endpoint comprometido. Lo importante: la segmentación y el logging hicieron que el radio de impacto fuera pequeño y la detección temprana.
El equipo no necesitó heroísmos. Necesitó papeleo aburrido y la postura de deny por defecto que todos se habían cansado de rodar los ojos.

Broma #2: La matriz de acceso fue tan impopular que probablemente califica como un ataque de denegación de servicio distribuido contra la paciencia de los desarrolladores.

Listas de verificación / plan paso a paso

Paso 1: Dibuja los segmentos que importan (no los que desearías)

• Lista VLANs y subredes: usuarios, servidores, gestión, impresoras, IoT, guest, OT.
• Lista dónde termina la VPN: firewall, router, gateway Linux, nube.
• Identifica puntos de enrutamiento inter‑VLAN y dónde vive la aplicación de políticas.

Presión de decisión: Si el enrutamiento ocurre en tres sitios, no tienes segmentación—tienes un rompecabezas.

Paso 2: Escoge el pool de direcciones cliente VPN como si lo tuvieras que mantener años

• Usa un rango RFC1918 dedicado que no choque con redes domésticas comunes.
• Hazlo lo bastante grande para crecer (no te calles en un /24 si tendrás 800 usuarios).
• Documentalo como zona de seguridad: “VPN-Users”.

Paso 3: Define acceso por rol y servicio

• Agrupa usuarios por lo que necesitan: dev, finanzas, IT, proveedores, soporte.
• Para cada grupo: enumera destinos (subredes/hosts) y puertos.
• Prefiere destinos a nivel de servicio (VIPs, balanceadores) sobre subredes enteras.

Paso 4: Implementa “menos rutas” además de “menos reglas de firewall”

• Empuja solo las rutas necesarias a cada grupo.
• Deny por defecto entre zona VPN y zonas internas.
• Allowlista puertos con justificación y control de cambios.
• Bloquea explícitamente redes de gestión y tráfico sensible este‑oeste por defecto.

Paso 5: Haz que DNS y tiempo sean sensatos

• Configura servidores DNS y dominios de búsqueda internos para la VPN intencionalmente.
• Asegura que NTP sea accesible; la autenticación y los logs dependen del tiempo.
• Decide split DNS vs recursión interna completa según la política.

Paso 6: Logging y auditoría que no te avergüencen luego

• Registra eventos de auth VPN con identidad de usuario e IP asignada.
• Registra denegaciones de firewall desde la zona VPN (al menos al inicio).
• Conserva datos suficientes para responder “quién accedió a qué” según tus necesidades de cumplimiento.

Paso 7: Prueba como un pesimista

• Pruebas positivas: apps requeridas accesibles desde la VPN.
• Pruebas negativas: VLAN de gestión no accesible; VLAN de usuarios no accesible (a menos que sea necesario).
• Pruebas de rendimiento: MTU, throughput, concurrencia, conmutación por error.

Paso 8: Opera sin convertir cada cambio en un simulacro

• Pon reglas de firewall y configuración VPN en control de versiones.
• Tener un plan de rollback que no requiera “la única persona que lo sabe”.
• Usa despliegues por etapas para cambios de política.

Preguntas frecuentes

1) ¿Los clientes VPN deben estar en la misma VLAN/subred que los usuarios de la oficina?

No. Da a los clientes VPN su propia subred enrutada (o zona equivalente a VLAN) y aplica políticas más estrictas.
Si necesitas “misma experiencia”, resuélvelo con DNS y accesos permitidos, no con adyacencia L2 compartida.

2) ¿El split tunneling es inseguro?

El split tunneling es un trade‑off. Reduce carga y latencia, pero asume que los endpoints están razonablemente gestionados.
Si no puedes confiar en endpoints, el túnel completo no es una solución mágica—los atacantes aún pasan por el endpoint. Usa comprobaciones de postura y listas internas estrictas en cualquier caso.

3) ¿Por qué no permitir a los usuarios VPN alcanzar VLANs de servidores completas?

Porque estás dando reconocimiento y capacidad de movimiento lateral. También aumenta el radio de impacto de endpoints comprometidos.
Si los usuarios necesitan “una app”, permite esa app (VIP, puerto). Si necesitan “una subred entera”, pregunta por qué y hazlo temporal y auditado.

4) ¿Cuál es la forma más limpia de bloquear acceso VPN a redes de gestión?

Coloca gestión en subredes/VLANs dedicadas y añade denegaciones explícitas desde la zona VPN a esas subredes.
Además, no anuncies rutas a esas subredes a clientes VPN a menos que un perfil administrativo lo necesite.

5) ¿Las VLAN por sí solas proporcionan segmentación de seguridad?

Las VLAN proporcionan separación en capa 2. Sin enrutamiento controlado y política de firewall, no son límites de seguridad.
Asume que cualquier adyacencia enrutada sin política es un “camino de posible incumplimiento”.

6) ¿Cómo manejo espacio IP solapado entre usuarios remotos y VLANs de oficina?

Lo mejor: evita solapamientos mediante planificación de direcciones corporativas sensata (no uses rangos domésticos comunes).
Si heredas el problema, el último recurso es NAT para clientes VPN o renumeración. NAT funciona pero complica identidad, registros y algunos protocolos.

7) ¿Por qué veo estados SYN-RECV cuando usuarios VPN se conectan a servicios internos?

A menudo enrutamiento asimétrico: el servidor responde vía un gateway diferente al que vio el SYN. Los firewalls stateful luego descartan el tráfico de retorno.
Arregla la ruta de retorno para que vuelva por el gateway/firewall VPN, o asegúrate de que el firewall vea ambas direcciones.

8) ¿Debo enrutar tráfico inter‑VLAN en el switch core o en el firewall?

Para puro rendimiento, los switches son excelentes. Para segmentación de seguridad con trazabilidad, los firewalls son mejores.
Muchos entornos hacen ambas cosas: switching para enrutamiento básico y firewall como punto de aplicación con políticas de zona explícitas.

9) ¿Cómo demuestro que la segmentación funciona?

Ejecuta pruebas negativas desde clientes VPN (intenta acceso a subredes de gestión, escanea puertos bloqueados), verifica que los contadores/logs del firewall muestren descartes y documenta las denegaciones esperadas.
La segmentación que no puedes probar es solo un cuento para dormir arquitectónico.

Conclusión: próximos pasos que no destruyen tu red

VPN de oficina más segmentación VLAN no es difícil por la tecnología. Es difícil porque “hacer que funcione” es fácil, y “hacerlo seguro, acotado y sostenible” requiere disciplina.
La buena noticia: la disciplina es, en su mayor parte, alcance de rutas, política deny por defecto y registros que puedas usar.

Próximos pasos que puedes ejecutar esta semana:

• Crea una subred/zona dedicada para usuarios VPN y deja de tratarla como “LAN”.
• Inventaría qué servicios internos necesitan realmente los usuarios remotos (destinos + puertos), luego implementa listas de permiso.
• Elimina empujes de rutas amplios; anuncia solo subredes necesarias por grupo.
• Ejecuta la guía rápida de diagnóstico en una app “conocida por fallar” y arregla MTU/rutas de retorno antes de que se convierta en cultura.
• Activa registro que mapee IPs VPN a identidades y guárdalo el tiempo suficiente para responder preguntas incómodas.

No necesitas una red plana para ser productivo. Necesitas una red donde el acceso sea intencional—y donde los modos de fallo sean predecibles, no misteriosos.