Switching

 View Only

  • 1.  EX4100 802.1X stuck in Connecting state with intermittent RADIUS unreachable events

    Posted 12 days ago
    Hi everyone,
     
    I'm troubleshooting an 802.1X issue on a Juniper EX4100 managed by Mist.
     
    Note: the IP addresses below are fictional placeholders used only to mask the real environment. They are not the actual production IPs.
     
    Environment
    - Switch: Juniper EX4100
    - Management: Mist
    - Access control: 802.1X
    - RADIUS server: NAC platform
    - RADIUS IP: 198.51.100.25 (placeholder)
    - Authentication port: 1645
    - Source address from the switch: 192.0.2.10 (placeholder)
    - Interface under test: ge-0/0/16
     
    Current behavior
    - The port is up/up
    - 802.1X is enabled and the authentication profile is applied
    - The interface stays in "Connecting"
    - In some tests the switch detects the supplicant MAC, but authentication never completes
    - No entries appear in "show dot1x authentication-failed-users"
    - No MAC is learned in the ethernet-switching table for the interface
     
    Relevant configuration
    - authentication-profile-name dot1x
    - server-reject-vlan BLACKHOLE
    - server-fail vlan-name BLACKHOLE
    - supplicant mode: multiple
    - reauthentication interval: 65000
     
    Relevant logs
    - AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 198.51.100.25 set to UNREACHABLE (profile dot1x)
    - DOT1XD_MAJOR_EXCEPTION_LOG: Authentication client could not contact RADIUS servers
    - Then later the same server returns to ALIVE
     
    What I already checked
    - Basic IP connectivity from the switch to the RADIUS server works with ping
    - The 802.1X profile is correctly applied to the interface range in Mist
    - The access VLAN is correctly assigned
    - The issue is reproducible on the same interface
     
    My questions
    1. Does this pattern usually indicate a real RADIUS service instability, or could it still be caused by 802.1X client behavior on the endpoint?
    2. Is there any EX4100-specific behavior with dot1x/authd that could cause periodic RADIUS UNREACHABLE/ALIVE events even when ping works?
    3. Would you recommend temporarily removing the server-fail BLACKHOLE behavior for troubleshooting?
    4. Are there additional EX4100 commands or traceoptions you recommend to isolate whether the failure is before EAP exchange completion or on the RADIUS backend side?
     
    Any guidance would be appreciated.
    Thanks.

    Note: all IP addresses in this post are intentionally fictitious placeholders to protect the real environment. The issue is not related to an incorrect IP configuration.


    ------------------------------
    CLEITON DA SILVA DOS SANTOS
    ------------------------------


  • 2.  RE: EX4100 802.1X stuck in Connecting state with intermittent RADIUS unreachable events

    Posted 10 days ago

    Hi

    You are using port 1645. Which is the legacy RADIUS port, the modern standard is 1812. If your NAC platform is listening on 1812 but Mist is pushing 1645 (or vice versa), the switch will never get a response

    Have checked that?


    Original Message


  • 3.  RE: EX4100 802.1X stuck in Connecting state with intermittent RADIUS unreachable events

    Posted 6 days ago

    Thanks.

    In this case, however, the FortiNAC deployment is operating in Local RADIUS mode. Per Fortinet documentation, UDP 1645 is the default authentication port for Local RADIUS Server, whereas UDP 1812 is the default for Proxy RADIUS mode.

    So in this environment, the use of 1645 is intentional and aligned with the FortiNAC configuration model. Because of that, the current symptom does not by itself indicate a wrong port selection.



    ------------------------------
    CLEITON DA SILVA DOS SANTOS
    ------------------------------

    Original Message


  • 4.  RE: EX4100 802.1X stuck in Connecting state with intermittent RADIUS unreachable events

    Posted 5 days ago

    Hello, 

    I have quite a few EX4100s using 802.1x, but I'm not familiar with FortiNAC.  My first thought is I wonder if there's any logging on the FortiNAC that you could look at.  It might be helpful to see if requests are reaching the radius server at all when the switch is reporting the unreachable status.  I've not run into this particular behavior with 802.1x on our EX4100s.



    ------------------------------
    CHRIS ROBERTS
    ------------------------------

    Original Message


  • 5.  RE: EX4100 802.1X stuck in Connecting state with intermittent RADIUS unreachable events

    Posted 4 days ago

    Hi,

    Can the switch telnet to the RADIUS server on the required port? A successful connection confirms reachability on that port. If configured, test this from the relevant routing instance (e.g., mgmt_junos). For example, in the outputs below, telnet to Mist NAC on the RADSEC port (2083) works for me. If telnet fails, NAC reachability on the required port should be checked first (e.g., firewall blocking the port)

    {master:0}
mist@XXXXXX> telnet 15.197.139.214 port 2083   
Trying 15.197.139.214...
Connected to af968536c6cd68bc1.awsglobalaccelerator.com.
Escape character is '^]'.
^C^C^CConnection closed by foreign host.

{master:0}
mist@XXXXXXX> telnet radsec.nac.mist.com port 2083 
Trying 15.197.139.214...
Connected to radsec.nac.mist.com.
Escape character is '^]'.
^C^C^CConnection closed by foreign host.

mist@XXXXXXXX> show system connections | match 2083    
tcp4       0      0  10.x.x.x.54815                            3.33.153.159.2083                             ESTABLISHED
tcp4       0     60  10.x.x.x.63152                            15.197.139.214.2083                           ESTABLISHED

    Regards



    ------------------------------
    Sheetanshu Shekhar
    ------------------------------

    Original Message