authentication control-direction in - Host stop working

[Niklas.D]

So i was testing a new ACL and DACL, and notice that when made a shut and no shut, on the port where my lab host was at the machine would lose its  DHCP Adress, but after 10 secones it would regain the IP and then 1 sec later lose it again. 

this just repets. but when i remove the line authentication control-direction in it works fine. 

i have this line on all my Dot1x ports.

and this havent happend before. 

am i missing something when i am adding ACL/DACLs on the port? 

[Mike.Cifelli]

FYSA
When you configure an interface as unidirectional via the <authentication control-direction in> command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host.

When you configure a port as bidirectional via using the <authentication control-direction both> command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.

Lastly, that command enables 802.1x authentication with the wake-on-LAN (WoL) feature.

Try creating an acl that gets applied to the interface, and is then overridden by the dacl received from ISE via authz profile.
ip access-group Base_ACL in
...
#sh ip access-lists Base_ACL
10 deny ip any any
Good luck & HTH!

[Niklas.D]

Hi Mike 

FYSA? i dont understand that one :) 

So i already have a ACL

interface GigabitEthernet0/2
description 802.1X
switchport access vlan 32
switchport mode access
switchport voice vlan 14
ip access-group Pre-ISE in
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 2
spanning-tree portfast
spanning-tree bpduguard enable

ip access-list extended Pre-ISE
permit icmp any any
permit udp host 0.0.0.0 host 255.255.255.255 eq bootps

(this is just a test ACL) 

And then i have a DACL that is a any any 

what i want is that so if a client would connect to my network that would be infected it would not be able to use vlan 32 to spread to other clients on that network. even if most other clients will be verified and move to another vlan. 

and that seems to kinda work. until in this LAB i connect a PC, and the PC keeps losing the connection 

until i remove the "authentication control-direction in" 

[Mike.Cifelli · Accepted solution]

For Your Situational Awareness :)
IMO using this:
ip access-list extended Pre-ISE
permit icmp any any
permit udp host 0.0.0.0 host 255.255.255.255 eq bootps
Is going to allow a host to send pings (possible ping sweep) and bootp traffic. Remove the 'authentication control-direction in' and try with the Base_ACL I provided you. Run tests which include full onboarding (ie- normal authz network access & a rogue computer connection). Setup ISE default authz to push some sort of non-compliant dacl.

what i want is that so if a client would connect to my network that would be infected it would not be able to use vlan 32 to spread to other clients on that network. even if most other clients will be verified and move to another vlan.
-The Base_ACL will aide in deterring this situation should ISE connectivity be lost from the NAD. Ensure in ISE authz policies you have unique conditions so that any rogue computer will hit default. Hitting default policy should apply a non-compliant dacl and possibly move the rogue host into a blackhole. Good luck & HTH!