11-07-2024 06:26 AM - edited 11-07-2024 06:27 AM
hello
I have a question regarding assigning a port to the guest VLAN, which should allow internet access if both dot1x and MAB fail. I created a service template for the guest VLAN and made modifications to the policy map you suggested, but I’m not entirely sure I implemented it correctly.
After making these changes, the port is successfully assigned to the guest VLAN if both dot1x and MAB fail, but I am not sure I did it in right way, Could you please help me implement this scenario correctly?
also, there is issue, the users experience, When a user’s device is assigned to the guest vlan and using Cisco anyconnect, it constantly connects and disconnects. However, there is no issue when they connect to the network through wifi. I have already configured an MTU of 1300 as a group policy on our Cisco ASA firewall for Cisco anyconnect. Since the default MTU on switch interfaces is 1500, should they be changed as well?
Here is my code:
11-07-2024 03:41 PM
As far as I understand IBNS 2.0, when the DOT1X_FAILED fires, and MAB authentication is performed, then the response from ISE is important - I think you have ONE chance to get it right. The logic in the MAB Authorization would look like this:
If Endpoint found in Guest Endpoint group then Authorized Accordingly (Access-Accept etc.)
If Endpoint found in logical Profiles, Profiles, Endpoint Groups then Authorize According as required
If Endpoint not matched yet, then send Access-Accept with URL redirection AVPair stuff (guest portal redirection)
Bottom line is, do not send an Access-Reject to the switch. Because that tells the switch to restart the whole NAC process from the top (i.e. starting with 802.1X etc.)
I believe that the class-map below is useful if ISE replied with an Access-Reject, but I would then assume that the switch doesn't perform MAB (which is not what you want) and then starts the NAC cycle again.
class-map type control subscriber match-all MAB_FAILED
match method mab
match result-type method mab authoritative
11-08-2024 10:54 AM - edited 11-08-2024 11:02 AM
Hi Arne,
Thanks for your response!
I’d like to assign non-MAC addresses directly to the guest vlan without URL redirection. Given the options, which approach would you recommend as the best fit for my scenario?
Also, I’m wondering if the Cisco AnyConnect issue might be related to the NAC cycle restarting.
Appreciate your guidance on this!
11-08-2024 11:17 AM
I had considered setting the last rule in the MAB Policy Set to assign the guest vlan. However, my main goal is to differentiate between authorized and unauthorized devices; specifically, those that fail and succeed in authentication.
Since I couldn’t find an option in ISE to mark a device as “failed authentication” and then assign it to the guest vlan, I opted to assign devices directly to the guest vlan from the switch. Is there an option in ISE that would allow a device to be flagged as “failed authentication” and still assigned to the guest vlan?
11-08-2024 01:00 PM
Ok I think I understand now. Your definition of "failed authentication" and the switch's concept of "failed authentication" are different. To a switch, an endpoint failed authentication, if the RADIUS server returns the Access-Reject code. That tells the switch that this session should be Unauthorized, and the endpoint has no access - and also, it tells IBNS to restart the NAC cycle.
However in your definition of failed authentication, you're thinking of giving that endpoint some treatment (e.g. dACL, dynamic VLAN, Session-Timeout, etc.) in conjunction with an Access-Accept - that tells the switch that the endpoint is Authorized, and then the NAC cycle stops. That's all correct, and you can constrain those "catch-all" endpoints to a "jail/guest VLAN" (call it whatever you want) that goes nowhere. E.g. ISE could return the attributes VLAN 999 which is not trunked/routed anywhere and a dACL from ISE that says "deny any any".
When you said guest VLAN, I thought you literally wanted to offer a guest portal to those devices that had a screen. In that case you need URL redirection of course.
One final thought on MAB and dynamic VLAN assignment, If you want to set a VLAN via ISE, that is different to the VLAN already configured on the switch interface (e.g. access VLAN 100), then 99% of the time your endpoints won't get a DHCP address on the newly switched VLAN, because it takes some time between the first DHCP Discovery message from the client (after Ethernet link up), while the client is in VLAN 100 (as defined on the interface), it then might get the offer, and reply and accept - and viola! It has an IP address on VLAN 100. And then a few ms later the VLAN is switched to 999 by ISE. Client won't know about this, and won't do another DHCP cycle. Hence, don't expect guest portals to work if you perform dynamic VLAN assignment. I don't know how others solve this problem - perhaps with a port-bounce instead of Re-Auth, or by making the interface access VLAN config always be the guest VLAN, and then not send a dynamic VLAN from ISE, but just the URL redirection stuff.
Dynamic VLAN assignment MUST happen BEFORE the endpoint has L3 network connectivity - in other words, it works well with 802,1X, because that happens at L2, and once 802.1X as concluded, the VLAN is switched and then the client starts their DHCP cycle.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide