| Anterior | Siguiente |
| ERROR_IPSEC_IKE_QUEUE_DROP_NO_MM | ERROR_IPSEC_IKE_MM_DELAY_DROP |
ERROR_IPSEC_IKE_DROP_NO_RESPONSE
Qué indica Windows con ERROR_IPSEC_IKE_DROP_NO_RESPONSE
ERROR_IPSEC_IKE_DROP_NO_RESPONSE (13813, 0x000035F5) — No se recibió respuesta del par remoto.
IKE/AuthIP negocia autenticación, algoritmos, parámetros de SA y payloads antes de que el tráfico quede protegido. El punto exacto de la negociación decide qué evidencia es útil.
Condición que hay que demostrar
La evidencia debe explicar exactamente «No se recibió respuesta del par remoto» en el componente que devolvió el valor.
Puntos de verificación
- Registra timestamps de inicio, retransmisiones, respuesta del peer y tiempo en cola. Esto separa peer silencioso, backlog local y una negociación que supera su timeout.
- Comprueba pérdida/MTU/NAT y carga del servicio antes de aumentar timeouts; una cola saturada y una red sin respuesta requieren correcciones diferentes.
- Conserva como etiqueta de correlación «ipsec · ike · drop · no · response» y la descripción exacta «No se recibió respuesta del par remoto»; evita mezclar esta incidencia con otro código de la misma familia.
No confundir con
ERROR_IPSEC_IKE_MM_ACQUIRE_DROP (13809) significa «La solicitud de negociación de modo principal permaneció demasiado tiempo en la cola». Aquí la condición es «No se recibió respuesta del par remoto».
Tratamiento recomendado
Elimina la causa de cola, pérdida o peer silencioso antes de ampliar timeouts. Una negociación nueva debe progresar sin permanecer en el mismo punto de espera.
Prueba controlada
Una conexión con peer conocido termina con 13813. El trace se alinea con las SA activas y muestra la fase exacta —timing— donde diverge de una negociación sana; la corrección se prueba abriendo una SA nueva.
Comando o consulta útil
netsh trace start scenario=NetConnection capture=yes tracefile=C:\Temp\ipsec.etl ... reproduce the failure ... netsh trace stopDistinción diagnóstica específica
La condición propia de esta página es «No se recibió respuesta del par remoto.». El estado más cercano por contenido, ERROR_IPSEC_IKE_TIMED_OUT, describe en cambio «Se agotó el tiempo de espera de la negociación IKE.». Ambos comparten IPsec, IKE, pero aquí el discriminante operativo es descarte, no, response.
Sitúa este resultado en la fase de ciclo de vida de la SA y conserva SA concreta, peer, timestamps, estado Main/Quick Mode y transición inmediatamente anterior. Comprueba si IKE descartó la solicitud sin responder y qué validación motivó el descarte. No lo conviertas automáticamente en un timeout de red del peer.
Anota el primer punto donde aparece «descarte, no, response» y comprueba que la condición descrita por ERROR_IPSEC_IKE_TIMED_OUT no sea la que realmente se observa.
Prueba discriminante del estado
La investigación de este valor debe centrarse en descarte sin respuesta. Captura mensaje recibido, validación que lo descartó y ausencia deliberada de reply y úsalo para separar un drop local de esperar hasta timeout; esa evidencia separa este estado de errores IKE que aparecen en otra fase.
El código más parecido por estructura es ERROR_IPSEC_IKE_TIMED_OUT, cuya condición es «Se agotó el tiempo de espera de la negociación IKE.». Aquí Windows informa «No se recibió respuesta del par remoto.»; compara ambas frases con el trace y decide por el campo/objeto observado, no por pertenecer a la misma familia IPsec.
Como recuperación, corregir el mensaje que provoca el descarte y verificar que Windows sí responda.
Referencias técnicas
¿Buscas un código diferente? Buscar otro código de estado o error.