Wired Intelligent Edge

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

yes, I didn't remember if i mentioned it here, or in my email chain with our implementation engineer and SE, that when i tweaked the policy to just allow everything onto the primary vlan and not get tunneled, it was working fine. I believe that was when i discovered i didn't have the IP-Helper information in the tunnel node VLAN

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

No you didn't :-) No problem. So switch is working correctly. Now you have a problem on the tunnel side. You can debug dhcp packets on the switch where GW is connected to see, if it receive DHCP responses. You will need to trace dhcp request/response and try to see, where it get lost.

Other option is to use device profiling on the originating switch if it support this function. But dhcp is quicker.

Best, Gorazd

yes, I didn't remember if i mentioned it here, or in my email chain with our implementation engineer and SE, that when i tweaked the policy to just allow everything onto the primary vlan and not get tunneled, it was working fine. I believe that was when i discovered i didn't have the IP-Helper information in the tunnel node VLAN

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

Additional question here. Why you would allow unprofiled devices to go to UBT? Wouldn't be easier to have profiling vlan locally?

I can think of several examples for UBT to be beneficial like no need to propagate another vlan across network, have firewall on GW available,...

Best, Gorazd

No you didn't :-) No problem. So switch is working correctly. Now you have a problem on the tunnel side. You can debug dhcp packets on the switch where GW is connected to see, if it receive DHCP responses. You will need to trace dhcp request/response and try to see, where it get lost.

Other option is to use device profiling on the originating switch if it support this function. But dhcp is quicker.

Best, Gorazd

yes, I didn't remember if i mentioned it here, or in my email chain with our implementation engineer and SE, that when i tweaked the policy to just allow everything onto the primary vlan and not get tunneled, it was working fine. I believe that was when i discovered i didn't have the IP-Helper information in the tunnel node VLAN

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

We do not span vlans between 75 campus switches, so it makes more sense for us, as a community college, to tunnel unidentified machines to the controller. At the controller, we can apply FW rules. To have a profiling vlan would require us to create a profiling VLAN and have it span across 75 switches (about 15000-18000 ports between those switches). We're trying very hard to keep unique vlans at each switch, to reduce noise and keep the config clean at each switch.

Additional question here. Why you would allow unprofiled devices to go to UBT? Wouldn't be easier to have profiling vlan locally?

I can think of several examples for UBT to be beneficial like no need to propagate another vlan across network, have firewall on GW available,...

Best, Gorazd

No you didn't :-) No problem. So switch is working correctly. Now you have a problem on the tunnel side. You can debug dhcp packets on the switch where GW is connected to see, if it receive DHCP responses. You will need to trace dhcp request/response and try to see, where it get lost.

Other option is to use device profiling on the originating switch if it support this function. But dhcp is quicker.

Best, Gorazd

yes, I didn't remember if i mentioned it here, or in my email chain with our implementation engineer and SE, that when i tweaked the policy to just allow everything onto the primary vlan and not get tunneled, it was working fine. I believe that was when i discovered i didn't have the IP-Helper information in the tunnel node VLAN

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

We do not span vlans between 75 campus switches, so it makes more sense for us, as a community college, to tunnel unidentified machines to the controller. At the controller, we can apply FW rules. To have a profiling vlan would require us to create a profiling VLAN and have it span across 75 switches (about 15000-18000 ports between those switches). We're trying very hard to keep unique vlans at each switch, to reduce noise and keep the config clean at each switch.

Additional question here. Why you would allow unprofiled devices to go to UBT? Wouldn't be easier to have profiling vlan locally?

I can think of several examples for UBT to be beneficial like no need to propagate another vlan across network, have firewall on GW available,...

Best, Gorazd

No you didn't :-) No problem. So switch is working correctly. Now you have a problem on the tunnel side. You can debug dhcp packets on the switch where GW is connected to see, if it receive DHCP responses. You will need to trace dhcp request/response and try to see, where it get lost.

Other option is to use device profiling on the originating switch if it support this function. But dhcp is quicker.

Best, Gorazd

