Security

Hi,

802.1x clients (mainly windows clients) seem to work fine. Also other clients that authenticates with MAC seems fine. I can see logs and getting in the network in  ClearPass no issues.

Some headless clients (i.e. printers) it is a another story, and only some of them. I will give a specific example:

- printer access the network

- the port goes IMMEDIATELY  in "Blocked by AAA".

- I have no logs of the switch ever trying to authenticate with ClearPass, switch simply blocks the port.

Port configuration:

aaa port-access authenticator A2 client-limit 10
aaa port-access authenticator A2 cached-reauth-period 86400

aaa port-access mac-based A2 addr-limit 10
aaa port-access mac-based A2 reauth-p period 86400

Other ports with same configuration just work fine.

Another issue i have is that issuing "no aaa port-access authenticator active" DOES NOT stop the authenticator AT ALL, i have to issue "no port-access authenticator [list of ports]', same for MAC, which is a pain, I thought that command would globally stop the authenticator process no matter if the port was in or not.

Switch is 5406zl2 running KB.16.05.0007

Clearpass is 6.7.5

thanks

Possibly open a Case with TAC

Hi,

I've the same issue with a 2920 (SW: WB.16.04.0016). This seem's to be with my vlan-configuration, cause I can replicate the problem to another ports, when I change the static VLAN-Settings to a "quarantine-vlan"

This issue happens only, when I connect a VoIP-Phone. It works fine with workstations/Windows-Clients independent of the port configs.

For example:

Config, where the log shows instantly "Blocked by AAA"

interface 2/30
   untagged vlan 66
   aaa port-access authenticator
   aaa port-access authenticator client-limit 3
   aaa port-access mac-based
   aaa port-access mac-based addr-limit 3
   exit

Config, where the telefone works and the NAD sends a request to CPPM

interface 2/25
   tagged vlan 17
   untagged vlan 12
   aaa port-access authenticator
   aaa port-access authenticator client-limit 3
   aaa port-access mac-based
   aaa port-access mac-based addr-limit 3
   exit

VLAN 17 = VoIP

VLAN 12 = Clients

VLAN 66 = Quarantine

I don't understand why this happens. I think, there could be something with lldp provisioning.

Is there any update/progress with this issue?

I am experiencing the same problem.

Hi,

The problem is that when you set up authentication on a port, the switch blocks the port until the device announce itself (i.e. generate any type of traffic). Most of these devices "do not talk unless talked to", whereas there might be Windows server polling printers, these printers are now isolated as they won't talk back because they don't receive any traffic, and the port stays blocked because the switch is not polling the device either.

There are essentially two solutions:

- you configure the port as described in the ClearPass best practice (it is linked on several threads in here). This WILL NOT work UNLESS you set up something on the end device to poll something at regular intervals. An example is to configure NTP on the printer to poll to NTP server. This is traffic generated from the printer itself, this will keep the port up.

- OR you configure like this, but it is not best practice (this applies config from port 1/1 to 1/10). Do this only on port you know are NOT uplinks:

no port-security 1/1-1/10 eavesdrop-prevention

spanning-tree 1/1-1/10 admin-edge-port

aaa port-access authenticator 1/1-1/10 auth-vid xx

aaa port-access authenticator 1/1-1/10

aaa port-access authenticator 1/1-1/10 client-limit 2

aaa port-access authenticator 1/1-1/10 cached-reauth-period 86400

aaa port-access 1/1-1/10 controlled-direction in

aaa port-access mac-based 1/1-1/10

Aaa port-access mac-based 1/1-1/10 addr-limit 4

aaa port-access mac-based 1/1-1/10 reauth-period 86400

aaa port-access mac-based 1/1-1/10 cached-reauth-period 86400

aaa port-access mac-based 1/1-1/10 logoff-period 9999999

