<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: authentication control-direction in - Host stop working in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4092785#M560711</link>
    <description>FYSA&lt;BR /&gt;When you configure an interface as unidirectional via the &amp;lt;authentication control-direction in&amp;gt; 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.&lt;BR /&gt;&lt;BR /&gt;When you configure a port as bidirectional via using the &amp;lt;authentication control-direction both&amp;gt; command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.&lt;BR /&gt;&lt;BR /&gt;Lastly, that command enables 802.1x authentication with the wake-on-LAN (WoL) feature.&lt;BR /&gt;&lt;BR /&gt;Try creating an acl that gets applied to the interface, and is then overridden by the dacl received from ISE via authz profile.  &lt;BR /&gt; ip access-group Base_ACL in &lt;BR /&gt;...&lt;BR /&gt;#sh ip access-lists Base_ACL&lt;BR /&gt;    10 deny ip any any&lt;BR /&gt;Good luck &amp;amp; HTH!</description>
    <pubDate>Wed, 27 May 2020 12:52:53 GMT</pubDate>
    <dc:creator>Mike.Cifelli</dc:creator>
    <dc:date>2020-05-27T12:52:53Z</dc:date>
    <item>
      <title>authentication control-direction in - Host stop working</title>
      <link>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4092645#M560708</link>
      <description>&lt;P&gt;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&amp;nbsp; DHCP Adress, but after 10 secones it would regain the IP and then 1 sec later lose it again.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;this just repets. but when i remove the line&amp;nbsp;authentication control-direction in it works fine.&amp;nbsp;&lt;/P&gt;&lt;P&gt;i have this line on all my Dot1x ports.&lt;/P&gt;&lt;P&gt;and this havent happend before.&amp;nbsp;&lt;/P&gt;&lt;P&gt;am i missing something when i am adding ACL/DACLs on the port?&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 27 May 2020 06:53:20 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4092645#M560708</guid>
      <dc:creator>Niklas.D</dc:creator>
      <dc:date>2020-05-27T06:53:20Z</dc:date>
    </item>
    <item>
      <title>Re: authentication control-direction in - Host stop working</title>
      <link>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4092785#M560711</link>
      <description>FYSA&lt;BR /&gt;When you configure an interface as unidirectional via the &amp;lt;authentication control-direction in&amp;gt; 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.&lt;BR /&gt;&lt;BR /&gt;When you configure a port as bidirectional via using the &amp;lt;authentication control-direction both&amp;gt; command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.&lt;BR /&gt;&lt;BR /&gt;Lastly, that command enables 802.1x authentication with the wake-on-LAN (WoL) feature.&lt;BR /&gt;&lt;BR /&gt;Try creating an acl that gets applied to the interface, and is then overridden by the dacl received from ISE via authz profile.  &lt;BR /&gt; ip access-group Base_ACL in &lt;BR /&gt;...&lt;BR /&gt;#sh ip access-lists Base_ACL&lt;BR /&gt;    10 deny ip any any&lt;BR /&gt;Good luck &amp;amp; HTH!</description>
      <pubDate>Wed, 27 May 2020 12:52:53 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4092785#M560711</guid>
      <dc:creator>Mike.Cifelli</dc:creator>
      <dc:date>2020-05-27T12:52:53Z</dc:date>
    </item>
    <item>
      <title>Re: authentication control-direction in - Host stop working</title>
      <link>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4093324#M560727</link>
      <description>&lt;P&gt;Hi Mike&amp;nbsp;&lt;/P&gt;&lt;P&gt;FYSA? i dont understand that one &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So i already have a ACL&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;interface GigabitEthernet0/2&lt;BR /&gt;description 802.1X&lt;BR /&gt;switchport access vlan 32&lt;BR /&gt;switchport mode access&lt;BR /&gt;switchport voice vlan 14&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;ip access-group Pre-ISE in&lt;/FONT&gt;&lt;BR /&gt;authentication host-mode multi-auth&lt;BR /&gt;authentication order dot1x mab&lt;BR /&gt;authentication priority dot1x mab&lt;BR /&gt;authentication port-control auto&lt;BR /&gt;mab&lt;BR /&gt;dot1x pae authenticator&lt;BR /&gt;dot1x timeout tx-period 2&lt;BR /&gt;spanning-tree portfast&lt;BR /&gt;spanning-tree bpduguard enable&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;ip access-list extended Pre-ISE&lt;BR /&gt;permit icmp any any&lt;BR /&gt;permit udp host 0.0.0.0 host 255.255.255.255 eq bootps&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;(this is just a test ACL)&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;And then i have a DACL that is a any any&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;and that seems to kinda work. until in this LAB i connect a PC, and the PC keeps losing the connection&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;until i remove the "&lt;SPAN&gt;authentication control-direction in"&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 28 May 2020 07:02:16 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4093324#M560727</guid>
      <dc:creator>Niklas.D</dc:creator>
      <dc:date>2020-05-28T07:02:16Z</dc:date>
    </item>
    <item>
      <title>Re: authentication control-direction in - Host stop working</title>
      <link>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4093610#M560745</link>
      <description>For Your Situational Awareness &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;BR /&gt;IMO using this:&lt;BR /&gt;ip access-list extended Pre-ISE&lt;BR /&gt;permit icmp any any&lt;BR /&gt;permit udp host 0.0.0.0 host 255.255.255.255 eq bootps&lt;BR /&gt;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 &amp;amp; a rogue computer connection).  Setup ISE default authz to push some sort of non-compliant dacl.  &lt;BR /&gt;&lt;BR /&gt;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. &lt;BR /&gt;-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 &amp;amp; HTH!</description>
      <pubDate>Thu, 28 May 2020 13:27:03 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/authentication-control-direction-in-host-stop-working/m-p/4093610#M560745</guid>
      <dc:creator>Mike.Cifelli</dc:creator>
      <dc:date>2020-05-28T13:27:03Z</dc:date>
    </item>
  </channel>
</rss>

