Impresoras entre oficinas: solucionar «Lo veo pero no imprime» sobre VPN

Un modelo mental práctico: ver una impresora vs imprimir en ella

«La veo» no es una prueba significativa. Normalmente significa una de estas cosas:
el dispositivo respondió a un eco ICMP, la interfaz de descubrimiento de Windows encontró un broadcast mDNS/WS-Discovery local,
las comparticiones del servidor de impresión son visibles, o existe un objeto de conexión obsoleto del mes pasado.
Nada de eso prueba que el cliente pueda completar la ruta de impresión real.

La impresión es una cadena. Rompe cualquier eslabón y el usuario percibe el mismo resultado: no sale nada, la cola se queda atascada o «Error – Imprimiendo».
Tu trabajo es identificar qué eslabón falló:

• Descubrimiento: cómo encontró el usuario la impresora (GPO, manual, mDNS, WS-Discovery, LDAP, «Agregar una impresora»).
• Establecimiento de la conexión: handshake TCP y autenticación al servicio de impresión (SMB, IPP, LPD, raw 9100).
• Spooling: dónde se renderiza y almacena el trabajo (spooler del cliente vs servidor de impresión vs disco/memoria de la impresora).
• Transporte: los bytes cruzan la VPN, sobreviven a peculiaridades de MTU/MSS y son permitidos por firewall/NAT.
• Aceptación en el dispositivo: la impresora acepta el trabajo y lo imprime (o lo rechaza silenciosamente por formato, ACLs o ajustes de función).

Sobre VPN, la división más común es: ICMP funciona, SMB/IPP no; o SMB funciona pero la impresión se traba a mitad de flujo;
o los trabajos llegan al servidor de impresión pero nunca alcanzan el dispositivo porque el servidor no puede enrutar al subred de la sucursal.

Cita para llevar en el bolsillo cuando alguien dice «pero hace ping»:
idea parafraseada — Vint Cerf, en muchas formas a lo largo de los años: poder enviar paquetes no significa tener una aplicación funcionando.

Guion rápido de diagnóstico (comprueba 1/2/3)

Comprobación 1: ¿Dónde se spolea realmente el trabajo?

Decide si el cliente está imprimiendo directo a la impresora (IPP/9100/LPD) o a través de un servidor de impresión (Windows Print Server, CUPS).
Esta única decisión cambia todo el árbol de resolución de problemas.

• Si es servidor de impresión: ¿puede el cliente alcanzar al servidor por VPN? ¿Puede el servidor alcanzar la impresora en la LAN de la sucursal?
• Si es directo: ¿puede el cliente alcanzar la IP de la impresora en el puerto requerido y sostener una transferencia TCP larga?

Comprobación 2: Prueba el protocolo real de impresión, no el ping

Identifica el protocolo y puerto:
la impresión SMB suele implicar TCP 445 hacia el servidor (luego el servidor habla con la impresora).
IPP suele ser TCP 631.
JetDirect raw es TCP 9100.
LPD es TCP 515.
Luego prueba ese puerto de extremo a extremo desde la máquina que origina el trabajo.

Comprobación 3: Busca señales de “muere a mitad de trabajo” (MTU/MSS, timeouts de firewall stateful)

¿Imprime una página o dos y luego se cuelga? ¿O las páginas de prueba pequeñas imprimen pero los PDFs grandes nunca?
Eso suele ser MTU/fragmentación, problemas de clamp MSS en TCP, o un firewall/NAT stateful que vence timeouts de flujos de larga vida.
La impresión es básicamente “transferencia de datos a granel con actitud”.

Hoja de consulta rápida de clasificación

• Cola atascada en el cliente: spooler/driver del cliente, autenticación al servidor de impresión.
• Cola atascada en el servidor: conectividad servidor→impresora, renderizado/driver en el servidor, ACLs de la impresora.
• El trabajo desaparece: la impresora rechaza el formato, la política de la impresora lo elimina o el servidor reintenta y finalmente abandona.
• Salida parcial: MTU/MSS, VPN inestable, DPI/IPS que interfieren con IPP/SMB o límites de memoria/almacenamiento de la impresora.

Broma #1: Ping es el equivalente de la impresora a saludar a alguien por la ventana—gesto bonito, no contrato de trabajo.

Datos interesantes y contexto histórico (los grandes éxitos de la impresión)

