Windows L2TP carga algunos sitios: borra el bit DF en pfSense

El portátil se conecta, la intranet carga y un puñado de sitios públicos se cuelga. La autenticación y el enrutamiento funcionan con claridad, lo que deja el tamaño del paquete como explicación. En un túnel L2TP/IPsec la MTU utilizable es menor de lo que el adaptador sigue anunciando, y el cliente continúa enviando paquetes de tamaño completo con el bit de no fragmentar activado. A una pasarela pfSense se le puede ordenar que borre ese bit, y esa es la forma más rápida de confirmar el diagnóstico antes de arreglarlo bien.

Empieza por las páginas que fallan

Anota qué destinos fallan y cuáles funcionan antes de tocar ningún ajuste. Los apretones de manos que se quedan por debajo del límite del túnel se completan con normalidad, mientras que las transferencias que necesitan un segmento de tamaño completo se atascan a mitad de camino. Esa división es la firma de un problema de tamaño y no de un filtro, porque un destino bloqueado falla al establecer la conexión y no a mitad de la página. Ambas observaciones no cuestan nada y estrechan la búsqueda de inmediato.

Prueba con un ping que active el bit y controle el tamaño de la carga útil. La carga útil más grande que sobrevive te dice la MTU real de la ruta, y el valor anunciado del adaptador muestra qué tan lejos están los dos.

Apunta ambos números. La corrección depende de cuál esté mal, y el par es lo que una captura confirmará más adelante.

Qué hace el bit DF a la salida

La encapsulación es la razón de que los números difieran. IPsec añade ESP, L2TP añade otra cabecera, y por eso el túnel transporta menos carga útil que el enlace físico. Windows sigue informando de 1500 bytes en el adaptador y activa el no fragmentar en lo que envía. Cuando un paquete así no cabe, la respuesta correcta de la pasarela es un mensaje ICMP que pide al emisor que se reduzca. Por eso un túnel que pasa pings pequeños puede fallar igualmente al descargar un archivo.

Ese mensaje a menudo nunca llega. Algún salto puede filtrar ICMP, o nada lo genera, y el emisor repite el mismo tamaño hasta que la transferencia se rinde.

El silencio es la presentación normal aquí, por eso el síntoma se lee como un bloqueo selectivo. Nada en el registro del cliente anota un mensaje ICMP ausente.

La opción de pfSense, y lo que no hace

La opción está en la página Sistema, Avanzado, Cortafuegos y NAT, con la etiqueta «Borrar los bits DF no válidos en lugar de descartar los paquetes». En vez de descartar un paquete demasiado grande que lleva la marca, el filtro quita la marca y deja que el paquete se divida más adelante. Un paquete cuenta como no válido cuando no puede cruzar la interfaz de salida de una sola pieza.

La opción restaura la conectividad sin tocar el cliente, por eso es popular. También es un parche: la fragmentación cuesta CPU y hace más caro cada fragmento perdido.

Se aplica solo al tráfico reenviado, no al tráfico que origina el propio cortafuegos. La misma página ofrece «Desactivar el depurado del cortafuegos», que apaga la normalización por completo, y eso es un cambio mucho más amplio de lo que necesita este problema.

Una corrección más estrecha que mantiene TCP sin fragmentar

Casi todos los flujos atascados son TCP, y TCP puede negociar un segmento más pequeño en vez de depender de la fragmentación. Limitar el MSS en la interfaz del túnel reescribe el valor anunciado durante el apretón de manos, de modo que cada lado envía lo que realmente cabe. La ruta se comporta entonces de forma predecible y ningún paquete necesita dividirse.

Eso deja UDP al descubrimiento o a la opción DF. Cuando los sitios que fallan son páginas web corrientes, el límite es el cambio que conviene preferir.

El cliente puede informar de su propia MTU de adaptador mediante netsh interface ipv4 show subinterfaces. Compara esa cifra con la que el servidor cree haber negociado, porque las dos no siempre coinciden. Ese valor es el que el sistema operativo usará realmente, diga lo que diga la negociación.

Confirma con una captura y luego restablece el estado

Captura en ambos lados antes de decidir: una traza donde corre el túnel y otra donde corre la interfaz WAN. Los paquetes que salen a tamaño completo sin ICMP que regrese apuntan al límite como la capa correcta. Las respuestas que llegan y luego mueren a la vuelta apuntan en cambio a la MTU del túnel.

Vacía la tabla de estados antes de reintentar, porque los flujos existentes conservan sus tamaños de segmento antiguos. Después carga la página que falló y lee la vista de estados para el tráfico bidireccional en lugar de contadores de un solo lado. Si sigue atascándose, captura de nuevo en vez de probar otra casilla.