Cloud Managed Networks

Odd Arne,

To what level in the hierarchy did you configure your WLAN? In the past, for tunneled SSIDs, these had to be on Device Group Level (and Roles had to be on Global. If you have not done that, please try and see if it makes a difference.

From the logging, it appears that the RadSec connection isn't established; which indeed can be the reason for a DOT1X Authentication Server timeout.

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

Good find, and thanks for coming back with it. That explains why nothing on the ClearPass side ever looked wrong.

Setting Secure RADIUS Trusted CA on that profile pushes radsec-trusted-cacert-name down to the gateway, and once the line is there the gateway will only accept a server certificate chaining to that named CA. The Central NAC RadSec endpoint is not signed by it, so the TLS session dies before RADIUS ever happens. Remove the line and the gateway falls back to its normal trust. It presents exactly like a certificate that was never issued, which is why it sends everyone off looking at certificates.

The part worth flagging for anyone else landing here: sys_central_nac is write-protected today, but a tenant that predates the protection can still be carrying an edit made back when it was not, and nothing in the UI will tell you. If Central NAC is failing on a tenant with any real history, pull the gateway config and look for radsec-trusted-cacert-name on that profile before you go near certificates.

Since you had to use disaster recovery mode to clear it, worth asking TAC to confirm the supported way to reset that field once they reverse it, so you have a documented path if it turns up on another gateway.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

Good find, and thanks for coming back with it. That explains why nothing on the ClearPass side ever looked wrong.

Setting Secure RADIUS Trusted CA on that profile pushes radsec-trusted-cacert-name down to the gateway, and once the line is there the gateway will only accept a server certificate chaining to that named CA. The Central NAC RadSec endpoint is not signed by it, so the TLS session dies before RADIUS ever happens. Remove the line and the gateway falls back to its normal trust. It presents exactly like a certificate that was never issued, which is why it sends everyone off looking at certificates.

The part worth flagging for anyone else landing here: sys_central_nac is write-protected today, but a tenant that predates the protection can still be carrying an edit made back when it was not, and nothing in the UI will tell you. If Central NAC is failing on a tenant with any real history, pull the gateway config and look for radsec-trusted-cacert-name on that profile before you go near certificates.

Since you had to use disaster recovery mode to clear it, worth asking TAC to confirm the supported way to reset that field once they reverse it, so you have a documented path if it turns up on another gateway.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

Good find, and thanks for coming back with it. That explains why nothing on the ClearPass side ever looked wrong.

Setting Secure RADIUS Trusted CA on that profile pushes radsec-trusted-cacert-name down to the gateway, and once the line is there the gateway will only accept a server certificate chaining to that named CA. The Central NAC RadSec endpoint is not signed by it, so the TLS session dies before RADIUS ever happens. Remove the line and the gateway falls back to its normal trust. It presents exactly like a certificate that was never issued, which is why it sends everyone off looking at certificates.

The part worth flagging for anyone else landing here: sys_central_nac is write-protected today, but a tenant that predates the protection can still be carrying an edit made back when it was not, and nothing in the UI will tell you. If Central NAC is failing on a tenant with any real history, pull the gateway config and look for radsec-trusted-cacert-name on that profile before you go near certificates.

Since you had to use disaster recovery mode to clear it, worth asking TAC to confirm the supported way to reset that field once they reverse it, so you have a documented path if it turns up on another gateway.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

As Dustin states with DR mode. That has been my experience as well across reboots. I had issues with VGW and license. I was able to change it by using the resource https://central.wifidownunder.com and pushing CLI settings to the group to correct the license in the running config. If I was looking at this issue, I would probably start with using API's to see if I can grab the output of the config and see if its listed anywhere. Based on my experiences so far with CNX and API's. If nothing is displayed its using default values or non configured values. I would find it hard to believe that this setting does not exist via API in CNX. 

Good find, and thanks for coming back with it. That explains why nothing on the ClearPass side ever looked wrong.

Setting Secure RADIUS Trusted CA on that profile pushes radsec-trusted-cacert-name down to the gateway, and once the line is there the gateway will only accept a server certificate chaining to that named CA. The Central NAC RadSec endpoint is not signed by it, so the TLS session dies before RADIUS ever happens. Remove the line and the gateway falls back to its normal trust. It presents exactly like a certificate that was never issued, which is why it sends everyone off looking at certificates.

The part worth flagging for anyone else landing here: sys_central_nac is write-protected today, but a tenant that predates the protection can still be carrying an edit made back when it was not, and nothing in the UI will tell you. If Central NAC is failing on a tenant with any real history, pull the gateway config and look for radsec-trusted-cacert-name on that profile before you go near certificates.

Since you had to use disaster recovery mode to clear it, worth asking TAC to confirm the supported way to reset that field once they reverse it, so you have a documented path if it turns up on another gateway.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.

As Dustin states with DR mode. That has been my experience as well across reboots. I had issues with VGW and license. I was able to change it by using the resource https://central.wifidownunder.com and pushing CLI settings to the group to correct the license in the running config. If I was looking at this issue, I would probably start with using API's to see if I can grab the output of the config and see if its listed anywhere. Based on my experiences so far with CNX and API's. If nothing is displayed its using default values or non configured values. I would find it hard to believe that this setting does not exist via API in CNX. 

Good find, and thanks for coming back with it. That explains why nothing on the ClearPass side ever looked wrong.

Setting Secure RADIUS Trusted CA on that profile pushes radsec-trusted-cacert-name down to the gateway, and once the line is there the gateway will only accept a server certificate chaining to that named CA. The Central NAC RadSec endpoint is not signed by it, so the TLS session dies before RADIUS ever happens. Remove the line and the gateway falls back to its normal trust. It presents exactly like a certificate that was never issued, which is why it sends everyone off looking at certificates.

The part worth flagging for anyone else landing here: sys_central_nac is write-protected today, but a tenant that predates the protection can still be carrying an edit made back when it was not, and nothing in the UI will tell you. If Central NAC is failing on a tenant with any real history, pull the gateway config and look for radsec-trusted-cacert-name on that profile before you go near certificates.

Since you had to use disaster recovery mode to clear it, worth asking TAC to confirm the supported way to reset that field once they reverse it, so you have a documented path if it turns up on another gateway.

Hi.

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec
  radsec-trusted-cacert-name sys_central_nac
!  

aaa authentication-server radius "sys_central_nac"
  host naw2.cloudguest.central.arubanetworks.com
  nas-identifier xxxxxxxxxxxxxxxxxxxxx
  radsec-port 2083
  timeout 20
  key xxxxxxxxxxxxxxxxxxxxxxxxxxx
  enable-radsec

!

Odd Arne, your logs narrow this down more than you might think. The cert request is leaving the gateway and Central is accepting it, so this is not a firewall or connectivity problem on your side. Central simply is not issuing.

First thing to undo: the downgrade to 10.7.2.6 was never going to work. Overlay authentication with Central NAC is documented as 10.8.0.0 and later, so stay on 10.8.1.

The thing I would check next is whether your WLAN is a library profile or a local one. The Central NAC docs are explicit that the WLAN and port profiles have to be shared objects in the library, and that local profiles cannot be used with Central NAC. A profile created with "Create as a local profile" ticked looks identical in the UI but is a different object. There is a closely matching thread, "Central NAC, problem with wired authentication" on a 6100, where the trust anchor profile was never pushed and the root cause turned out to be scope assignment rather than firmware.

Also worth confirming: both the Overlay WLAN and the WLAN SSID need to be scope mapped, not just the SSID. A site has to exist and your gateways need to be assigned to it. And since you have moved config back and forth a few times, look for stale objects reusing the same ESSID across scopes, which the Central NAC caveats call out as unsupported.

Two quick ones on the gateway: show aruba-central and check the Trusted CA Cert Name field, and show ntp status for clock skew.

If all that is clean then it is cloud side. When you open the TAC case, lead with the fact that the request leaves the gateway and Central never responds, otherwise they will spend a week on your firewall.