Trabajo de forma remota conectándome a un servidor NAS Synology DS223j ubicado en otra localización. La conexión se realiza a través de un túnel VPN Tailscale (protocolo WireGuard). Mi socia, en su ubicación, trabaja con el NAS de forma rápida y eficaz, pero en mi domicilio (con router Mitrastar GPT-2541GNAC) la comunicación es prácticamente nula.
Configuración actual:
Software: Synology Drive Client y Tailscale.
Hardware local: Router Mitrastar GPT-2541GNAC.
Uso: Sincronización de archivos profesionales de gran tamaño (RAWs de fotografía, aprox. 30-50MB por archivo).
Problemática detectada:
Bloqueo de flujos TCP: El sistema logra indexar los archivos (veo las miniaturas y los nombres), pero en cuanto se inicia una transferencia de datos pesada (descarga de archivos RAW), el router bloquea la conexión.
Errores de red: El sistema operativo devuelve errores de "Red no disponible" (0x80070184) a los pocos segundos de iniciar cualquier descarga, ya sea por el software dedicado o incluso a través de descarga directa por navegador web.
Velocidades residuales: En el monitor de recursos se observan velocidades de transferencia que caen a los 2.5 KB/s, lo que indica que el router está descartando los paquetes de datos del túnel VPN.
Inestabilidad de Tailscale: Aunque la conexión figura como "Direct", el router Mitrastar parece interrumpir las sesiones persistentes necesarias para la sincronización.
Para agilizar el diagnóstico, informo de que ya se han realizado las siguientes intervenciones sin éxito:
Optimización del Adaptador de Red:
Se ha desactivado el protocolo IPv6 en el adaptador virtual de Tailscale para forzar el tráfico por IPv4 y evitar conflictos de enrutamiento.
Pruebas de Protocolo de Transferencia:
Software Dedicado: Se ha probado con Synology Drive Client (basado en sincronización por bloques).
Navegador Web (HTTP/HTTPS): Se ha intentado la descarga directa vía navegador (Chrome/Edge). En ambos casos, la descarga se inicia y se corta bruscamente a los pocos segundos.
Estado de la VPN (Tailscale):
Se ha verificado que la conexión es "Direct" (puerto a puerto) y no a través de un nodo de retransmisión (Relay/DERP). Aun así, el tráfico no fluye.
Aislamiento de Archivos:
Se ha intentado la descarga de archivos individuales (un solo RAW de 30MB) y de bloques pequeños. El router bloquea la conexión de forma sistemática tras el primer o segundo archivo exitoso.
Reinstalación y Limpieza:
Se han reiniciado ambos servicios (Tailscale y Drive) y el propio router en repetidas ocasiones, sin que la estabilidad de la conexión mejore.
Verificación de Hardware en Origen:
Se ha confirmado que otros usuarios (mi socia) descargan del mismo NAS de forma fluida desde otras operadoras/routers, lo que sitúa el problema específicamente en la gestión de tráfico de este router Mitrastar.
No hemos recibido nuevas comunicaciones por tu parte, por lo que entendemos que la información indicada anteriormente fue de ayuda para solucionar el fallo que presentabas. Por nuestra parte, procederemos a cerrar este hilo. Si más adelante tienes alguna otra consulta, no dudes en comunicárnoslo y estaremos encantados de ayudarte.
Como no hemos recibido más comunicaciones por tu parte, creemos que ya no necesitas más ayuda desde el foro. en caso de no ser así, responde a este mismo hilo y retomaremos tu caso.
No hemos recibido respuesta de tu parte. No dudes en contactarnos si tienes alguna consulta o duda. Es importante para nosotros confirmar si el fallo que mencionaste anteriormente ya ha sido solucionado y si el servicio continúa funcionando correctamente. Esto nos permite verificar que tu consulta ha sido atendida de manera efectiva y que todas las funcionalidades que necesitas están operando adecuadamente.
Nos alegra saber que tu consulta ha quedado resuelta y agradecemos que lo hayas compartido con nosotros. Esperamos que la información proporcionada haya sido útil y haya resuelto tu consulta. Si consideras que el caso está solucionado, te agradeceríamos que pulsaras el botón “Marcar como solución” en el mensaje que dio respuesta a tu duda dentro del hilo que abriste. Esto nos ayuda a confirmar que tu consulta ha sido atendida correctamente y, además, permite que otros usuarios puedan encontrar fácilmente respuestas útiles para situaciones similares. Muchas gracias por confiar en nuestro servicio. Confiamos en que la calidad de la red móvil continúe mejorando de manera gradual gracias a las correcciones aplicadas en la zona por parte de nuestros técnicos.
Me alegra saber que se ha solucionado. No obstante, un par de matices, si no te importa:
1º. A pesar de que sigas en la creencia que la culpa es que el Router, ahora con que sea más o menos "sensible", me temo El Router no es ni más ni menos sensible a ello, al Router lo único que le importa es que no se te ocurra que le llegue un paquete de más de 1492, porque al meterle 8bytes de cabecera se romperá. Para el 99% de los casos esto no es un problema pq es un valor que se negocia, pero al empaquetar un paquete dentro de otro, es lo que pasa. Las cabeceras de WireGuard son igualmente agnósticas para el Router, son solo datos. Como ya te he explicado, el Router no tiene que procesar/leer nada, simplemente reenvía. Es más, para el Router es mucho más costoso tener que lidiar con paquetes de por ejemplo 1000Bytes que paquetes de 1400Bytes. Cuanto más bajo sea el MTU, más paquetes se requieren para la misma información, con lo que el Router trabaja más. El problema nunca ha estado en el Router, ni lo está, si dices que con 1100 parece ir mejor, el problema te aseguro que está en el lado del servidor.
2º. Paquetes más bajos implican menos eficiencia. Por eso es adecuado en la medida de lo posible usar el MTU más alto posible... pero teniendo cuidado como es lógico a no provocar problemas como hemos visto. En teoría, el valor "seguro" para Wireguard está alrededor de 1420, 1400 si te quieres curar en salud, dado que no puedes saber por lo general el origen desde el que te vas a conectar. Si son proveedores "masivos" suelen emplear de MTU 1280Bytes para asegurarse de que en su totalidad no hay red o configuración que no pueda funcionar. Un MTU de 1100 en principio solo tiene un 1% menos de eficiencia que uno de 1500Bytes, pero sin embargo para un simple archivo de 1MB puede significar un 30% más de paquetes, lo que implica mucha más carga para el Router, servidor, CPU... todo
Mi consejo, es que investigues en el servidor que está causando esa anomalía y se subsane. Obviamente funciona porque si los paquetes dejan de ser descartados la anomalía base, ahora por fin llegan, aunque lo están haciendo a un precio muy alto.
A ver... uso Wireguard desde hace mucho en mi propia conexión, tengo tb mi propio servidor, y tanto con Mitrastar como Asley, te aseguro que funciona perfectamente sin problema alguno. En lo personal siempre he usado el valor de 1400Bytes por seguridad, pero obviamente mis VPN están muy controladas y sé quien se conecta y quien no, no es una VPN de acceso "libre" que al final puede conectarse personas casi desde cualquier tipo de conexión. En España, en las conexiones que tenemos, un valor de 1400Bytes debería de ser totalmente seguro. Tener problemas con ello denota únicamente un fallo en la configuración por parte del servidor o del cliente (o de los equipos donde se corren)
Saludos, y nos alegramos que por fin lo hayas podido solucionar.
Hola, quería pasarme por aquí para daros las gracias, especialmente a Theliel, porque vuestra pista sobre la fragmentación de paquetes ha sido la clave definitiva.
Después de hacer las pruebas de ping -f -l que me recomendasteis, vi que incluso a 1280 la conexión seguía siendo inestable con mi router Mitrastar de Movistar. Finalmente, he bajado el MTU de la interfaz de Tailscale a 1100 y... ¡magia! Las descargas de Synology Drive han pasado de cortarse a los 2 segundos a ser totalmente estables.
Parece que mi router es especialmente 'sensible' con las cabeceras de WireGuard/Tailscale y necesitaba ese margen extra para no descartar los paquetes. Ya estoy descargando carpetas enteras de fotos RAW sin un solo error.
¡Mil gracias por vuestra paciencia y por compartir vuestro conocimiento!
Pues debo decirte que en este caso es totalmente falso, no existe ningún Router, y mucho menos de usuario, que puedan saber o hacer lo que dices.
Un Router si puede hacer perfectamente SPI para "inspeccionar" en la medida de lo posible el payload, el puerto de origen y destino... incluso en algunos protocolos, obviamente no cifrados como FTP ó SIP los Router tienen "ayudantes" para que funcionen de forma correcta bajo NAT, y literalmente "leen" parte de ese payload y lo modifican. Contenido no cifrado, repito. Sí, un Router podría "clasificar" diferente tipo de tráfico en función del puerto usado, así por ejemplo si te conectas a una web segura HTTPS el puerto por lo general es el 443, y aunque el tráfico sea cifrado el Router podría decir: Ah, si veo puerto 443 es HTTPS, puedo usar QoS u otras técnicas de eficiencia!! Eso sí se puede hacer, es factible, aunque no lo vas a ver en Router de ningún ISP, son funcionalidades avanzadas no disponibles en los equipos domésticos que te instala un ISP.
Es cierto que existen sistemas a niveles empresariales donde analizando metadatos, cabeceras y otros pueden ser capaces con todo ello intentar adivinar que protocolos se están usando (no el contenido, ojo), pero no quiero que te lleves a engaños a pensar que eso se hace o es posible a nivel doméstico, y mucho menos que tu Router lo hace, y mucho menos para una VPN como Wireguard.
Ahora bien, eso no tiene absolutamente nada que ver con lo que propones. Si bien un Router que te compres en el mercado podrías técnicamente configurarlo para por ejemplo aplicar algún tipo de filtrado para el tráfico que se dirija al puerto 443, eso no quiere decir que el Router supiese que es tráfico HTTPS, eso no lo sabe porque si el contenido va cifrado no tiene la menor idea de que hay dentro, ni siquiera sabe si el contenido está realmente cifrado o no. Es más, VPN como OpenVPN generalmente es habitual usar el puerto 443, y no es una conexión HTTPS.
Volviendo a WireGuard, es similar. De nuevo, te repito, el Router no tiene ninguna forma humana ni inhumana de saber que es un paquete VPN Wireguard o que no lo es. De hecho, lo más parecido que puede hacer tu Router es, en el caso de usar una VPN como IPSec/L2TP o PPTP, es saber que estás usando una VPN, porque para que estos protocolos viejos funcionen detrás de NAT el Router se ve obligado a usar "ayudantes". En esos casos concretos sí, el Router "sabe" que hay un tunel VPN establevido, nada más. Ni bloquea, ni satura, nada.
En el caso de Wireguard es aun más absurdo, porque se encapsula en un paquete UDP normal y corriente, no tiene magia alguna. El Router sólo ve un paquete IP usando como capa de transporte UDP, se acabó. El Router no tiene ni idea si ese paquete está cifrado, si va en texto plano, si es una matriuska, si... simplemente recoge el paquete que estás enviando y lo reenvía a Internet, nada más.
"...cortan sesiones VPN largas cuando detectan mucho tráfico UDP cifrado..."
Hay dos errores en esa afirmación. Una conexión UDP es por definición stateless, no existe el concepto de sesión. En una conexión UDP tu no abres una conexión o la cierras, tu equipo envía o no un paquete, y recibe o no un paquete. Tú si abres/cierras una conexión a nivel de VPN, en el contexto de la información que va dentro del payload cifrado), pero no a nivel de conexión del paquete exterior. Por eso UDP se considera extremadamente silencioso. En TCP la cosa es totalmente diferente, porque literalmente se tiene que establece una conexión, un handshake, y además se tiene que mantener "viva" enviando paquetes keep-alive. UDP no. Si envías por ejemplo un paquete UDP al puerto correcto de tu servidor WireGuard con cualquier cosa que no sea un paquete válido para el propio servidor Wireguard, no va a responder nada, ni mucho ni poco ni error... nada, como si ese paquete jamás hubiese llegado.
El otro error es, repito lo de detectar tráfico cifrado. El tráfico cifrado por definición es cifrado, es un galimatías, no puedes saber si realmente está cifrado o si es texto plano que simplemente no entiendes o no sabes decodificar. Es parte de la seguridad intrínseca. Si yo te mando un mensaje que ponga por ejemplo: "Hola, que tal." lo tienes claro, dirás: Eso no es un mensaje cifrado, eso es en texto plano. Obviamente!! Peri si te mando por ejemplo esto otro:
"48 6f 6c 61 2c 20 71 75 65 20 74 61 6c 2e" a menos que tengas una tabla ASCII o conversor hexadecimal podrías pensar que es cifrado, y nada más lejos, es exactamente el mismo mensaje. Pero es que a lo mejor un protocolo cualquiera necesita para inicializarse la cadena hexadecimal que comience por... que te digo yo, "060606", esto no tiene contrapartida ASCII legible, y tampoco sería un texto cifrado. Imagina ahora que el Router ve pasar:
"78595c571c164143551644575c18"
Eso es cifrado? no va cifrado? En caso de ir cifrado, que cifrado?? Pues no lo puede saber, y es más, si yo no te lo digo, tu tampoco lo puedes saber. Puede ser que sea un pequeño fragmento cifrado, puede ser que sean simplemente datos binarios que configuran un relé, puede ser que sea el comienzo de una imagen JPG, o un trocito de parte de la imagen...
Al Router le da igual que sea "hola pepito", 78595c571c164143551644575c18... y a Movistar tres cuartos de lo mismo. COmo ves, es totalmente ilógico pensar que te pueden cerrar una sesión VPN cuando ni existe una sesión propiamente dicho en UDP, ni nadie sabe si es tráfico cifrado o no.
"...confundiéndolo con saturación o ataques"
Creo que subestimas lo que es una saturación o un ataque. Tendrás una linea de 600Mbps o 1Gbps, ¿crees realmente que por "descargar" un archivo de unos 30MB estás saturando algo?? Pero si ya lo haces cuando haces cualquier test de velocidad, y a muchísima más velocidad y volumen!! Por qué o como una conexión UDP se va a considerar un "ataque" o una "saturación" cuando tu equipo ya establece a lo largo del día muchas otras conexiones UDP a todo tipo de destino con más y menos carga y sin que tu lo sepas.
Un Router por lo general puede implementar medidas para evitar ataques? Sí, rotundamente, de hecho tu Router con seguridad tiene reglas específicas para evitar que te ataquen, y donde esté el servidor VPN posiblemente también. Y esto te puede afectar? No, rotundamente tampoco.
Estos filtros para empezar ´únicamente se disparan para tráfico entrante no solicitado. Es decir, cuando el primero que envía el primer paquete es alguien desde Internet hacia tu Router. Este no es tu esquema, en todo caso sería el tuyo con el servidor VPN, porque eres tú quien envía el primer paquete de la comunicación. Y el Router donde está la VPN tampoco aplica ninguna regla rara, porque tendrá un puerto mapeado para tal efecto, que dirá: Todo lo que me llegue por aquí, lo envías al NAS. Y el NAS? Podría tener el NAS algún firewall para filtrar ciertas conexiones? Sí, técnicamente si puede, podría por ejemplo bloquearte dependiendo de mil factores (ya te digo que no lo hace), pero en cualquier caso sería el servidor VPN quien lo hiciese.
Entonces, que "bloquea" realmente tu Router?? Simple, si alguien intenta desde Internet sin iniciar tu la comunicación, por ejemplo, abrir en menos de 5 segundos 20 conexiones TCP. Entonces el Router salta y dice, ei!! Espera más lento, ahora te dejo solo una conexión en los siguientes 10 segundos. Y aun así la conexión no se corta, una vez la conexión se establece en TCP se puede mantener abierta. Obviamente esto no tiene tampoco nada que ver con lo que te pasa
No tienes que configurar la interfaz VPN, tienes que configurar el cliente WireGuard si quieres estar segura, y echar un ojo a la configuración del servidor. Y si quieres estar segura si tus paquetes son o no adecuados, hay un modo como te dije terriblemente simple: Wireshark, que es un analizador de paquetes y puedes ver de forma simple el tamaño de los paquetes:
Mira el tamaño de los paquetes, algunos mas pequeños, otros mas grande... en este caso la mayoría son de 1506 porque he realizado queriendo nu test de velocidad para que saliesen lo más grande posible. Dirás inmediatamente: Ei ei ei!! Me has mentido, ahí pone 1506, me habías dicho que no más de 1500!!. No exactamente, 1500 es el MTU máximo, el Payload que puede llevar un frame Ethernet, no el frame Ethernet en sí mismo. El Frame Ethernet tiene su propia cabecera (las direcciones MAC) que son 14 Bytes (también algunos CRC y otros pero esa información normalmente la quita el adaptador de red directamente). Así que sis restas: 1506 - 14 = 1492Bytes!! Ummmm no llega a 1500Bytes?? No, porque si los paquetes fuesen de 1500, al pasar por el Router y añadirle la cabecera PPP que son 8Bytes más, fallo. Por eso son 1492. Y lo mejor de todo... mi interfaz de red no está a 1492, está a 1500. El Router negocia con el destino 1492, y le pasa le testigo al equipo, al equipo le llega un paquete que dice: Vas a usar 1492, y el equipo a partir de ese momento solo envía paquetes de máximo 1492.
Por qué esto es muy útil?? Porque si tienes un problema de MTU con cualquier VPN, lo puedes ver, literalmente. Si por cualquier motivo ves que de tu equipo sale un paquete mayor de 1506, ya sabes que se va a descartar. La mayoría serán mas pequeños, pero si es una transferencia mas grande o cualquier cosilla más importante, subirá.
Esto no solo te afecta a ti, porque el problema también podría suceder en el otro lado, al servidor VPN. Como??? Pues simple, del mismo modo que tu no puedes enviar a más de 1492, no puedes tampoco recibirlo. Si un origen te envía un paquete con un payload de 1500Bytes... no te va a llegar... no es que lo vaya a descartar tu Router, es que no llega a ti siquiera!! En cuando el paquete llegue al BNG de Movistar, bendiciones y buenas noches.
De ahí que te dijese que es imprescindible configurar correctamente tanto servidor como cliente VPN, no las interfaces, esas por lo general no deberían dar problemas, sino el propio Software.
Es que he leído que algunos routers de operadora, al realizar una inspección de estado de paquetes (SPI) o por tablas NAT saturadas, cortan sesiones VPN largas cuando detectan mucho tráfico UDP cifrado, confundiéndolo con saturación o ataques, ¿puede suceder?
¡Hola de nuevo! Mil gracias por la clase magistral de redes. Me ha quedado clarísimo el concepto de las 'muñecas matrioskas' y cómo el paquete interno puede romper el externo si no calculamos bien las cabeceras PPPoE y de la VPN. De verdad, técnica y lógicamente, tu explicación es impecable.
Sin embargo, hay un dato que me tiene totalmente descolocada y que creo que rompe esta lógica en mi caso particular:
Como comenté antes, ya he configurado el MTU de la interfaz de la VPN en 1280. Si hacemos las matemáticas que propones:
Incluso siendo generosos con las cabeceras, nos quedamos en 1348 Bytes, muy lejos del límite de 1500 (o 1492 de PPPoE). Es decir, mi 'caja' es mucho más pequeña que el 'túnel', por lo que no debería haber fragmentación ni descartes por tamaño, ¿esto es correcto? Perdón, pero es que estoy muy machacada con esto, y me cuesta ver la solución
Entiendo perfectamente tu pregunta, pero tiene una explicación realmente sencilla, y es, de hecho, lo que nos dice entre otras cosas que es precisamente ese el problema. Vamos a ver dos puntos importantes aquí que citas, la posibilidad de que sea el Router que tenga algún tipo de problema, sea como dices tráfico masivo, Firewall... que sea MTU, que en otros sitios funcione bien...
1º. Por qué VPN falla y no falla una conexión normal
Precisamente por como funciona una VPN. No sé por qué en el colectivo se ha quedado que una conexión VPN es un puente mágico que te conecta a otro lado... no hay nada de mágico, TODO tu tráfico sigue pasando por la red del ISP y otras redes, igual que cualquier otro tipo de tráfico. Las VPN nacen de la necesidad de poder acceder a una red local privada, sin estar físicamente conectada a ella. Y si se entiende este concepto, se entiende el resto.
Sí tú estás en tu red y te quieres conectar a otro equipo de tu misma red, tu equipo y el de tu red se intercambian frames Ethernet sin problema a 1500Bytes. El interior de este paquete puede ser perfectamente este esquema (IPv4), es simplificado porque el frame Ethernet tiene otras cosas, pero para el MTU es lo que nos interesa:
Cabecera IP (20Bytes) + Cabecera TCP (20Bytes) + Payload (Datos, hasta 1460Bytes)
Eso es un paquete IPv4 básico que usa TCP. Con 1500Bytes podemos enviar por tanto datos "válidos" por un total de hasta 1460Bytes. En ese paquete tu le puedes decir al equipo de tu red que quieres descargar un archivo de 2MB. Obviamente el archivo de 2MB no cabe en esos 1460Bytes, así que se "parte" en muchos paquetes de 1460Bytes: 2MB = 2097152 Bytes. A 1460 Bytes por paquete necesitamos 1437 paquetes, 1436 completos y el 1437 no ocupará los 1460Bytes, usará solo 592Bytes. Y esto funciona a la perfección.
Este esquema es extremadamente similar a si descargas un archivo desde Internet... con un pequeño cambio, cuando el Router negocia el MTU con el servidor destino, no nos permite usar 1500, así que el esquema ahora es ligeramente diferente:
SIN VPN: Cabecera PPPoE (8Bytes) + Cabecera IP (20Bytes) + Cabecera TCP (20Bytes) + Payload (Datos, hasta 1452Bytes)
El cálculo es igual, solo que ahora tenemos menos datos que podemos meter. ahora necesitamos 1445 paquetes, 1444 completos y el último pues 464Bytes solo.
Ahora bien, esto cambia totalmente cuando usas una VPN, el esquema es totalmente diferente. El paquete que te llega/envías está encapsulado dentro. Por usar el mismo esquema vamos a suponer que usamos una VPN bajo UDP. Ahora el paquete que importa no es el de fuera, es el de dentro!!
Mira que pasa si dejásemos exactamente el mismo paquete anterior encapsulado
Paquete que nos interesa, donde se va a transmitir realmente la información útil:
UTIL = Cabecera IP (20Bytes) + Cabecera TCP (20Bytes) + Payload (¿Cuantos Bytes?, donde van los pedazos )
Pero es una VPN, lo tenemos que encapsular dentro de un paquete externo. Este es el paquete Externo:
Cabecera PPPoE (8Bytes) + Cabecera IP (20Bytes) + Cabecera UDP (8Bytes) + Payload (Datos, hasta 1464, Cabecera VPN + UTIL)
¿Ves ahora el problema? El Router negocia sin problema el paquete externo que él controla y ve, pero tu estás construyendo con la VPN en el payload de ese paquete un paquete completo. El paquete de fuera no puede exceder los 1500, la VPN necesita saber obligatoriamente con cuantos Bytes cuenta para crear el paquete que hemos llamado UTIL. Sin VPN es simple, ya lo hemos puesto arriba "SIN VPN). Ahora eso no nos vale, porque si la VPN coge ese paquete y lo mete dentro, rompe el tamaño. Suponiendo siempre IPv4, Wireguard requiere una cabecera de 32Bytes si no recuerdo mal, con lo que con eso ya puedes hacer digamos toda la "suma". Si el MTU de la VPN fuese de 1500, el paquete final sería
PERO!! Esto no es una norma, y ha ignorado que podemos usar una conexión PPPoE...
Cabecera PPPoE (8Bytes) + Cabecera IP (20Bytes) + Cabecera UDP (8Bytes) + Payload (32Bytes + 1440Bytes (Cabecera IP + Cabecera TCP + Payload)) = 1508 Bytes... Se JOD***
¿¿Lo entiendes ahora?? En una retransmisión normal esto da exactamente igual, tu equipo sabe perfectamente que tiene que crear payload de 1492, aun cuando la interfaz física esté en 1500, el Router negocia 1492Bytes, y tu equipo cualquier cosa que envíe a Internet lo hace asumiendo 1492. Y lo hace perfectamente!! Y por eso funciona todo perfectamente. El problema aparece cuando pasas a la VPN el control de ese payload, y mete más de lo que puedes meter. Ni el PC ni el Router pueden negociar el tamaño que debería de tener el Payload interno
2º. ¿Por qué no puede ser el Router?
Te lo expliqué en el otro mensaje. Para el Router el es totalmente indiferente el contenido que hay en ese Payload. El Router lo único que ve es (en el caso de UDP)
Cabecera PPPoE (8Bytes) + Cabecera IP (20Bytes) + Cabecera UDP (8Bytes) + Payload (Datos, hasta 1464Bytes)
-El Router no sufre absolutamente NADA con eso. -El Router no sabe siquiera que estás usando una VPN -El Router es capaz, sin despeinarse, de procesar velocidades de todo lo que de tu fibra. -El Router no tiene la menor idea de lo que tú metes en el Payload.
El Payload puede ser desde un paquete VPN, un paquete de control, un simple paquete ping, fragmentos de un archivo de 500GB... puede ser lo que te de la gana, al Router le resbala a dos manos (y perdóname la expresión) lo que quieras meter en el Payload. El Router no tiene que procesar nada, no toca ese payload, ni siquiera lo mira. Lo único que le va a importar al Router es que el paquete sea conforme a lo que dicta los estándares: Que no esté corrupto, que las cabeceras sean correcta, que el tamaño sea correcto..... Lo que tú quieras meter en el Payload, es cosa únicamente tuya. El único que mira el payload en este caso es el servidor VPN y el cliente VPN. Ellos son los que procesan el paquete.
Cuando el paquete llega al servidor VPN hace el proceso inverso. Elimina el paquete externo que es el vehículo que ha permitido que le llegue a él, se queda con el Payload que es lo que él necesita. Ese Payload es a su vez cabecera y datos encriptados, que una vez los desencripta es un paquete Ethernet con su cabecera IP, con su cabecera TCP (probablemente) y con el Payload de datos útiles. Y esto mismo lo hace tu cliente VPN cuando recibe un dato del servidor VPN.
Para el Router todo ello es totalmente invisible. El Router no bloquea absolutamente nada, el Router no sabe siquiera que es o no es tráfico de una VPN, el Router no detecta ningún tipo de inundación de nada. En absoluto es tráfico UDP masivo!! tráfico masivo archivos de 30MB?? Ni de 30 ni de 500GB. El Router puede transferir sin problema velocidades sostenidas de 1Gbit (Unos 110MB/s aprox, 110x8) tanto en subida como en bajada (simultáneamente) durante horas o días si quieres. Si eso fuese una tarea "pesada" para el Router, no podrías entonces navegar ni descargar nada a más de unos pocos MB/s. Que sea UDP además en vez de TCP es aun menos trabajo para el Router, porque el tráfico UDP no requiere mantener una conexión activa bidireccional, por eso se usa UDP en vez de TCP, por eficiencia, UDP es más rápido pero tiene menos "control", por eso es el preferido para las VPN (ojo, se puede usar perfectamente TCP con WireGuard y con cualquier VPN, simplemente la velocidad de transferencia será menor, no porque el Router sea mejor o peor, es por como funciona UDP y como funciona TCP, TCP requiere constantemente que el que recibe vaya informando al emisor que va llegando cada pedacito... )
