VPN de oficina para aplicaciones ERP/CRM: prevenir bloqueos y tiempos de espera correctamente

diciembre 25, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 7

¿Te fue útil?

No hay nada que erosione más la confianza en “TI” que una pantalla del ERP que se congela justo cuando alguien registra facturas. El cursor gira, la sesión caduca y de repente tu equipo financiero realiza el ritual ancestral: cerrar todo, reabrir, volver a introducir datos y maldecir en voz baja.

Las VPN reciben la culpa porque son visibles. A veces es justo. Más a menudo, la VPN es donde el comportamiento frágil de la aplicación se encuentra con latencia, pérdida de paquetes, rarezas de MTU, confusión de DNS y firewalls stateful con corta memoria. Así es como haces que ese desastre se comporte en producción—sin adivinar.

Qué son realmente los “congelamientos” (y por qué no son místicos)

Cuando los usuarios dicen “el ERP se congeló”, el sistema normalmente está haciendo exactamente lo que le pediste: esperar. Está esperando una respuesta de red, una vuelta a la base de datos, que se libere un bloqueo de archivo o que se renegocie una sesión TLS. La mayoría de las aplicaciones de negocio (ERP/CRM) son habladoras: muchas solicitudes pequeñas, muchas dependencias y muchas asunciones sobre redes con calidad LAN.

Las VPN cambian la física:

Aumenta la latencia (incluso una VPN “buena” añade unos pocos a decenas de milisegundos).
La pérdida de paquetes se vuelve visible (Wi‑Fi, LTE y los ISP domésticos adoran la micro-pérdida).
La PMTU se rompe (sobrecarga por encapsulación, ICMP bloqueado y fragmentación súbita).
Cambios en el enrutamiento/DNS (DNS dividido, NRPT, resolutores inaccesibles, sufijos de búsqueda).
Dispositivos stateful imponen timeouts (NAT, firewalls, proxies, IDS).

Las apps ERP/CRM amplifican esto porque a menudo tienen:

Sesiones de larga duración con keepalives frágiles.
Time-outs codificados ajustados para LANs de oficina.
Protocolos mixtos (HTTP(S), WebSockets, SMB, controladores de BD, RDP/ICA, a veces todos en un mismo “flujo”).
Picos de carga grandes (exportes de informes, adjuntos, actualizaciones de cliente).

El objetivo no es “hacer la VPN más rápida”. El objetivo es hacer la VPN predecible y mantener los flujos críticos de la aplicación alejados de las trampas conocidas.

Hechos interesantes y contexto histórico (útil para reuniones)

IPsec se estandarizó en los años 90 con el objetivo de asegurar IP en sí, no solo el tráfico web. Esa mentalidad “a nivel de red” explica por qué aún está en todos lados en VPNs sitio-a-sitio.
Las VPN SSL se hicieron populares porque el puerto 443/HTTPS pasa. No fue elegancia—fue supervivencia en la era del egress bloqueado.
El “colapso” TCP-sobre-TCP se conoce desde hace décadas: tunelizar tráfico TCP dentro de una VPN TCP puede causar retransmisiones acumulativas y rendimiento desastroso bajo pérdida.
La detección de PMTU depende de ICMP para funcionar correctamente. Bloquear ICMP “por seguridad” es una forma fiable de crear timeouts misteriosos.
NAT y firewalls stateful convirtieron la red en un alquiler: si no envías algo periódicamente, tu “conexión” puede borrarse a mitad de sesión, aunque ambos extremos estén bien.
Los proveedores de ERP históricamente optimizaron para LANs porque ahí vivían los ERP: servidores on‑prem, clientes gruesos y redes de baja latencia. La nube y el trabajo remoto sacaron esas suposiciones a la luz.
SMB tiene una larga historia de sensibilidad a la latencia. Ha mejorado (SMB2/3), pero sigue penalizando RTT alto y pérdida, especialmente con I/O pequeño y operaciones de metadatos habladoras.
Las retransmisiones Wi‑Fi pueden parecer “pérdida aleatoria” en la capa VPN. La encriptación VPN oculta visibilidad de la app, así que el equipo de red a menudo solo ve “UDP encriptado” y se encoge de hombros.
TLS moderno puede reanudar sesiones rápidamente, pero los middleboxes que inspeccionan o proxyizan pueden romper esas optimizaciones, forzando más handshakes y más estancamientos.

Guía de diagnóstico rápido: encuentra el cuello de botella pronto

Si no haces nada más, haz esto en orden. La idea es dejar de debatir y empezar a aislar.

1) Establece si es latencia, pérdida o MTU