• Puerto raw 9100 (JetDirect) se volvió popular porque es muy simple: abrir TCP, enviar bytes, esperar lo mejor. La seguridad no era la prioridad.
• LPD/LPR viene de los primeros días de UNIX y aún vive en muchas impresoras porque a los fabricantes no les gusta eliminar la “compatibilidad heredada”.
• IPP (Internet Printing Protocol) fue diseñado para ser más amigable con Internet que LPD y usa semánticas HTTP—ideal para WAN cuando está bien configurado.
• La impresión en Windows históricamente se apoyó en SMB/RPC y distribución de drivers. Conveniente internamente y molesto a través de enlaces restringidos.
• Bonjour/mDNS discovery hizo que las impresoras “simplemente aparecieran” en redes locales—y luego confundió a todos cuando las VPN no reenviaban multicast.
• PostScript vs PCL eran guerras religiosas; hoy son principalmente “qué driver hace que este PDF deje de explotar”.
• Los fabricantes añadieron almacenamiento onboard para spooling y retención de trabajos; cuando ese disco se llena, las impresoras pueden fallar de formas que parecen redes.
• El endurecimiento de SMB en la última década (signing, encriptación, deprecaciones) mejoró la seguridad pero aumentó la fragilidad entre sitios si las configuraciones no son consistentes.
• Los cambios tras PrintNightmare empujaron a las organizaciones a repensar instalaciones de drivers y políticas de point-and-print; la impresión por VPN se rompió de maneras nuevas y creativas.

Mapa de fallos: dónde falla el “la veo”

1) El descubrimiento miente (o al menos exagera)

Los usuarios «ven» impresoras vía objetos en caché, mapeos GPO antiguos o una lista de comparticiones del servidor de impresión. Eso no garantiza:
que las credenciales sean válidas, que el servidor sea alcanzable por la ruta de red correcta, o que la impresora detrás del servidor esté en línea.

2) Enrutamiento VPN y split tunneling no son neutrales

El split tunnel es genial hasta que el servidor de impresión es “interno” pero el rango IP de impresoras es “sucursal”, y el cliente hace hairpin incorrectamente.
O el DNS devuelve una dirección interna a la que el cliente no puede enrutar.
O la VPN no empuja rutas para las VLANs de impresoras porque alguien decidió que “las impresoras son de bajo riesgo”.
(No lo son. Ejecutan sistemas operativos completos y almacenan documentos. Además, son exigentes.)

3) Las políticas de firewall suelen permitir ICMP pero bloquear puertos de impresión

Es común ver ICMP permitido para troubleshooting, mientras que TCP 9100/631/515/445 está denegado a través de la VPN.
Eso no es automáticamente incorrecto—imprimir entre sitios es una decisión de seguridad—pero es la razón clásica por la que «puedo hacer ping» se convierte en una trampa.

4) Problemas MTU/MSS y de fragmentación aparecen como “los trabajos se cuelgan”

Los streams de impresión pueden ser grandes y de larga duración. La sobrecarga de IPsec, encapsulación GRE o una configuración de MTU demasiado ambiciosa pueden crear agujeros negros donde
paquetes más pequeños tienen éxito y los más grandes desaparecen. Obtienes impresiones parciales, colas atascadas e intermitente «funciona para página de prueba».

5) Autenticación e identidad fallan entre dominios y túneles

La impresión SMB a través de un servidor Windows puede fallar porque el cliente no puede obtener tickets Kerberos (DNS/mapeo de sitios AD),
los relojes están desincronizados o NTLM está restringido. La impresora aparece, se envían trabajos y luego obtienes acceso denegado o fallos silenciosos.

6) Drivers y renderizado pueden fallar sin errores evidentes

La VPN hace enlaces lentos. Enlaces lentos hacen que drivers y spoolers agoten tiempos.
Además, los drivers «universales» a veces son tan universales como la cinta americana: funcionan hasta que realmente no funcionan.

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

Estas tareas asumen que eres un SRE/operador con acceso a un jump box Linux, un servidor de impresión (Linux CUPS o Windows),
y opcionalmente un puesto de usuario. El objetivo es reducir la impresión a estados de red y spool medibles.
Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Tarea 1: Confirma la ruta al subred de la impresora (desde el origen real)

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

Significado: el tráfico hacia la IP de la impresora va por la interfaz VPN (tun0) y el gateway correcto.
Si ves un gateway local o una interfaz pública, estás haciendo split-tunneling en la dirección incorrecta.

Decisión: Si la ruta es incorrecta, arregla las rutas empujadas por la VPN / la tabla de rutas del cliente antes de tocar impresoras o drivers.

Tarea 2: Verifica que DNS resuelva el servidor de impresión como espera la VPN

cr0x@server:~$ getent hosts print01.corp.local
10.20.5.10     print01.corp.local