yes, I didn't remember if i mentioned it here, or in my email chain with our implementation engineer and SE, that when i tweaked the policy to just allow everything onto the primary vlan and not get tunneled, it was working fine. I believe that was when i discovered i didn't have the IP-Helper information in the tunnel node VLAN

I think you misunderstood me. Use a role without UBT (local vlan) for profiling to see if profiling is working correctly.

Best, Gorazd 

Right now, our tunneled "role" is fairly relaxed in its policy. We loosened the policy as I was testing the ability for me to check that a desktop PC got into the correct VLAN remotely. So all that to say, the machines in the tunneled VLAN do still have access to the DHCP servers, etc.

I'll perform some additional testing with new devices. I'm not particularly happy with our current DHCP setup. There's some quirks in how the engineer set that server up, and I feel like some machines don't always do a full DHCP discover when they land in new VLANs, etc. 

You can try to use a specific role for devices not yet profiled before you send them to UBT. This role can have DHCP, DNS and HTTP(s) access and should disconnect/bounce port when profiling is done. Then you will have endpoint database updated before you create UBT.

Best, Gorazd

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?

ClearPass will process an incoming DHCP packet for profile data as soon as it arrives and will immediately update the endpoint repository with the associated data. 

around 9:24 this morning was when i bounced the switch port and it still had no profile information

at 10:08 AM, it looks like the switch got some profile information and did a self "bounce" of the port, likely because it got the profile information, and came back with the proper information. Is that kind of delay normal, or potentially something in our environment?

Adding the ip-helper information into the VLAN's where tunneled devices end up did not help get the profiling information. I'm not sure if there is considerable delay, but 20+ minutes later, there is still nothing.

We'll try to troubleshoot the tunneled role a bit more. I don't know if the DHCP server is hanging onto the lease too long and isn't sending the full DHCP discover packet, thus the server is not getting the profile information.

I believe you are correct. For this project, our Aruba engineer set up a brand new clearpass server. I had added the publisher IP to all wired VLANs, but then I think i forgot to add the IP Helper for that new IP to the vlan where wireless/tunneled devices go.

I'm going to add that now and delete the devices from the endpoint repository and test again, and see how it goes. 

Hi @HornAlum,

You describe that the resulting policy uses a tunnelled node enforcement profile from the switch to the controller and by the looks of your screenshots it appears that the client does not have a profile in the endpoint repository. I suspect that something is stopping the DHCP request from reaching ClearPass in order to establish profile categorisation. To troubleshoot this, try setting things so that [Other] tips role ends up in a user VLAN where DHCP traffic is forwarded to ClearPass. Then check the endpoint repository for the MAC address of your Access Point to see if it gets the data. You can clear this multiple times in the endpoint repository while you are testing. If this works then you need to look into why the profiling isn't working with the tunneled node configuration. 

When the client traffic is tunneled to the controller is the controller the L3 gateway for the user VLAN or is an upstream switch the L3 gateway? Do you know if traffic flows appropriately in this tunneled node configuration?

Keep pushing... you must be close!

We're still in the development and testing stages of a project involving wired security. Spent a few months on 802.1X and trying to get TEAP auth working, and now i'm circling back to MAC auth, for non-windows devices. Something seems to have broken where most of the devices I'm trying to connect to my test switch are getting the "Failed to get value for attributes"

Here, I'm testing with an Aruba AP plugged into the physical ports. It's failing to get any profiling/fingerprint/attribute information. The only thing it sees is the client-mac-vendor, which is listing it as Hewlett Packard Enterprise. I'm not exactly sure what could have broken with this service.

I currently have my dhcp-helper settings on all my VLAN's pointed at the clearpass servers just so i can watch clearpass gather some profile information from DHCP traffic alone, but when it comes to actually performing the real fingerprinting on an authenticated port, it seems to have stopped working:

Because it fails to get a tips role, it defaults to the "OTHER" role, during which my enforcement profile tunnels it off to the controller using the tunneling methodology.

What could i be missing? some kind of default / startup role?