Latencia: la app funciona pero se siente lenta en todas partes; cada clic espera.
Pérdida/jitter: la app se “congela” y luego recupera; las sesiones se caen; hay reconexiones; voz/video también sufre.
MTU/MSS: las cosas pequeñas funcionan; subidas/descargas grandes se cuelgan; páginas específicas se atascan; al guardar falla; algunos sitios TLS se cargan a medias.

2) Prueba si la VPN está en el camino para el tráfico ERP/CRM

Revisa el enrutamiento (cliente) y confirma si estás en túnel completo o dividido para los endpoints ERP/CRM.
Verifica DNS: ¿resuelves el hostname del ERP a la IP correcta (interna vs pública)?

3) Identifica el punto de estrangulamiento: Wi‑Fi del cliente, uplink de oficina, concentrador VPN o backend de la app

Compara comportamiento desde: LAN de oficina, casa vía VPN, casa sin VPN (si el ERP es SaaS) y un host de prueba en la misma subred que los servidores ERP.
Busca rendimiento asimétrico: descarga rápida/subida lenta suele indicar shaping, bufferbloat o policing.

4) No depures el ERP hasta que el túnel sea aburrido

Cuando el transporte esté estable—sin picos de pérdida, sin problemas de MTU, sin flapping de DNS—entonces puedes culpar a la aplicación. Antes de eso, solo estás generando ruido.

Una cita para tener a mano: “La esperanza no es una estrategia.” —James Cameron (idea parafraseada usada a menudo en ops e ingeniería)

Los modos de falla habituales: latencia, pérdida, MTU, DNS y estado de sesión

Latencia: muerte por mil viajes de ida y vuelta

Las apps ERP/CRM con frecuencia hacen una solicitud por acción de UI, a veces docenas. Añade 30–60 ms de RTT por la VPN y de pronto un flujo de trabajo con 200 llamadas secuenciales se convierte en una pausa para el café. Por eso las “subidas de ancho de banda” no lo arreglan: el problema es el retraso, no el rendimiento.

Fuentes típicas:

Concentrador VPN lejano a los usuarios (mala geografía).
Ruteo en loop: usuario → VPN → centro de datos → SaaS → de nuevo por la VPN, por túnel completo y “seguridad”.
DNS forzando rutas internas cuando externas serían más rápidas (o viceversa).
RDP/ICA sobre VPN sobre Wi‑Fi con bufferbloat (picos de latencia bajo carga).

Pérdida de paquetes y jitter: el botón de congelar

La pérdida perjudica todo, pero daña más las apps interactivas y habladoras. Un 0.5% de pérdida puede convertir un buen día en una tormenta de tickets. La encriptación VPN también complica la clasificación QoS a menos que la planifiques.

Fuentes comunes:

Wi‑Fi de consumo, especialmente en entornos saturados.
Congestión del ISP y shaping en horas punta.
VPNs basadas en UDP en redes que depriorizan UDP.
CPU del concentrador VPN saturada (el cifrado no es gratis).

MTU y MSS: la categoría “funciona hasta que no funciona”

La encapsulación añade overhead. Si no lo tienes en cuenta, obtienes fragmentación o blackholing. El síntoma clásico es: login funciona, navegación funciona, luego una exportación de informe se cuelga para siempre. O los adjuntos fallan por timeout. O una página específica se carga a medias y se detiene.

Fuentes comunes:

ICMP bloqueado en algún punto, rompiendo PMTUD.
Overhead de VPN no compensado con MSS clamping.
Túneles mixtos (por ejemplo, VPN anidadas) con MTU inconsistente.

DNS y enrutamiento: los saboteadores silenciosos

Los fallos de VPN a menudo parecen fallos de aplicación porque la resolución y el enrutamiento deciden a qué servidor llegas. El DNS dividido puede ser correcto, pero solo si el cliente puede alcanzar el resolutor con fiabilidad y lo usa de forma consistente.

Patrones que causan dolor:

El ERP resuelve a una IP privada, pero el túnel dividido no la enruta.
Múltiples sufijos DNS hacen que el cliente pruebe el hostname equivocado primero (fallback lento).
Consultas DNS van por la VPN, pero las respuestas van directas (o viceversa) y se descartan.

Estado de sesión y timeouts por inactividad: teatro de desconexiones a mitad del día

Las sesiones ERP/CRM pueden ser cookies HTTP, JWTs, sesiones de base de datos o WebSockets de larga duración. Las VPN añaden otra capa de sesión, y en el medio están NATs y firewalls con timers de inactividad. Cuando cualquier capa expira silenciosamente, el usuario experimenta un “congelamiento” hasta que la app se rinde.

Aquí es donde importan keepalives y timeouts. No como folklore. Como ingeniería.

Broma #1: Una VPN es como un ascensor: todo el mundo solo la nota cuando se queda entre pisos.

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

