cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

1133
Views
5
Helpful
6
Replies
Highlighted
Beginner

ISE CWA on 802.1x Foreign / Anchor set up

Hi
 
I am trying to implement an 802.1x network in foreign/anchor setup, with an ISE web-auth redirect for devices in the “blacklist” endpoint group.
My foreign WLC WLAN is doing the RADIUS auth and accounting requests, and the Anchor WLC WLAN has RADIUS servers disabled.
 
I’ve followed the various guides (prescriptive ISE deployment, ISE CWA etc) but can’t seem to get it to work. 
 
My Testing shows that: 
  • the ISE Authorisation rule for blacklisted devices is matched by the client access request
  • the correct ISE AuthZ profile is applied, with the correct ACL applied to the client session on both WLCs.
  • Foreign WLC shows client as export-anchor.
  • Anchor WLC shows client status as 802.1x_REQ.
 
On the WLAN, i do not have ISE NAC enabled on either end - if so enable this, the client is anchored, but fails to acquire an IP address.
 
Is this setup supported / possible?
If so, what am I doing wrong?
 
Any help is greatly appreciated!
 
Thanks
Don
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Yes - Mobility Anchor is up and configured OK [I have multiple WLANs anchored that work OK] and all WLCs have IP reachability to the ISE nodes as needed - this is working fine.

The Foreign/Anchor works fine when ISE NAC on the WLAN is disabled, but stops functioning as expected when it is enabled as per the post.

 

This approach was to be used as part of a Guest / BYOD solution, but I'm sorry to say that due to the number of caveats around anchored WLANs [such as DNS ACL's etc] we've decided to review our entire solution and are doing away with the Foreign/Anchor WLC option and using plain old WLC without DMZ anchor. 

Our design used the anchor WLC purely for EoIP/overlay transport, but we'll be using a different tunnelling technology to achieve this now... just makes it a little simpler.

 

Thanks for the input anyway, appreciated.

View solution in original post

6 REPLIES 6
Highlighted
Rising star

This is supported since that is basically how Guest access works with a foreign/anchor setup.  You do not need to disable the Radius servers on the anchor side.  Just uncheck Radius accounting on the anchor side.  Every other setting for the SSID should match on the foreign and anchor.  When you say it doesn't work, what is actually not working?  You get an IP address?  Fully associated to the SSID?  Redirect not happening?  No traffic allowed at all?  Or is traffic flowing and that is the issue?

With the redirect, it is probably a FQDN.  Make sure the client on the DMZ/anchor can resolve the FQDN and that the traffic is allowed through any firewalls for the redirect.

Highlighted

Hi Colby, thanks for quick reply. Appreciate the help...

Apologies, just re-read and yes i wasn’t as clear as i should have been! ;-)

 

To be more clear:

 

- With WLAN ISE-NAC nac state disabled at both ends, the client can obtain an IP, but redirection fails when attempting a web page request (just times out)

 

The portal host/port is accessible from the client when in this state (proven via DNS lookups and telnet to the portal PSN host Port number / create a socket / response). So L3/L4 reachability is good.

Also, this same L2/L3 domain works fine for normal Open SSID guest access with CWA.

 

- With ISE-NAC nac state enabled at both ends, and accounting disabled on Anchor the client associates to the SSID, is plumbed to Anchor WLC but fails to get DHCP IP. Even with a static IP, there is no L3 connectivity (arp/gateway not accessible). My ACLs permit DHCP server client on both directions too.

 

Client debug shows the client being plumbed to Anchor, but no IP (0.0.0.0).

 

If I disable ISE-NAC nac state at both ends, L3/L4 reachability is restored

 

Seems a bit odd?

 

I’m glad you have confirmed it is supported, thought i was going mad and wondering if i had missed a caveat with this set up (like DNS ACL etc).

 

Any thoughts?


Thanks!

 

 

 

 

Highlighted

My apologies.  I totally missed your statement about it being 802.1x.  With foreign/anchor, I assumed a guest sort of setup.  I am not sure on the 802.1x piece being supported for that.  I don't see why it wouldn't be supported since redirect is used for posture on 802.1x clients.  But the foreign/anchor piece is the question for me since I haven't tried that.

Can you send a screenshot of your settings in the advanced tab of the SSID?

Highlighted

Apologies for the lack of response on this - Inhad to briefly abandon in favour of another challenge i’m having with ISE /WLC!
I’ll revisit tomorrow with the info...
Highlighted

The Mobility Anchor is up between your 2 WLC, both Data and Control Paths are up and the SSID is configured the same on both ends?

The WLCs can all see the ISE?

On you Anchor SSID, have got the Mobility Anchor to point to "local" and the Foreign to point to the "Anchor IP"?

 

 

Highlighted

Yes - Mobility Anchor is up and configured OK [I have multiple WLANs anchored that work OK] and all WLCs have IP reachability to the ISE nodes as needed - this is working fine.

The Foreign/Anchor works fine when ISE NAC on the WLAN is disabled, but stops functioning as expected when it is enabled as per the post.

 

This approach was to be used as part of a Guest / BYOD solution, but I'm sorry to say that due to the number of caveats around anchored WLANs [such as DNS ACL's etc] we've decided to review our entire solution and are doing away with the Foreign/Anchor WLC option and using plain old WLC without DMZ anchor. 

Our design used the anchor WLC purely for EoIP/overlay transport, but we'll be using a different tunnelling technology to achieve this now... just makes it a little simpler.

 

Thanks for the input anyway, appreciated.

View solution in original post