MAC Auth + Device Type (DHCP Fingerprint) NAC Rule

[Anonymous]

Hi,

I would like to create a rule that matches on MAC auth, with a End-System and Device Type group set.

There is an initial issue with doing that in that the MAC auth takes place before the end-system has had a chance to get an IP address from the DHCP server and therefore no fingerprint to use in the Device Type match.

Now I believe the answer to this was to create a rule that allows MAC auth, then another rule that tested against the device type once it got an IP address from DHCP?

Issue is I’m not clear on the process, what triggers the re-auth to re-run through the NAC rule engine  (believe that has something to do if the end-system receives a new bit of information?), and how the NAC and Policy Roles and Rules would be laid out to achieve this?

Be grateful for any advise?

Many thanks in advance

[Anonymous]

Hi Zdenek,

Thanks for getting back.

Ok, great, think I’ve got it.

So in the last example I provided I have the Default Catch ALL left to Guest VLAN.

For the device type identification I have the same rule in twice, just the second rule will have my ‘Deny Access’ policy rule and the first rule the actual one I need…

That should work, thanks 🙂

[Zdeněk_Pala]

Hi Martin.

yes the following approach works:

• new ES is connected to the network
• rule like default catch all will trigger and apply profile “Deny IPv4”
• the Deny IPv4 does allow DHCP
• the ES start DHCP and Engine resolve the device type
• NAC automatically reevaluate rules and if there is match with different NAC profile assigned then it does trigger reauth
• this time rule with “device type” will be activated and new policy is applied

The trap:

• in the lab environment, many engineers apply different rules but the same profile = for testing purposes. The engineer expect to see Rule change. But the NAC will not trigger reauth as the result will be the same. You need to have a different profile assigned, otherwise the change will not be triggered.

[Anonymous]

Hi Ryan,

Thanks for posting a reply.

I’ve created a deny role below (default action permit traffic) and applied it to the default catch all rule in NAC.

The idea behind this is that all foreign devices will not be able to access the network due to the IPV4 deny, but will still be able to ARP, DHCP and DNS. Once the device has an IP from DHCP it should reatuh and then hit my earlier NAC rule with the ‘Device Type’ inclusions - Do you think that would work?

The scenario I can’t picture is if I wanted the Default Catch All to place end-systems into a Guest VLAN, and therefore I need to create NAC rule that would capture the ability to get an DHCP address and provide this function.

For example, I create a NAC rule with authentication type set only to MAC and add it sits just above the default catchall, apply the same policy role / rules. All end-systems would effectively hit this NAC rule if no match is found, including my Guest devices. They would get an IP and re-auth, at this point I need it to skip past this NAC rule and hit my Default Catchall Rule and be placed in the Guest VLAN.

I would perhaps have to put an ‘invert’ statement in that same NAC rule, although I can’t see what? 

Be great if NAC supported IF, AND, NOT, OR, statements, so for example I could put ‘invert’ End-System Group AND End-System Group, if you understand what I mean.

Going to be something more simple, just can’t see it 🙂

Many thanks,

Martin

[Ryan_Yacobucci · Accepted solution]

Hello Martin,

You got it. The answer is to create another rule that allows MAC auth below it with a different profile. 

“Device Type” information is information that is learned from a DHCP packet, so it’s not available to be evaluated on the initial authentication of the device.The client needs to be authorized into a profile/Role that allows DHCP, then DHCP packet then gets to the NAC and then NAC learned the device type information.

The process that triggers reauthentication is that when the hostname/device type family information is updated the NAC performs an “internal” reauthentication evaluation because of the field change. It re-runs the rules engine evaluation to determine if the new information will result in a rule change. If it determines a different profile is returned based on the new information the NAC reaches out with the re-authentication request. 

So DHCP packet is received. 
NAC identifies there is a hostname or device type/device family change AND there’s a rule that matches on this criteria so it runs a rule engine evaluation

NAC identifies different profile returned based on new information

NAC reauthenticates the device and it pops into the new rule.

If the DHCP packet is not received because the client hit a deny all rule because of the initial rule miss you can see why the rest of the process doesn’t work. This is the reason for the “placeholder” rule when it comes to “learned” or “after the fact” information like device family or hostname (LDAP host group rule)

Let me know if this helps.

Thanks

-Ryan