Estos son chequeos prácticos que puedes ejecutar desde un jump host Linux, un gateway VPN o una VM de troubleshooting cercana al segmento del usuario. Las salidas abajo son representativas. Úsalas para decidir qué arreglar a continuación.

Task 1 — Confirma la ruta hacia el endpoint ERP/CRM

cr0x@server:~$ ip route get 10.42.8.25
10.42.8.25 via 10.8.0.1 dev tun0 src 10.8.0.23 uid 1000
    cache

Qué significa: El tráfico a 10.42.8.25 va por la interfaz de túnel VPN (tun0) vía 10.8.0.1.

Decisión: Si esto debería ser túnel dividido (p. ej., SaaS), cambia la política. Si debe ir por la VPN, continúa diagnosticando la salud del túnel.

Task 2 — Comprueba la resolución DNS y si coincide con tu intención

cr0x@server:~$ getent hosts erp.internal.example
10.42.8.25     erp.internal.example

Qué significa: El nombre resuelve a una dirección privada.

Decisión: Asegura que el enrutamiento incluya 10.42.0.0/16 sobre la VPN. Si los usuarios deben llegar al SaaS/IP público, corrige el DNS dividido o el reenvío condicional.

Task 3 — Mide latencia y jitter base (rápido y sucio)

cr0x@server:~$ ping -c 20 10.42.8.25
PING 10.42.8.25 (10.42.8.25) 56(84) bytes of data.
64 bytes from 10.42.8.25: icmp_seq=1 ttl=62 time=38.2 ms
64 bytes from 10.42.8.25: icmp_seq=2 ttl=62 time=41.7 ms
64 bytes from 10.42.8.25: icmp_seq=3 ttl=62 time=120.5 ms
...
--- 10.42.8.25 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19021ms
rtt min/avg/max/mdev = 37.8/52.3/120.5/18.4 ms

Qué significa: Sin pérdida, pero picos de jitter (max 120 ms). Eso se siente como “congelamientos” en apps interactivas.

Decisión: Investiga bufferbloat/shaping (router doméstico, uplink ISP), colas de la VPN o concentrador sobrecargado. Aún no toques el ERP.

Task 4 — Detecta pérdida bajo carga con un ping más largo

cr0x@server:~$ ping -i 0.2 -c 200 10.42.8.25
...
--- 10.42.8.25 ping statistics ---
200 packets transmitted, 196 received, 2% packet loss, time 40123ms
rtt min/avg/max/mdev = 39.1/55.7/310.2/42.8 ms

Qué significa: 2% de pérdida es suficiente para arruinar un ERP hablador, especialmente sobre TCP.

Decisión: Prioriza arreglar la pérdida: Wi‑Fi, ISP, policing de UDP o drops del dispositivo VPN. Considera cambiar el transporte VPN, ajustar keepalives y forzar conexiones cableadas para usuarios críticos.

Task 5 — Verifica la PMTU con ping “no fragmentar”

cr0x@server:~$ ping -M do -s 1472 -c 3 10.42.8.25
PING 10.42.8.25 (10.42.8.25) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

Qué significa: La MTU efectiva en el camino es 1420, no 1500.

Decisión: Clampa MSS o ajusta la MTU del túnel para evitar fragmentación/blackholes. Si ICMP está bloqueado, arréglalo también—o seguirás persiguiendo fantasmas.

Task 6 — Confirma la MTU de la interfaz en cliente/gateway VPN

cr0x@server:~$ ip link show tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Qué significa: La MTU del túnel es 1400. Es común en algunas configuraciones VPN, pero debe coincidir con la realidad.

Decisión: Si tu prueba PMTU muestra 1420, 1400 es seguro. Si PMTU es menor que la MTU del túnel, fragmentarás o crearás blackholes—ajusta.

Task 7 — Revisa el clamp de TCP MSS en un gateway Linux (iptables)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i mss
-A FORWARD -o tun0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Qué significa: Los paquetes SYN saliendo por tun0 tendrán MSS ajustado a la PMTU.

Decisión: Si sospechas problemas de MTU y esto falta, añádelo (o su equivalente en tu firewall). Si está presente, busca en otro lado.

Task 8 — Confirma el transporte VPN y evita TCP-sobre-TCP cuando sea posible

cr0x@server:~$ sudo ss -Htanp | grep -E 'openvpn|wg|strongswan' | head
ESTAB 0 0 10.0.0.5:1194 198.51.100.20:51432 users:(("openvpn",pid=1342,fd=6))

Qué significa: El servidor OpenVPN usa una sesión TCP (ESTAB) en 1194.

Decisión: Si tunelizas mucho tráfico TCP de aplicaciones, considera seriamente transporte VPN basado en UDP (o WireGuard/IPsec) salvo que la política lo prohíba. VPN sobre TCP puede funcionar, pero es frágil bajo pérdida.