I want to point out that we went on with HPE TAC for MONTHS without them realizing this, I got the answer bumping on a thread on reddit talking more or less matter by pure chance, from there and after couple of hours of testing, i came out with the above config. You dont need to run recent firmware for that to work. Test on a bunch of ports first. If you break **bleep** I am not taking responsability, you do at your own risk.

I just came off a 2hr session with TAC. No real progress.

I think you are right in regards to trying to keep the device talking.

It seems some devices become quiet after a period of time, and once the arp entry times outs the switch (aaa) places the port into blocked status.

You can "wake up" the device by disabling and enabling the port (bounce), and then everything works. For how long I'm not sure though.

Ive also noticed that whenever you make a config change to the interface, specifically in regards to aaa port-access, you must bounce the port.

Thank you for your insight.

With a NAC solution quiet devices needs always attention. The default logoff period is 300 seconds, which is to short for devices like printers.

A really good solution is to use the ip client tracker feature. The client tracker will send ARP requests to a client to make sure it's sending traffic. 

Example config:

ip client-tracker trusted
ip client-tracker probe-delay 15

ip arp-age 3

The ARP age at the switch needs to be lower than the logoff period. If the logoff period is 300 seconds (the default) make sure the arp age is lower than the 300 seconds, for example 3 minutes.

However, some devices like the 2920 switch, doesn't support the config option ip client-tracker probe-delay. In that case this will result in some duplicate IP's issues with Windows. There is no really duplicate IP in the network but Windows thinks that there is a duplicate IP if there is no probe delay. In that case, don't use the client tracker feature.

An other option is to specify the logoff period in the user-role. So this gives us the option to specify a logoff period for devices like printers. It's also possible to set the logoff period to 0 in the user-role. This will disable the logoff period on a period, so the same as mac pinning.

I never disable the eavesdrop-prevention to find a solution for this 'issues'.

Thanks for an excellent explanation.

Is there any difference between logoff-period =0 and mac-pinning?

Why would you use 1 over the other?

What other effects (negative and positive)  would setting  a long logoff-period?

Ip client trusted does not work, the switch never polls the device. We tried this and switch was running latest version at the time (TAC forced us to upgrade to latest).

The log off timeout is irrelevant if the device never logs on in the first place, which is basically the "problem". I say "problem" because it is not Arubas fault as it is working as designed (Cisco works this way too), but the fact that nobody in HP/Aruba had the knowledge to point this out was the frustrating part, considering the premium costs of ClearPass.

I have found that setting the logoff-period to 999999 has resolved my problem.

If a device is active , that is, link state on switch port is UP and MAC is learnt, is this not sufficient criteria to be "logged-on"?

I can't think of a scenario where an active device is not logged on.....

logged on means that the device you connect start sending traffic otherwise the port get stuck in "blocked by AAA". If the port is blocked by AAA state, the log off period will never start because the device is not logged on (went past the AAA) in the first place.

It might work on certain devices, in my experience and especially on old dumb printers, that does not work, you need to enable the controlled direction in so the printer is polled by something on the network and when they try to respond, they then pass the AAA (provided ClearPass is configured properly at that point). 

If you have all latest printer models with no other devices in the middle (we, for example, have badge scanners for secure printing), then you should even to authenticate them via 802.1x. But with all printers that is the only way we found that consistently works.

logoff period 0 is the same as MAC pinning, atleast in the latest releases.

IP client tracker is working and is doing his job. However, some (legacy) devices doesn't respond to the ARP requests of the switch.

When a device connect and is not sending traffic at all NAC can be difficult. This is not something that can be fixed on switches (also not other vendors) because it's a client problem. Best way to deal with this is using DHCP on the client. I have also seen some devices that are not send traffic at all unless they receive some data. Some times a workaround is to set the untagged VLAN at to port to the port where the device belongs to and set the control direction to inbound. This will flood broadcast/multicast data to the port even if the port is blocked by AAA.

I have set the logoff-period to something large, and also set the controlled-direction to inbound only.

This seems to have resolved most if not all my problems.

Thank you all for your help, without this forum I would still be stuck pulling my hair out.