Seguridad en Internet

Por qué fallan el correo y DeepL en la WiFi «alemana» con la VPN conectada

Por qué fallan el correo y DeepL en la WiFi «alemana» con la VPN conectada

Infografía de JumpIT UNIFI que explica por qué el correo y DeepL fallan en la VLAN alemana de UniFi. Muestra el flujo de red de los dispositivos a través del UniFi Cloud Gateway, con un túnel WireGuard DE y NAT con estado, lo que provoca conexiones de correo y DeepL interrumpidas.

En los últimos días he tenido un problema que, a primera vista, parece completamente ilógico:

La VPN está conectada, los tests de velocidad son buenos, las páginas web funcionan, pero justo cosas importantes como el correo de iCloud, GMX, en parte las tiendas de aplicaciones o la app de DeepL, la tienda de apps de Samsung TV y la de LG dejan de conectarse o, en algún momento, simplemente se cortan.

El esquema de arriba muestra justo eso: por qué «VPN activada» no significa automáticamente que todo funcione bien.

Y por qué estos problemas a menudo no desaparecen de verdad «ajustando un poco más la MTU» o «añadiendo unas reglas más».

Lo explico aquí a propósito de forma comprensible para no expertos, sin palabras de moda y sin que haga falta haber estudiado tecnología de redes.

1) Lo que en realidad quiero conseguir

Mi objetivo es simple:

  • Vivo/trabajo en Mallorca (con Starlink como internet)
  • Necesito en casa una WiFi que se comporte como Alemania
  • Es decir: los dispositivos deben salir al exterior con IP alemana (streaming, geobloqueo, determinados servicios, etc.)
  • Al mismo tiempo, todo esto no puede ser inestable: los correos tienen que funcionar sí o sí, y las apps también.

Técnicamente lo hago con WireGuard:

El tráfico de datos pasa por un túnel hasta un servidor en Alemania (centro de datos/VPS) y desde allí sale a internet.

Hasta aquí, todo bien.

2) Por qué hace falta el esquema

Porque el problema no es que «la VPN esté rota».

El túnel está establecido. El handshake es correcto. Los datos fluyen.

Y aun así se dan estos casos tan molestos:

  • El navegador funciona, pero el correo se queda colgado
  • El test de velocidad es excelente, pero las apps dicen «sin conexión»
  • Funciona por la tarde y por la mañana vuelve a fallar
  • Reiniciar a veces ayuda, y a veces no

Este es el patrón clásico de los problemas de sesión.

3) La diferencia más importante: conexiones «cortas» frente a «largas»

Los navegadores abren nuevas conexiones constantemente.

Si una se atasca un momento, da igual: la siguiente funciona.

Correo / iCloud / DeepL / banca / servicios de apps

Estos servicios suelen trabajar con sesiones largas:

  • El correo (IMAP/SMTP) mantiene las conexiones abiertas
  • iCloud hace sincronizaciones continuas en segundo plano
  • Las apps usan «conexiones HTTPS largas» y esperan que se mantengan estables

Cuando se interrumpe una sesión así, a menudo no ocurre nada visible, salvo que:

  • no carga
  • no sincroniza
  • parece «muerta»

Justo eso es lo que muestra el esquema.

4) Qué falla en segundo plano (versión para no expertos)

En el esquema pone «La sesión empieza vía DE», es decir:

La conexión comienza correctamente a través del túnel VPN alemán. ✅

Y entonces, en algún momento, ocurre algo como:

  • la ruta cambia un instante
  • el NAT/seguimiento de sesiones pierde el estado
  • o la conexión no vuelve de la misma forma en que salió

Y entonces la sesión se acaba. ❌

Las sesiones nuevas pueden volver a funcionar, pero las existentes se quedan colgadas.

Para el usuario es como si «internet se volviera loco», cuando en realidad es un problema de enrutamiento/estado.

5) ¿Qué significa «el NAT con estado pierde el estado»?

Muy sencillo:

El router recuerda internamente qué conexión corresponde a qué ruta de vuelta.

Eso se llama «estado».