Task 9 — Revisa timeouts de firewall/NAT que afectan (conntrack)

cr0x@server:~$ sudo conntrack -S
cpu=0 found=23145 invalid=12 insert=89234 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=123

Qué significa: Valores no nulos en invalid y mucho search_restart pueden indicar estrés. No es prueba, pero sí un olor.

Decisión: Si los usuarios se quejan de drops bajo carga, examina el tamaño de la tabla conntrack y los timeouts. Aumenta la capacidad o reduce la churn de sesiones (p. ej., túnel dividido para SaaS).

Task 10 — Comprueba si alcanzas límites de la tabla conntrack

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

Qué significa: Estás cerca del límite. Cuando la tabla se llena, se descartan nuevos flujos. Los usuarios llaman a eso “congelarse”.

Decisión: Incrementa nf_conntrack_max (y RAM), reduce tráfico de túnel completo innecesario o escala el gateway.

Task 11 — Identifica si el gateway está limitado por CPU (cripto)

cr0x@server:~$ top -b -n 1 | head -n 12
top - 12:43:11 up 31 days,  4:02,  2 users,  load average: 7.92, 7.10, 6.55
Tasks: 221 total,   1 running, 220 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6.1 us,  2.0 sy,  0.0 ni, 75.2 id, 16.3 si,  0.0 st
MiB Mem :  32000.0 total,  1100.3 free,  9800.2 used,  21100.1 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1342 root      20   0  1450m  220m   12m S  220.0   0.7  80:12.43 openvpn

Qué significa: Softirq alto (si) y un proceso VPN consumiendo varios núcleos. Eso puede indicar cuellos de botella en el procesamiento de paquetes.

Decisión: Activa AES‑NI/offload criptográfico si está disponible, ajusta interrupciones/RPS o cambia a una pila VPN más eficiente. A veces la solución es “comprar una máquina más grande”, y sí, eso es ingeniería.

Task 12 — Revisa errores/descartes en la interfaz del gateway

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       12453    0       112233
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  7456789  0       9821     0       0

Qué significa: Existen descartes. Algunos descartes son normales bajo shaping, pero el crecimiento persistente durante las quejas es una pista.

Decisión: Inspecciona qdisc, tamaños de ring de NIC y políticas de shaping. Si los descartes se correlacionan con los congelamientos ERP, tienes un problema de red, no del ERP.

Task 13 — Valida QoS/disciplinas de cola en Linux (control de bufferbloat)

cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Qué significa: fq_codel ayuda a reducir bufferbloat y latencia bajo carga.

Decisión: Si ves un pfifo_fast básico o buffers gigantes y los usuarios se quejan de congelamientos durante subidas, implementa AQM moderno (fq_codel/cake) donde puedas.

Task 14 — Captura evidencia de blackholing por MTU con tcpdump

cr0x@server:~$ sudo tcpdump -ni tun0 host 10.42.8.25 and icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:47:01.112233 IP 10.8.0.23 > 10.42.8.25: ICMP echo request, id 3921, seq 1, length 1480
12:47:01.112987 IP 10.42.8.25 > 10.8.0.23: ICMP unreachable - need to frag (mtu 1420), length 556

Qué significa: PMTUD funciona (recibiste “need to frag” con una MTU). Bien—ahora clampa MSS y evita paquetes sobredimensionados.

Decisión: Si nunca ves el ICMP “need to frag”, sospecha filtrado de ICMP y arréglalo, o ajusta MTU de forma conservadora.

Task 15 — Valida la alcanzabilidad a nivel aplicación y tiempo de handshake TLS

cr0x@server:~$ curl -sk -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://erp.internal.example/login
dns=0.004 connect=0.037 tls=0.210 ttfb=0.612 total=0.613

Qué significa: El handshake TLS dura 210 ms; el time-to-first-byte es 612 ms. Eso puede ser normal, pero si se dispara durante “congelamientos”, tienes inestabilidad de ruta o saturación de backend.

Decisión: Si DNS/conexión/TLS fluctúan, arregla la red/VPN. Si solo sube TTFB mientras los tiempos de red están estables, investiga las capas web/app/base de datos del ERP.

Task 16 — Comprueba ruteo asimétrico (a menudo rompe dispositivos stateful)

cr0x@server:~$ traceroute -n 10.42.8.25 | head -n 8
traceroute to 10.42.8.25 (10.42.8.25), 30 hops max, 60 byte packets
 1  10.8.0.1   2.011 ms  1.902 ms  2.144 ms
 2  10.10.0.1  8.220 ms  8.101 ms  8.333 ms
 3  10.42.0.1  35.009 ms  34.882 ms  35.120 ms
 4  10.42.8.25 38.551 ms  38.420 ms  38.600 ms

