Hi;
Consider the following scenario:
Here is the configuration applied under the interface:
The client boots up and successful authenticates by 802.1X:
Now, the verification steps:
Why the switch applies the highlited ACE from its point o view.
My current environment:
- ISE 3.2 Patch 7
- Cisco 3560-8PC with IOS 15.0(2)SE11
Thanks
Accepted Solutions
Based on my findings, consider the following statement:
The “access-session acl default passthrough” and its old counterpart “epm access-control open” command are used for hosts without an authorization policy to access ports configured with a dACL. Let’s say that you have several different types of devices connecting to the same interface and some devices are configured to get dACL from ISE while some are not. For instance, you may configure dACL for PC while no dACL is used for IP Phones. As you test different devices on the network you notice that when you connect a PC behind the IP phone, the IP phone loses connectivity to voice gateway until you unplug the PC. You suspect the dACL so you temporarily change the PC dACL to “permit ip any any” to ensure access from any devices on the port, but the problem persists. Then you decide to use “permit ip any any” dACL for the IP phone as well, and now the IP phone does not get disconnected from the voice gateway when the PC is connected behind it. This is also true when a hub is used to authenticate multiple devices behind a single switch interface. If you have devices already connected and authenticated via hub without dACL and a new device connects with a dACL, then all the previously connected devices will lose connectivity to the network as the dACL is only permitted from the endpoint assigned to it and not for the other endpoints on the same interface. There are two main options to address this. One option is to ensure dACL is applied to every permission that will be sharing the same physical port or simply run the following global command, which will dynamically insert “permit ip host x.x.x.x any” in case there is no ACL attached to the session and another device is being connected to the same port with a dACL.
Now consider the following scenario:
As you can see in the above figure, the VM is configured to use 802.1X authentication with a dACL applied to the Interface f0/1 if the authentication is successful. And the physical machine (hosting the VM) is not configured with 802.1X and so the switch uses MAB for it. In this case, after successful MAB authentication, ISE just sends the switch RADIUS Access-Accept message without any authorization policy like dACL. Below is the current fast 0/1 configuration:
The mentioned dACL is configured as follow:
Now, I powered on the both systems and as you can see below, both of them have successfully passed authentication:
Then:
Conclusion: This operation is by design to prevent any situations from occurring for applying a dACL for a session prevents traffic for other session without dACL.
Based on my findings, consider the following statement:
The “access-session acl default passthrough” and its old counterpart “epm access-control open” command are used for hosts without an authorization policy to access ports configured with a dACL. Let’s say that you have several different types of devices connecting to the same interface and some devices are configured to get dACL from ISE while some are not. For instance, you may configure dACL for PC while no dACL is used for IP Phones. As you test different devices on the network you notice that when you connect a PC behind the IP phone, the IP phone loses connectivity to voice gateway until you unplug the PC. You suspect the dACL so you temporarily change the PC dACL to “permit ip any any” to ensure access from any devices on the port, but the problem persists. Then you decide to use “permit ip any any” dACL for the IP phone as well, and now the IP phone does not get disconnected from the voice gateway when the PC is connected behind it. This is also true when a hub is used to authenticate multiple devices behind a single switch interface. If you have devices already connected and authenticated via hub without dACL and a new device connects with a dACL, then all the previously connected devices will lose connectivity to the network as the dACL is only permitted from the endpoint assigned to it and not for the other endpoints on the same interface. There are two main options to address this. One option is to ensure dACL is applied to every permission that will be sharing the same physical port or simply run the following global command, which will dynamically insert “permit ip host x.x.x.x any” in case there is no ACL attached to the session and another device is being connected to the same port with a dACL.
Now consider the following scenario:
As you can see in the above figure, the VM is configured to use 802.1X authentication with a dACL applied to the Interface f0/1 if the authentication is successful. And the physical machine (hosting the VM) is not configured with 802.1X and so the switch uses MAB for it. In this case, after successful MAB authentication, ISE just sends the switch RADIUS Access-Accept message without any authorization policy like dACL. Below is the current fast 0/1 configuration:
The mentioned dACL is configured as follow:
Now, I powered on the both systems and as you can see below, both of them have successfully passed authentication:
Then:
Conclusion: This operation is by design to prevent any situations from occurring for applying a dACL for a session prevents traffic for other session without dACL.
