none
Radius autentificacion. RRS feed

  • Pregunta

  • Hola, tengo un servidor Windows Server 2012 configurado con servidor de directivas de red (NAP) con DHCP.

    Los equipos clientes son windows embedded 6, estos se conectan de forma inalambrica a unos access point y este a su vez al servidor donde les otorga el acceso por NAP y obtienen IP por DHCP, todo bien; excepto que tarda unos segundos en autentificar al cliente el servidor el NAP.

    He isntalado wireshark, para entender loqe sucede en realidad, debido al tiempo de respuesta del NAP.

    Como se observa en la captura, en el proceso de autentificacion radius, hay varias Access-Request y Access-Challenge  con diferente id, en promedio 5 veces en este proceso para cada cliente hasta que termina en Access-Acept, despues se completa en proceso de DHCP sin ningun problema.

    Mi pregunta es porque esta sucediendo esto cada vez que se conecta el cliente, toma demasiados Access-Request y

    Access-Challenge, cuando creo deberia ser solo una vez.

    Que esta sucediendo?

    jueves, 10 de enero de 2019 13:30

Respuestas

  • Desonozco de dónde has deducido que hay fragmentación, y que eso es lo que causa el problema, pero las últimas capturas muestran claramente que "More fragments = False"

    Me equivoqué con el tema IPv6, las direcciones "FF02::" son de multicasting y no direcciones de interfaces

    Este foro es de y para soporte para productos Microsoft, así que por favor recurre a la marca del AP

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 16 de enero de 2019 19:07
    Moderador

Todas las respuestas

  • https://1drv.ms/u/s!AnU8F7uZFLZBhHhTFmxftxZyZmti

    Link de la imagen dedibo a cuenta no verificada.

    jueves, 10 de enero de 2019 13:37
  • Hola Peter485, cosas para que puedas investigar un poco

    Hay algo en la captura que no veo normal: el "Access-Request" no tiene siempre el mismo tamaño, lo que me da a pensar que puede haber algo desde el punto de vista del AP

    Trataría de ver/interpretar el contenido del paquete a ver si encuentas diferencias, o cómo intenta en cada uno de los pedidos de acceso

    Si no lo has hecho ya, consultaría en el soporte del AP

    [Edito y agrego] Cuidado que 192.169.y.z es direccionamiento IP público

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.


    jueves, 10 de enero de 2019 13:53
    Moderador
  • lunes, 14 de enero de 2019 19:16
  • Hola gracias por la sugerencia, te comento que cheque los radius packets y hay diferencia entre los tamanos del paquete en el EAP message; donde el mensaje se fragmenta por la negociacion en TLS message, como se muestra en la figura

    lunes, 14 de enero de 2019 19:34
  • Creo que se debe a fragmentacion EAP-TLS
    lunes, 14 de enero de 2019 19:34
  • Entiendo que ese tráfico es entre el AP y el NAP, así que por eso como puse antes debes consultar al soporte del AP

    IPv6 no hace fragmentación "durante la ruta", es el emisor quien determina el tamaño máximo para el segmento, y eventualmente lo fragmenta

    Por otra parte se están usando direcciones IPv6 ULA cuyo uso está desaconsejado por haber sido declaradas como "deprecated" https://tools.ietf.org/html/rfc3879

    Recurre al soporte del AP porque son los que pueden saber si existe una solución para el tema

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    lunes, 14 de enero de 2019 20:00
    Moderador
  • Hola Guillermo, gracias por responder, he consultado con el soporte tecnico del AP, sin respuesta aun :(

    Realizando busquedas por internet me encontre con esto  link

    En donde propone cambiar el MTU size link

    no se si serviria inentarlo. Ademas habra una manera de debug el proceso de conexion en el cliente (windows embedded 6)

    Por otra parte a que te refieres con direcciones IPv6?

    Saludos.

    miércoles, 16 de enero de 2019 18:21
  • Desonozco de dónde has deducido que hay fragmentación, y que eso es lo que causa el problema, pero las últimas capturas muestran claramente que "More fragments = False"

    Me equivoqué con el tema IPv6, las direcciones "FF02::" son de multicasting y no direcciones de interfaces

    Este foro es de y para soporte para productos Microsoft, así que por favor recurre a la marca del AP

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 16 de enero de 2019 19:07
    Moderador