Qué significa: El camino de ida parece sano. La asimetría trata sobre el camino de retorno, así que aún necesitas verificar el enrutamiento en el lado de la subred ERP.

Decisión: Si los servidores ERP retornan tráfico por un firewall distinto al que vio el SYN, verás stalls y resets “aleatorios”. Arregla la simetría de ruteo o usa reglas stateless donde proceda.

Diseña la VPN para aplicaciones empresariales, no para heroicidades

Decide: túnel completo vs túnel dividido (con reglas maduras)

El túnel completo es atractivo porque da sensación de control: “todo el tráfico pasa por nosotros.” También convierte tu VPN en el internet de oficina para cada usuario remoto, que es una gran forma de aprender qué significa “planificación de capacidad” en tiempo real.

Para ERP/CRM, la mejor respuesta suele ser el túnel selectivo:

Tuneliza lo que debe ser privado: ERP on‑prem, APIs internas, servicios de archivos ligados a workflows del ERP.
No hairpinees SaaS: si tu CRM es SaaS, enrutarlo por la oficina añade latencia y dominios de fallo sin ganancia funcional.
Usa DNS dividido con cuidado: nombres internos resuelven internamente; nombres públicos resuelven públicamente. Manténlo determinista.

Los equipos de seguridad a menudo temen que el túnel dividido signifique “menos seguro”. La afirmación más precisa es: el túnel dividido significa que debes diseñar controles intencionalmente (EDR, posture de dispositivo, protecciones DNS y políticas de egress), no dejarlos al azar mediante hairpinning.

Elige el transporte correcto: UDP cuando puedas, TCP solo cuando sea forzado

Para aplicaciones interactivas de negocio, el tunelizado basado en UDP suele ser más tolerante bajo pérdida porque evita bucles de retroalimentación TCP‑sobre‑TCP. WireGuard e IPsec suelen comportarse bien y son operativamente sensatos. OpenVPN puede estar bien también, pero evita transporte TCP salvo que no haya alternativa.

Si la red bloquea UDP, aún puedes lograrlo con TCP—solo espera dedicar más tiempo a MTU/MSS y ajuste de keepalives, y no finjas que “es igual de bueno”.

Haz la MTU aburrida: defínela, clampéala y mídela

Los problemas de MTU son clásicos porque son intermitentes y dependen del tamaño de la carga. Sólvalos sistemáticamente:

Mide la PMTU efectiva a través del túnel.
Define la MTU del túnel ligeramente por debajo de esa.
Clampa el MSS TCP en la salida del túnel a la PMTU.
Permite ICMP “fragmentation needed” (tipo 3 código 4) a través de los firewalls relevantes.

Si alguien dice “bloqueamos ICMP por seguridad”, dale un pager. No como amenaza. Como experiencia de aprendizaje.

Mantén las conexiones vivas (porque los middleboxes olvidan)

Los timers de inactividad no son teóricos. Los fijan NATs, firewalls y a veces el propio concentrador VPN. Cuando un cliente ERP mantiene una sesión inactiva mientras un usuario lee una pantalla, el transporte subyacente puede volverse inactivo también.

Usa:

Keepalives VPN a un intervalo más corto que el timeout de estado más corto en el camino.
Keepalives de aplicación cuando esté soportado (ping/pong de WebSocket, parámetros de keepalive en BD).
Ajuste de timeouts de firewall para flujos de app conocidos y buenos.

Reduce dependencias habladoras: usa proximidad a nivel app o apps publicadas

La forma más fiable de hacer que un ERP hablador se comporte sobre una red no siempre perfecta es dejar de enviar cada ida y vuelta por la VPN. Dos patrones comunes:

Escritorio virtual / aplicación publicada cerca del ERP (RDP/ICA): solo pixeles/teclas cruzan la WAN. Cambias preferencias UX por estabilidad.
Frontends web y APIs cerca de la base de datos: mantén llamadas DB habladoras dentro del data center, no por la VPN.

Sí, esto es arquitectónico. Ese es el punto. No puedes “tunear” la física indefinidamente.

Observa como adulto: mide la experiencia de usuario, no solo si el túnel está arriba/abajo

“VPN conectada” es una métrica de vanidad. Necesitas:

RTT y pérdida a subredes internas clave.
Descartes de paquetes del túnel, rekeys, renegociaciones.
CPU del gateway, softirq, descartes NIC.
Tiempos de la aplicación (TTFB), tasas de error, caídas de sesión.

Correlaciona. Informes de congelamiento que coinciden con descartes del gateway son red. Los que coinciden con esperas de bloqueo en la base de datos son aplicación. Tu trabajo es parar el carrusel de culpas.