Si ese estado se pierde (por ejemplo, por un aprovisionamiento, por tablas reconstruidas, por timeouts o por un cambio de ruta), la respuesta ya no se puede asignar correctamente.

Resultado:

  • La conexión se corta
  • Las apps se quedan colgadas
  • El correo no funciona

En la imagen, ese es el momento del signo de exclamación rojo.

6) ¿Por qué ocurre justo con una «WiFi alemana» a través de un gateway?

Porque aquí un dispositivo (gateway/router) intenta hacer de gateway VPN para toda una red:

  • Los clientes (Mac, iPhone, Apple TV) no pueden usar WireGuard por sí mismos
  • Por tanto, el gateway tiene que «hacer el trabajo»
  • Y de forma permanente, para muchas sesiones en paralelo

Es una carga distinta a la de «VPN solo para un portátil».

Y justo aquí se nota que:

No todo gateway es un «auténtico gateway VPN», aunque «sepa» hacer VPN.

7) Por qué la MTU/MSS no es la solución milagrosa

Mucha gente conoce los problemas de MTU:

Si la MTU es demasiado alta, los paquetes grandes no pasan → las webs cargan a medias → errores extraños.

Configurar bien la MTU/MSS es importante.

Pero:

👉 La MTU resuelve la fragmentación, no la estabilidad de las sesiones.

Si la sesión se rompe por el enrutamiento o el estado, ni siquiera la MTU perfecta ayuda.

Ese es exactamente el punto del esquema:

La sesión empieza bien, pero más tarde se corta, no por el tamaño de los paquetes, sino por el «estado/enrutamiento».

8) Por qué tras reinicios o actualizaciones suele volver

Un punto que mucha gente subestima:

Cuando un gateway se reinicia, se actualiza o se «aprovisiona», internamente a menudo se reconstruyen tablas:

  • Cadenas del firewall
  • Tablas NAT
  • Decisiones de enrutamiento

Esto puede hacer que el comportamiento cambie, aunque «no se haya cambiado nada».

Para una red doméstica normal: da igual.

Para una VPN de «todo por DE»: puede desencadenar justo estos problemas de sesión.

9) Lo que he aprendido (y lo que de verdad ayuda)

Soluciones que a veces ayudan, pero nunca garantizan el 100 %:

  • Ajustar MTU/MSS (clamping)
  • Modificar el keepalive
  • Adaptar el DNS
  • Retocar las rutas

Eso puede reducir los síntomas.

Pero, siendo sincero: es una chapuza, porque se intenta forzar una estabilidad que la configuración no ofrece de forma fiable.

Solución que en la práctica es realmente estable:

Un gateway VPN dedicado.

Es decir:

  • Un pequeño router (p. ej. MikroTik/pfSense/OPNsense) establece WireGuard
  • Este dispositivo se encarga del enrutamiento con estado y mantiene estables las sesiones
  • UniFi (o cualquier otro sistema de WiFi) se limita después a la WiFi/VLAN y queda fuera del estrés de la VPN

Es una solución limpia y también funciona con dispositivos que no pueden usar VPN (Apple TV, televisores, IoT).

10) Conclusión

El esquema resume el problema en una frase:

La VPN está conectada, pero determinadas sesiones largas pierden su camino de vuelta estable, y justo entonces mueren el correo y las apps.

Si quiere «IP alemana en toda la casa», la pregunta decisiva no es:

  • «¿Está conectada la VPN?»

sino:

  • ¿Se mantienen estables las sesiones durante horas, también tras periodos de inactividad, tras reinicios y aunque en segundo plano se reaprovisione algo?

Si la respuesta es «no siempre», volverá a ocurrir tarde o temprano, normalmente justo cuando menos le conviene.

Si necesita una configuración así en su casa o en una finca (incluidos Apple TV, Smart TV, cámaras, IoT):

Puedo montársela de forma limpia, de manera que sea estable y no funcione solo «la mayoría de las veces».

Más artículos

Aviso: las imágenes y partes de los textos de esta página se han creado con ayuda de inteligencia artificial y han sido revisados editorialmente por JumpIT.

← Al centro de conocimiento