HPE Mist Networking

Hi Juniper Community,

We are currently troubleshooting a CoA behavior in a Juniper Mist Edge deployment and would like to validate the expected flow and the recommended troubleshooting path.

Environment summary:
- Juniper Mist Edge running as a VM
- VM deployed following the official Mist Edge VM requirements
- Tunneled WLAN through Mist Edge
- RADIUS Proxy enabled through Mist Edge
- CoA/DM Server enabled
- External RADIUS server / Cisco ISE used for guest portal authentication
- WLAN used for guest/captive portal access
- Client traffic is tunneled through Mist Edge

What we are observing:
- The wireless client associates successfully to the SSID.
- DHCP, Gateway ARP, and DNS are successful in the Mist client events.
- Portal redirection is shown as "Processed" and then "In Progress".
- The RADIUS server appears to send the CoA/DM request.
- However, after the CoA, we do not see the expected re-authentication event in Mist/Mist Edge logs.
- The client remains stuck in the final portal redirection stage and does not appear to move to the final authorization state.

Based on the Mist Edge documentation, the expected behavior after CoA is:
1. RADIUS server sends the CoA request.
2. Mist Edge sends a CoA ACK.
3. Mist Edge/Mist Cloud redirects the CoA/DM to the correct AP/client.
4. A new RADIUS authentication exchange should occur.
5. The final Access-Accept should no longer include the redirect URL.

In our case, this final re-authentication does not appear to be happening.

Questions:
1. Which logs should we collect on Mist Edge or Mist Cloud to confirm that the CoA was correctly mapped to the right AP/client?
2. Should the post-CoA re-authentication be visible in the Mist client event timeline, or only on the RADIUS server side?
3. Are there mandatory RADIUS attributes required for CoA matching, such as Event-Timestamp, Calling-Station-Id format, Acct-Session-Id, NAS-IP-Address, or any Mist-specific attributes?
4. Could this behavior be related to a mismatch between the RADIUS NAD IP, Mist Edge OOBM IP, Tunnel IP as Source, or the CoA/DM server configuration?
5. Is there any specific limitation or additional requirement when Mist Edge is deployed as a VM for tunneled WLAN + guest portal + CoA?
6. Is there any recommended packet capture point to validate the CoA flow end-to-end: ISE → Mist Edge → Mist Cloud → AP/client?

We also attached a screenshot from the Mist client events showing DHCP Success, Gateway ARP Success, DNS Success, and Portal Redirection Processed/In Progress, but no visible re-authentication after CoA.

Any guidance would be appreciated.

Thank you.

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

The CoA has to go where the Access-Request came from. With RADIUS proxy on, ISE sees the Mist Edge as the NAS, not the AP, so the network device in ISE needs the Edge's RADIUS source address with CoA enabled, on the same port and secret you set in the WLAN's CoA/DM Server section (ISE defaults Cisco devices to port 1700, so check it against the Mist side). Then it has to be a message Mist acts on: a Disconnect with Admin-Reset, or a reauth carried as Cisco-AVPair subscriber:command=reauthenticate. Port bounce and port shut are ignored, per the Mist CoA page: https://www.juniper.net/documentation/us/en/software/mist/mist-wireless/topics/concept/coa.html. The Mist ClearPass Guest guide shows the attribute set that works, Calling-Station-Id, NAS-IP-Address and Event-Timestamp plus that AVPair, which is what to mirror in ISE: https://www.juniper.net/documentation/us/en/software/mist/mist-wireless/topics/task/arubaguestintegration.html.

The discriminator is ISE's CoA result in the live log plus a capture of that port on the Edge's RADIUS interface. No packet: wrong address or port. CoA-NAK with an Error-Cause: secret or attributes. CoA-ACK but no second Access-Request for that MAC on ISE: the reauth type. A good run shows that second Access-Request and an Accept without the redirect.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------