Tres mini-historias de la vida corporativa

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

La empresa había movido su capa web del ERP a una subred privada y la publicó mediante una VPN. El personal remoto se quejaba de que “cada tarde” el ERP se congelaba al subir PDFs de facturas. El equipo de infra vio gráficos limpios: túneles VPN arriba, CPU bien, ancho de banda no saturado. Lo etiquetaron como “bug del ERP” y escalaron al proveedor.

El proveedor pidió logs HAR. Los logs mostraron un patrón: pequeñas llamadas API funcionaban, pero la petición de subida se atascaba y finalmente caducaba. Alguien sugirió MTU. La sala se quedó en silencio—MTU es ese tipo de cosa que la gente recuerda que existe justo antes de que arruine la semana.

Testearon PMTU a través del túnel y encontraron una MTU efectiva de 1412 por un dispositivo WAN aguas arriba. La VPN estaba configurada con MTU 1500 porque “Ethernet es 1500”, lo cual es verdad en el mismo sentido que “la comida es al mediodía” es verdad: depende de dónde estés y quién manda.

La solución fue sencilla: clamped MSS en el gateway y ajustar la MTU del túnel de forma conservadora. Los congelamientos en subidas desaparecieron de inmediato. La lección del postmortem no fue MTU. Fue la suposición equivocada de que “si las pequeñas solicitudes funcionan, la red está bien.” La sensibilidad al tamaño de la carga es una gran pista.

Mini-historia #2 — La optimización que salió mal

Otra organización quiso “acelerar” la VPN. Alguien notó que UDP se bloqueaba ocasionalmente en Wi‑Fi de hoteles, así que cambiaron la VPN a TCP globalmente “por fiabilidad”. Ayudó a algunos viajeros a conectarse más seguido. Los tickets bajaron por dos semanas. Luego llegó el cierre de mes.

Durante la actividad pico financiera, el tiempo de respuesta del ERP pasó de “aceptable” a “congelado” para un grupo de usuarios remotos. La VPN permanecía conectada, pero el throughput se hundía ante una pérdida leve de paquetes. Los usuarios decían que el ERP se colgaba 20–60 segundos y luego repentinamente se ponía al día.

Las capturas mostraron el clásico comportamiento TCP‑sobre‑TCP: retransmisiones dentro de retransmisiones, ventanas de congestión colapsando y el túnel amplificando el mal rendimiento. Su “optimización” mejoró conectividad en redes hostiles pero convirtió jitter normal en destructivo.

La solución no fue avergonzar al autor del cambio. Fue restaurar UDP por defecto, añadir un perfil fallback TCP para entornos que lo necesitaban y hacer que los clientes seleccionen según la alcanzabilidad. Fiabilidad no es “usar TCP”. Fiabilidad es “diseñar para la red que realmente tienes”.

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

Una empresa manufacturera ejecutaba un ERP on‑prem con un cliente grueso que hablaba con una base de datos y un share de archivos. El trabajo remoto crecía y supieron que la VPN sería una nueva dependencia. Hicieron dos cosas poco glamurosas temprano: documentaron los flujos críticos del ERP (qué servidores, qué puertos, qué protocolos) y montaron sondeos continuos desde la subred VPN hacia esos endpoints.

Meses después, se aplicó una actualización de políticas de firewall. Nadie tocó la configuración VPN. A la mañana siguiente, los usuarios remotos vieron congelamientos intermitentes al abrir adjuntos. El helpdesk escaló rápido porque el dashboard de monitorización ya mostraba un cambio: el tiempo de respuesta SMB desde la subred VPN aumentó y aparecieron nuevos resets TCP en el camino al servidor de adjuntos.

Puesto que el equipo tenía el mapa de flujos, no perdieron media jornada probando teorías al azar. Encontraron una discrepancia en el timeout de sesión en un firewall para flujos SMB desde el pool VPN y revirtieron esa política específica. Nunca llamaron al proveedor ERP. Finanzas no tuvo que volver a introducir datos.

No pasó nada heroico. Por eso funcionó. La observabilidad aburrida y las baselines conocidas vencen al drama siempre.

Errores comunes: síntomas → causa raíz → solución

Esta es la parte que puedes pegar en un sistema de tickets y parecer sabio.

1) “El login funciona, pero las subidas/descargas se cuelgan”

Síntomas: Adjuntos, exportes de informes o páginas específicas se atascan; llamadas API pequeñas funcionan.
Causa raíz: Blackholing por MTU o problemas de fragmentación; PMTUD roto por filtrado ICMP; falta de MSS clamping.
Solución: Mide PMTU, define MTU de túnel de forma conservadora, clampa MSS en la salida y permite ICMP “frag needed”.