Significado: el nombre se resuelve a una IP interna. Si se resuelve a otra cosa (o no se resuelve), tu cliente puede estar usando DNS público.

Decisión: Arregla la configuración DNS de la VPN / split DNS. No codifiques IPs a mano a menos que te gusten los incidentes recurrentes.

Tarea 3: Prueba el puerto real de impresión (IPP 631) en lugar de ping

cr0x@server:~$ nc -vz -w 3 10.42.18.25 631
Connection to 10.42.18.25 631 port [tcp/ipp] succeeded!

Significado: el handshake TCP tuvo éxito. Si expira, es routing/firewall/política VPN, no un driver.

Decisión: Si está bloqueado, abre los puertos requeridos en la ruta VPN/firewall o cambia a un modelo con servidor de impresión.

Tarea 4: Prueba la conectividad de impresión raw (JetDirect 9100)

cr0x@server:~$ nc -vz -w 3 10.42.18.25 9100
Connection to 10.42.18.25 9100 port [tcp/*] succeeded!

Significado: el socket raw de impresión es accesible. Si 631 falla pero 9100 funciona, estás en una ruta de código distinta (y probablemente reglas de firewall diferentes).

Decisión: Prefiere IPP por manejabilidad cuando sea posible; usa 9100 solo si aceptas “menos control, más misterio.”

Tarea 5: Confirma el PMTU del camino (encuentra el agujero negro)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.42.18.25
PING 10.42.18.25 (10.42.18.25) 1372(1400) bytes of data.
1380 bytes from 10.42.18.25: icmp_seq=1 ttl=63 time=28.1 ms
1380 bytes from 10.42.18.25: icmp_seq=2 ttl=63 time=27.9 ms
1380 bytes from 10.42.18.25: icmp_seq=3 ttl=63 time=28.0 ms

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

Significado: el PMTU soporta paquetes ~1400 bytes sin fragmentación. Si ves «Frag needed» o timeouts a tamaños mayores, tienes un problema de MTU.

Decisión: Haz clamp MSS en la VPN/firewall, reduce MTU en el túnel o arregla el filtrado PMTUD.
No “arregles” esto cambiando drivers. Solo moverás el problema.

Tarea 6: Busca timeouts de firewall/NAT stateful (observa un stream)

cr0x@server:~$ sudo tcpdump -ni tun0 host 10.42.18.25 and tcp port 9100
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:04:11.123456 IP 10.8.0.12.53122 > 10.42.18.25.9100: Flags [S], seq 123456789, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
12:04:11.150000 IP 10.42.18.25.9100 > 10.8.0.12.53122: Flags [S.], seq 987654321, ack 123456790, win 28960, options [mss 1360,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0
12:04:11.150200 IP 10.8.0.12.53122 > 10.42.18.25.9100: Flags [.], ack 1, win 502, options [TS val 3 ecr 2], length 0

Significado: el handshake tuvo éxito. Si más tarde ves retransmisiones, RSTs o largos huecos, sospecha de middleboxes.

Decisión: Si las sesiones se reinician después de N segundos, ajusta los timers de sesión del firewall o enruta vía un servidor de impresión más cercano a la impresora.

Tarea 7: En servidor CUPS, lista impresoras y confirma device URI

cr0x@server:~$ lpstat -v
device for HR-Laser: ipp://10.42.18.25/ipp/print
device for Finance-Color: socket://10.42.18.30:9100

Significado: CUPS sabe a dónde envía trabajos. Un IP erróneo aquí puede persistir meses porque las impresoras “se mueven” y nadie actualiza el URI.

Decisión: Si el URI apunta a una subred antigua, corrígelo (lpadmin -p ... -v ...) y reintenta antes de depurar la VPN.

Tarea 8: En servidor CUPS, inspecciona el estado de la cola y el comportamiento de trabajos

cr0x@server:~$ lpstat -p HR-Laser -l
printer HR-Laser is idle.  enabled since Sun 28 Dec 2025 11:33:12 AM UTC
        Form mounted:
        Content types: any
        Printer types: unknown
        Description: HR-Laser
        Alerts: none
        Location: Branch-2
        Connection: direct

Significado: «idle» sugiere que CUPS no está bloqueado actualmente. Si dice «paused» o «stopped», es administrativo o por error.

Decisión: Si está en pausa, lee el log de errores y vuelve a habilitar. No sigas reenviando trabajos a una cola pausada.

Tarea 9: Envía una impresión de prueba controlada (pequeña, conocida buena)

cr0x@server:~$ printf "VPN print test: $(date -Is)\n" | lp -d HR-Laser
request id is HR-Laser-1042 (1 file(s))

Significado: El trabajo fue aceptado por el spooler. Si el usuario imprime un PDF de 200 páginas primero, no aprenderás nada salvo cuánta paciencia tienen tus colas.

Decisión: Si los trabajos pequeños funcionan pero los grandes fallan, pivota a MTU/timeouts/límites de spool.

Tarea 10: Sigue el error_log de CUPS mientras imprimes para capturar fallos a nivel de protocolo

cr0x@server:~$ sudo tail -n 30 -f /var/log/cups/error_log
E [28/Dec/2025:12:10:22 +0000] [Job 1042] Unable to connect to 10.42.18.25:631 - Connection timed out
E [28/Dec/2025:12:10:22 +0000] [Job 1042] Backend returned status 1 (failed)

Significado: Esto no es un problema de driver. Es un timeout de conexión al puerto IPP de la impresora desde el servidor.

Decisión: Arregla el enrutamiento/firewall desde el servidor CUPS hasta la subred de la impresora, o coloca la impresora detrás de un proxy de impresión local.

Tarea 11: Valida que el servidor de impresión pueda alcanzar la impresora (no solo el cliente)

cr0x@server:~$ traceroute -n 10.42.18.25
traceroute to 10.42.18.25 (10.42.18.25), 30 hops max, 60 byte packets
 1  10.20.5.1  0.451 ms  0.389 ms  0.377 ms
 2  10.8.0.1   12.401 ms  12.380 ms  12.355 ms
 3  10.42.0.1  22.110 ms  22.099 ms  22.087 ms
 4  10.42.18.25  28.022 ms  27.991 ms  27.975 ms

Significado: Hay un camino enrutado real. Si muere en el salto 2 o 3, tu ruta site-to-site no está presente donde crees.

Decisión: Arregla la ruta de red del servidor de impresión hacia las VLANs de la sucursal; no pierdas tiempo reinstalando impresoras en clientes.

Tarea 12: En Linux, busca reglas de firewall locales que bloqueen salidas de impresión

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

Significado: La política de salida es accept; la entrada permite 631. Si tuvieras una política de salida drop, podrías estar bloqueando la conexión backend silenciosamente.

Decisión: Si la salida está restringida, permite explícitamente tcp dport 631/9100 hacia las subredes de impresoras.

Tarea 13: Comprueba la accesibilidad de la compartición en servidor de impresión Windows (SMB) desde un Linux

cr0x@server:~$ smbclient -L //print01.corp.local -U 'CORP\svc-print%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	HR-Laser        Printer   HR-Laser on Branch-2
	Finance-Color   Printer   Finance-Color on HQ
SMB1 disabled -- no workgroup available

Significado: La conectividad SMB y la autenticación funcionan; las comparticiones son visibles. Si esto falla, los clientes tampoco se conectarán de forma fiable.

Decisión: Si falla la autenticación, revisa la conectividad AD sobre VPN, la sincronización horaria y las políticas NTLM/Kerberos.

Tarea 14: Confirma la desviación horaria de Kerberos (clásico “funciona en LAN, falla por VPN”)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 12:15:02 UTC
           Universal time: Sun 2025-12-28 12:15:02 UTC
                 RTC time: Sun 2025-12-28 12:15:01
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El reloj está sincronizado. Si el reloj del cliente o servidor deriva, Kerberos falla y la impresión vía SMB puede degradarse en reintentos o acceso denegado.

Decisión: Arregla NTP/chrony/fuente de AD primero. No desactives Kerberos “para que la impresión funcione”. Así consigues un incidente de seguridad con papel.

Tarea 15: Comprueba el clamp MSS en el borde de la VPN (cuando los trabajos grandes cuelgan)

cr0x@server:~$ sudo iptables -t mangle -S | sed -n '1,80p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: MSS se clampa al PMTU para SYNs reenviados. Si falta esta regla en un entorno IPsec/GRE, los streams de payload grande pueden caer en agujeros negros.

Decisión: Añade clamp MSS (o equivalente en tu firewall/dispositivo VPN) en lugar de bajar MTUs arbitrarios en endpoints.

Tarea 16: Busca rechazo en el lado de la impresora (códigos de respuesta IPP)

cr0x@server:~$ ipptool -tv ipp://10.42.18.25/ipp/print get-printer-attributes.test
ipptool: Using port 631
ipptool: Printer supports IPP/2.0
ATTR: printer-state (enum) = idle(3)
ATTR: printer-is-accepting-jobs (boolean) = true
ATTR: printer-up-time (integer) = 582113

Significado: La impresora acepta trabajos y responde a consultas IPP. Si reporta que no acepta trabajos, está en pausa o devuelve errores de autorización, es configuración del dispositivo.

Decisión: Arregla la política de la impresora (ACLs, auth, retención de trabajos) o actualiza credenciales si usas IPP con autenticación.

Broma #2: Las impresoras son los únicos dispositivos “IoT” que pueden atascar tu día y luego exigirte rellenar sus sentimientos magenta.

Tres mini-historias corporativas desde las trincheras

Incidente causado por una suposición errónea: «Si hago ping, el puerto está abierto.»

Una compañía multinacional desplegó un nuevo cliente VPN con una “postura de seguridad más limpia”. Traducción: menos rutas, reglas de firewall más estrictas,
y una bonita interfaz que convenció a la dirección de que el problema estaba resuelto por diseño.
A la mañana siguiente, el personal de sucursales podía «ver» impresoras en la lista de agregar impresora de Windows (en caché de antes) y podían hacer ping a las IPs de impresoras.
La impresión fallaba por todos lados.

La respuesta inicial fue predecible: reinstalar drivers, quitar/añadir impresoras, reiniciar spoolers, reiniciar impresoras y—porque así es la vida corporativa—reiniciar la esperanza.
Nada cambió. Los trabajos se quedaban en “Spooling” o “Printing” para siempre. El helpdesk empezó a recopilar pantallazos como si montaran una exposición de arte.

La suposición errónea fue que el éxito de ICMP implicaba éxito de política. El firewall de la VPN tenía una regla que permitía ICMP a “subredes internas”
para troubleshooting, pero TCP 9100 y 631 no estaban permitidos desde clientes VPN a VLANs de impresoras. No fue malicioso.
Fue simplemente la ejecución de una idea de least privilege sin un modelo de amenaza para impresión.

La solución fue doble: permitir que los clientes VPN alcancen servidores de impresión, no las VLANs de impresoras; y asegurar que solo los servidores de impresión puedan alcanzar impresoras.
El equipo también reescribió el runbook: “Ping es opcional; siempre prueba el puerto real.” Casi podías oír la presión arterial colectiva bajar.

Optimización que salió mal: «Evitemos el servidor de impresión e imprimamos directo.»

Otra organización quiso “reducir dependencias” y “eliminar puntos únicos de falla”, así que impulsaron instalaciones directas a impresora.
Los usuarios se conectaban a impresoras por IPP o TCP raw, incluso desde casa por VPN. En la diapositiva parecía brillante.
Sin mantenimiento de servidores, sin distribución de drivers, sin drama de gestión de colas.

Funcionó—hasta que no. Las primeras grietas fueron sutiles: trabajos pequeños imprimían, trabajos grandes se atascaban.
Luego lo gordo: una actualización de firmware cambió los defaults TLS de IPP y clientes antiguos ya no pudieron negociar.
Media flota quedó a oscuras para el personal remoto. Localmente, el equipo de escritorio aún podía imprimir porque su camino LAN no atravesaba middleboxes de la VPN.

La “optimización” también multiplicó el radio de impacto. En vez de arreglar una configuración en un servidor de impresión, tuvieron que soportar un zoológico de clientes:
diferentes OS, versiones de driver, realidades de MTU diferentes, perfiles VPN distintos. Depurar se volvió un ejercicio de comparar el caos.

Finalmente reconstruyeron alrededor de un pequeño número de servidores de impresión por región, más una regla estricta:
los clientes VPN solo pueden imprimir a servidores de impresión, nunca directamente a subredes de impresoras.
No porque no confíen en los usuarios (bueno, un poco), sino porque las redes se comportan mejor cuando el salto de larga distancia está controlado y es observable.

Práctica aburrida pero correcta que salvó el día: «Servidores de impresión cerca de las impresoras, logs retenidos y una impresión de prueba.»

Una tercera compañía tenía una costumbre poco glamorosa: cada oficina tenía una pequeña VM con CUPS (o un servidor Windows),
colocada en la misma LAN que las impresoras. Los usuarios remotos imprimían a ese servidor por VPN. El servidor imprimía localmente.
Sin descubrimiento multicast. Sin impresión directa desde clientes remotos. Sin improvisación.

Cuando un cambio en la VPN introdujo un desajuste de MTU, los usuarios empezaron a quejarse de que los PDFs se colgaban a mitad de trabajo.
El equipo no tocó ni un driver al principio. Consultaron los logs de CUPS y vieron patrones consistentes de “connection reset by peer” en trabajos largos,
pero solo para el sitio cuyo encapsulado de túnel había cambiado.

Debido a que el diseño mantenía el tráfico de impresora local, solo tuvieron que hacer fiable la ruta VPN para cliente hacia servidor,
lo cual era más fácil: una IP, un conjunto de puertos y monitorización consistente. Aplicaron clamp MSS en el borde de la VPN,
verificaron con impresiones de prueba controladas y el incidente terminó sin rituales de reimagen de la flota.

La práctica no era innovadora. Simplemente era correcta. En ops, lo aburrido es una característica.

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

1) «La impresora aparece en línea, los trabajos quedan en ‘Printing’»

Causa raíz: Puerto bloqueado (TCP 631/9100/445) a través de la VPN; ICMP permitido, así que todos se engañan.

Arreglo: Prueba con nc -vz. Abre el puerto específico desde la fuente correcta (cliente→servidor o servidor→impresora).
Mejor: restringe a los clientes a imprimir solo a servidores de impresión.

2) «La página de prueba imprime, los PDFs no»

Causa raíz: Agujero negro MTU/MSS, timeout de firewall stateful o DPI/IPS interfiriendo con streams largos.

Arreglo: Pruebas de PMTU con ping -M do; habilita clamp MSS; ajusta timers de sesión; evita imprimir directo sobre VPN.

3) «El usuario puede añadir la impresora pero obtiene acceso denegado al imprimir»

Causa raíz: Falla de autenticación (problemas Kerberos sobre VPN, restricciones NTLM, credenciales en caché) o permisos de la compartición.

Arreglo: Valida DNS/sincronización horaria; confirma acceso SMB a comparticiones; corrige ACLs y supuestos de confianza de dominio.

4) «La cola del servidor de impresión muestra trabajos atascados en ‘Sending data’»

Causa raíz: El servidor no puede alcanzar la subred de la impresora (ruta faltante, firewall, enrutamiento asimétrico).

Arreglo: Desde el servidor de impresión, ejecuta traceroute y comprobaciones de puerto hacia la impresora. Arregla la ruta servidor→impresora.

5) «La impresora imprime duplicados intermitentemente o reanuda trabajos antiguos»

Causa raíz: Raw 9100 con reintentos + VPN inestable puede causar reenvío; la impresora no tiene contabilidad robusta de trabajos.

Arreglo: Prefiere IPP con estado adecuado; reduce reintentos; coloca un servidor de impresión local a las impresoras.

6) «Funciona en LAN, falla solo cuando es remoto»

Causa raíz: Split DNS, rutas faltantes, política VPN que limita VLANs de impresoras o métodos de descubrimiento que dependen de multicast.

Arreglo: Forzar impresión vía servidor alcanzable por VPN; configurar split DNS correctamente; dejar de depender de broadcasts de descubrimiento entre sitios.

7) «Los trabajos desaparecen sin rastro»

Causa raíz: Impresión directa desde cliente sin logs centralizados; la impresora descarta trabajos por formato/ACL/memoria.

Arreglo: Centraliza spooling y logging; consulta el registro/admin de la impresora; valida driver y lenguaje de la impresora (PCL/PS/PDF directo).

8) «Tras actualización de la VPN, solo una oficina no puede imprimir»

Causa raíz: Encapsulado/MTU específico del sitio; cambio de crypto/sobrecarga; regresión en la publicación de rutas.

Arreglo: Compara MTU/MSS y rutas entre sitios; usa pruebas controladas; aplica clamp o corrige la distribución de rutas.

Decisiones de diseño que evitan esto para siempre (o casi)

Regla #1: Los clientes remotos imprimen a servidores de impresión, no a VLANs de impresoras

Si tomas una única decisión de opinión de este artículo, que sea esta.
Imprimir directo a impresora por VPN es seductor porque parece simple: menos servidores, menos piezas móviles.
En la práctica, crea una superficie de soporte del tamaño de toda tu flota de endpoints.

Coloca servidores de impresión donde viven las impresoras (misma LAN, o al menos mismo sitio). Luego permite que usuarios VPN alcancen solo:
el/los servidores de impresión en un pequeño conjunto de puertos (SMB 445, IPP 631, quizá HTTPS para gestión).
Los servidores de impresión alcanzan las impresoras localmente. Obtienes observabilidad, drivers/renderizado consistentes y menos sorpresas de MTU.

Regla #2: Elige protocolos con intención

• IPP: mejor por defecto para WAN si está soportado; ofrece estado más rico y opciones modernas de seguridad. Aún necesita TLS correcto y políticas de firewall adecuadas.
• SMB a un servidor Windows: común en entornos Windows; funciona bien cuando DNS, tiempo y AD están limpios. Sensible a cambios de endurecimiento de políticas.
• Raw 9100: útil como último recurso y para rarezas de dispositivos; reporte de estado débil; reintentos pueden causar duplicados; la seguridad es “esperanza”.
• LPD: legado; mantenlo solo si es necesario. En VPN suele ser un “por qué seguimos con esto” en la conversación.

Regla #3: Monitoriza la cadena, no solo el dispositivo

Monitorizar “la impresora responde a ping” es mejor que nada y peor de lo que piensas.
Monitoriza:
la profundidad de cola del servidor de impresión, tasas de éxito de conexión backend, accesibilidad de puertos de impresora desde el servidor,
y salud del túnel VPN (latencia, pérdida de paquetes, MTU).
Si puedes graficar “trabajos atascados > 5 minutos”, detectarás fallos antes de que el CFO intente imprimir la nómina.

Regla #4: Haz que MTU/MSS sea aburrido

Los fallos de impresión en WAN son a menudo matemáticas de red. IPsec añade overhead. GRE añade overhead. Las etiquetas VLAN añaden overhead.
En algún punto, un dispositivo descarta fragmentos o bloquea mensajes ICMP de “necesita fragmentación” y PMTUD falla.
La solución suele ser clamp MSS o un MTU consistente en el túnel, no un driver nuevo.

Regla #5: Mantén la estrategia de drivers centralizada y conservadora

Si ejecutas servidores de impresión Windows, controla point-and-print y despliegue de drivers con intención.
Si usas CUPS, estandariza PPDs/paquetes de drivers y conserva una matriz de compatibilidad para los modelos comunes.
La peor estrategia de drivers es “lo que el usuario encontró en Internet cuando estaba enfadado”.

Listas de verificación / plan paso a paso

Paso a paso: diagnostica a un usuario que «lo ve pero no imprime»

1. Identifica la ruta: ¿directo a impresora o vía servidor? Obtén el URI/share de la impresora.
2. Identifica el protocolo: SMB 445, IPP 631, raw 9100, LPD 515.
3. Desde el origen: verifica la ruta a la IP/subred destino (ip route get).
4. Prueba el puerto: nc -vz a destino:puerto. Si falla, para y arregla red/política.
5. Si es servidor de impresión: desde el servidor, prueba alcance a la IP/puerto de la impresora. Confirma rutas y ACLs.
6. Envía un trabajo pequeño y controlado: una línea de texto; captura el ID del trabajo.
7. Lee logs: error_log de CUPS o Visor de eventos/Logs PrintService de Windows; busca timeouts, errores de auth, fallos de backend.
8. Si “pequeño funciona, grande no”: prueba MTU/MSS y mira con tcpdump; busca retransmisiones/resets.
9. Confirma que la impresora acepta trabajos: atributos IPP o interfaz admin de la impresora; revisa estado de retención/pausa/error.
10. Sólo entonces: considera problemas de driver/renderizado (mismatch de formato, PS vs PCL) si transporte y acceso están probados.

Paso a paso: endurece tu entorno para que este ticket deje de repetirse

1. Centraliza el spooling: servidor de impresión por sitio cerca de las impresoras; clientes remotos imprimen solo al servidor.
2. Restringe reglas de firewall: permite a clientes VPN acceder a servidores de impresión; permite a servidores de impresión acceder a VLANs de impresoras; bloquea todo lo demás por defecto.
3. Estandariza protocolos: elige IPP (o SMB a servidores Windows) como primario; documenta excepciones.
4. Arregla DNS y tiempo: split DNS para nombres internos; NTP/chrony consistente en clientes VPN y servidores.
5. Haz MTU explícito: configura MTU del túnel; aplica clamp MSS en bordes; valida con pruebas.
6. Instrumenta: profundidad de cola, tasas de error de trabajos, comprobaciones de accesibilidad de puertos desde servidores y métricas de salud de túneles.
7. Runbook: entrena al helpdesk para dejar de usar ping como prueba de vida.

Qué no hacer (porque se siente bien pero no soluciona nada)

• No reinstales drivers antes de haber probado que el puerto destino es accesible de extremo a extremo.
• No abras VLANs de impresoras ampliamente a clientes VPN “temporalmente”. Temporal es como las redes se convierten en lugares encantados.
• No dependas de descubrimiento multicast a través de VPN a menos que disfrutes depurar dominios de broadcast a las 2 a.m.
• No aceptes «funciona en LAN de HQ» como evidencia. Esa es otra red.

Preguntas frecuentes

1) ¿Por qué puedo hacer ping a la impresora por VPN pero no imprimir?

El eco ICMP puede estar permitido mientras que los puertos de impresión están bloqueados. O el enrutamiento es correcto para ICMP pero no para la ruta TCP real debido a enrutamiento de políticas.
Prueba el puerto real (631/9100/445) desde el cliente real.

2) ¿Deberíamos permitir que clientes VPN impriman directamente a impresoras?

Usualmente no. Aumenta la superficie de ataque y multiplica la complejidad de soporte.
Permite que los clientes VPN alcancen servidores de impresión y deja que los servidores hablen con las impresoras en las LAN locales.

3) ¿Qué protocolo es mejor para imprimir entre sitios?

IPP es generalmente la mejor opción amigable para WAN cuando está soportado y configurado de forma consistente.
En entornos centrados en Windows, la impresión SMB vía un servidor Windows también es común y viable—si DNS, tiempo y políticas están limpios.

4) ¿Por qué los trabajos pequeños imprimen pero los grandes fallan?

Eso es comportamiento clásico de agujero negro MTU/MSS o un dispositivo stateful que vence en conexiones largas.
Pruébalo con tests de PMTU y capturas de paquetes; arréglalo con clamp MSS o correcciones de MTU de túnel.

5) ¿Cuál es la forma más rápida de demostrar que no es un driver?

Desde la máquina que envía el trabajo, ejecuta una prueba de conexión TCP al puerto real (nc -vz printer 631 o al servidor de impresión en 445/631).
Si no puedes establecer una conexión TCP, los drivers no son tu primer problema.

6) ¿Por qué la impresión falla después de cambios en la VPN o el firewall?

Porque la impresión usa puertos específicos, conexiones de larga duración y a veces flujos de autenticación que dependen de DNS y tiempo.
Los cambios en la VPN a menudo alteran MTU, enrutamiento o reglas de política en formas que la navegación básica no expone.

7) ¿Cómo sé si el fallo es del lado del cliente o del servidor?

Rastrea dónde se atasca el trabajo. Si el trabajo nunca llega a la cola del servidor de impresión, es cliente→servidor (auth/red/spooler).
Si está atascado en el servidor “sending”, es conectividad servidor→impresora o rechazo del dispositivo.

8) ¿Y si debemos soportar impresión directa (no se permiten servidores)?

Entonces trata las impresoras como servicios de producción: asigna IPs estables, documenta puertos requeridos, monitoriza accesibilidad, estandariza drivers
y arregla MTU/MSS correctamente. Acepta también que el soporte será más lento y los incidentes más ruidosos.

9) ¿Puede hacerse fiable el “descubrimiento de impresoras” sobre VPN?

Puedes reenviar multicast o ejecutar proxies de descubrimiento, pero eso añade complejidad con valor cuestionable.
Prefiere despliegue gestionado (GPO/MDM) y servidores de impresión con nombres conocidos.

10) ¿Por qué a veces las impresoras rechazan trabajos sin aviso?

Mismatch de formato (PS/PCL/PDF directo), ajustes de política de trabajos, requisitos de autenticación, almacenamiento lleno o presión de memoria pueden causar descartes.
El spooling centralizado con logs hace esto visible; la impresión directa a menudo no.

Conclusión: siguientes pasos que realmente puedes hacer

Si estás atrapado en el bucle infinito de «lo veo pero no imprime», deja de tratar la impresión como un problema periférico mágico.
Es un servicio en red con protocolos, puertos, autenticación y flujos de datos de larga duración.
Abórdalo como harías con cualquier otra dependencia de producción: define la ruta, mide la ruta, registra la ruta.

1. Elige el modelo: clientes VPN imprimen a servidores de impresión; servidores imprimen localmente a dispositivos.
2. Codifica los flujos permitidos: cliente → servidor puertos; servidor → impresora puertos. Todo lo demás denegado.
3. Arregla MTU/MSS intencionalmente: clamp MSS o fija MTU del túnel; verifica con pruebas; deja de adivinar.
4. Instrumenta y crea runbook: profundidad de cola, logs de error y un guion de primeros 15 minutos que el helpdesk pueda seguir.
5. Estandariza drivers: reduce variabilidad, tickets y la rabia de tu yo futuro.

Haz eso, y la próxima vez que alguien diga «pero está en línea», tendrás una respuesta mejor que reiniciar la impresora y rezar.