2) “Se congela 30 segundos, luego se pone al día”

Síntomas: Stalls intermitentes largos; eventualmente se reanuda; sobre todo con Wi‑Fi ocupado o en horas punta.
Causa raíz: Pérdida/jitter con backoff de retransmisión TCP; a veces transporte VPN TCP amplificando la pérdida.
Solución: Prefiere transporte UDP; reduce fuentes de pérdida (cableado, mejor Wi‑Fi), aplica AQM (fq_codel/cake), revisa descartes del gateway.

3) “La VPN está conectada pero ERP dice ‘no puede alcanzar el servidor’”

Síntomas: Túnel arriba; el nombre resuelve; la conexión falla o caduca.
Causa raíz: Rutas de túnel dividido faltantes; ERP resuelve a IP interna pero el cliente la envía al gateway por defecto; ACL faltante.
Solución: Arregla push/policies de ruta; confirma con ip route get; alinea DNS con la intención de enrutamiento.

4) “Funciona por la mañana, falla por la tarde”

Síntomas: Correlación por hora del día; más quejas durante llamadas/subidas.
Causa raíz: Congestión y bufferbloat; saturación del uplink WAN; CPU del gateway bajo pico.
Solución: Aplica shaping; implementa AQM; escala el concentrador; deja de hairpinear SaaS por la VPN.

5) “Solo algunos usuarios se ven afectados, y cambia”

Síntomas: Subconjuntos aleatorios de usuarios ven congelamientos; difícil de reproducir.
Causa raíz: Diferencias anycast/geo a POPs VPN, variaciones en caminos ISP, condiciones Wi‑Fi o diferencias MTU con túneles anidados.
Solución: Estandariza perfiles de cliente; ofrece endpoints VPN regionales; recoge mediciones desde cliente (RTT/pérdida/MTU).

6) “RDP al escritorio ERP se congela, pero navegar por la web está bien”

Síntomas: RDP/ICA se entrecorta o congela; internet en general parece OK.
Causa raíz: UDP bloqueado o shaped, o jitter alto; RDP es sensible a picos de latencia; colas en la VPN.
Solución: Asegura UDP estable cuando sea posible; aplica QoS en el borde; reduce picos de latencia con AQM; considera ajustes de soporte UDP de RDP según el entorno.

7) “Se desconecta constantemente cuando los usuarios están leyendo pantallas”

Síntomas: Usuarios inactivos son desconectados; sesiones se reinician tras pocos minutos de inactividad.
Causa raíz: Timeouts de NAT/firewall más cortos que las expectativas de la app; falta de keepalives.
Solución: Configura keepalives VPN; ajusta timeouts de sesión; asegura que flujos de larga duración estén permitidos y se rastreen correctamente.

Broma #2: Si tu plan de troubleshooting es “reinicia la VPN”, no estás arreglando el sistema—estás realizando un ritual para los dioses de los paquetes.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar ERP/CRM sobre VPN en 10 movimientos

Inventario de flujos: endpoints ERP/CRM, puertos, protocolos, dependencias (shares de archivos, proveedores de identidad, APIs).
Decide la intención de enrutamiento: túnel dividido para SaaS; tuneliza solo redes internas que deben ser privadas.
Arregla determinismo DNS: reenvío condicional/DNS dividido para que los nombres resuelvan consistentemente al lugar correcto.
Mide PMTU a través del túnel y estandariza MTU por perfil VPN.
Clampa MSS en la salida del túnel para TCP.
Prefiere transporte UDP para la VPN donde sea factible; mantiene TCP como perfil de fallback separado.
Configura keepalives por debajo del timeout de middlebox más corto; alinea timers de firewall con la realidad del negocio.
Implementa AQM (fq_codel/cake) en el borde del gateway o dispositivo WAN si lo controlas.
Planifica capacidad del concentrador: CPU (cripto), RAM (conntrack/estado), descartes NIC y sesiones concurrentes.
Monitoriza señales de experiencia de usuario: RTT/pérdida, drops de túnel, fallos DNS, tiempos HTTP y salud de backend.

Lista de verificación: antes de cambiar nada en producción

¿Puedes reproducir el congelamiento y capturar timestamps?
¿Tienes RTT/pérdida de baseline desde un usuario conocido bueno?
¿Sabes si el tráfico es túnel completo o dividido?
¿Has validado la resolución DNS y que las rutas coincidan?
¿Probaste PMTU y confirmaste MSS clamping?
¿Sabes el transporte VPN (UDP/TCP) y por qué se eligió?
¿Revisaste CPU del gateway, descartes y utilización de conntrack durante la ventana del incidente?

Lista de verificación: si debes mantener túnel completo (la política lo exige)

Asegura que el egress VPN tenga suficiente ancho de banda y shaping/AQM sensato.
No hairpinees SaaS obvio si puedes usar gateways web seguros o controles de dispositivo en su lugar.
Fija aplicaciones críticas a rutas y resolutores conocidos y buenos; evita DNS “mágico” que cambie por red.
Segmenta pools VPN (ejecutivos/finanzas vs general) para que el streaming de un grupo no sea problema de todos.
Loguea y alerta sobre renegociaciones de túnel, drops del gateway y tasas de fallo DNS.

Preguntas frecuentes

1) ¿Debemos usar túnel dividido para ERP/CRM?

Para ERP on‑prem, tunelizarás las subredes internas. Para CRM/ERP SaaS, el túnel dividido suele ser la mejor opción para evitar latencia por hairpin y reducir carga en la VPN—siempre que tengas controles en el endpoint y DNS sensato.

2) ¿OpenVPN es “malo” para ERP?

No. OpenVPN puede funcionar bien. La trampa común es ejecutarlo sobre TCP para uso general y luego preguntarse por qué el rendimiento colapsa ante pérdida. El transporte UDP suele ser mejor para apps interactivas.

3) ¿Qué MTU debemos definir?

Mide la PMTU a través del camino real. Luego elige una MTU de túnel que deje margen. Si no puedes confiar en ICMP, elige de forma conservadora y clampa MSS. Adivinar 1500 porque “Ethernet” es la forma de ganarte turnos nocturnos.

4) ¿Por qué los usuarios dicen “se congela” en lugar de “está lento”?

Porque muchas apps bloquean el hilo de UI esperando I/O de red o un lock. La pérdida de paquetes y el backoff de retransmisión parecen un congelamiento duro aunque el proceso esté vivo.

5) ¿Las subidas de ancho de banda arreglan timeouts?

A veces, si estás saturando un uplink y todo se encola. Pero la mayoría del dolor ERP/CRM sobre VPN es latencia, jitter, MTU o timeouts de estado—no ancho de banda bruto. Mide antes de comprar.

6) ¿Por qué funciona en hotspot móvil pero no en Wi‑Fi doméstico?

Diferente comportamiento del último tramo: interferencia Wi‑Fi, bufferbloat del router, shaping del ISP o manejo de UDP. Los hotspots pueden ser caminos más limpios, o peores. El punto es: no es “la VPN”, es el camino.

7) ¿Necesitamos QoS si todo está encriptado?

Aún puedes aplicar QoS en el túnel exterior (por usuario/grupo, marcando DSCP antes de encriptar o shaping por túnel). Si no haces nada, el flujo más ruidoso gana—suele ser quien sube un vídeo mientras finanzas registra asientos.

8) ¿Cómo evitamos desconexiones por inactividad?

Configura keepalives VPN y alinea timeouts de firewall/NAT. También revisa que rekey/renegociación no interrumpa sesiones de larga duración. Si la app tiene su propio keepalive, actívalo.

9) ¿RDP es un buen workaround para ERP sobre VPN?

A menudo sí. Si tu ERP es hablador o usa SMB/BD directamente desde el cliente, publicar la app cerca de los servidores convierte el dolor WAN en un único protocolo controlable. No es elegante, pero es eficaz.

10) ¿Cuál es la causa raíz más común que ves?

Problemas MTU/MSS para “cuelgue en subidas” y pérdida/jitter para “congelamientos aleatorios”. En tercer lugar: malas decisiones de DNS/enrutamiento que causan hairpin o endpoints incorrectos.

Conclusión: siguientes pasos que realmente reducen los tickets

ERP/CRM sobre VPN falla de maneras predecibles. Si lo tratas como un misterio, obtendrás misterios. Trátalo como un sistema con propiedades medibles—RTT, pérdida, MTU, enrutamiento, DNS y timeouts de estado—y se vuelve aburrido. Aburrido es la meta.

Pasos prácticos:

Ejecuta la guía de diagnóstico rápido en un camino de usuario afectado y en uno conocido bueno. Captura RTT/pérdida/PMTU y evidencia de enrutamiento/DNS.
Arregla MTU/MSS y el manejo de ICMP primero. Es bajo esfuerzo y alto impacto.
Deja de hairpinear SaaS por la oficina a menos que tengas una razón validada y específica.
Prefiere transporte VPN basado en UDP; mantén TCP como perfil fallback, no por defecto.
Instrumenta tu gateway VPN como si importara: descartes, conntrack, CPU/softirq y cheques de experiencia por ruta a endpoints ERP.
Si el ERP es inherentemente hablador, acerca la interacción del usuario a la app (apps publicadas/VDI) en vez de intentar perfeccionar la WAN.