Sponsored Guest portal doesn't work in ISE 1.3

[Majid Jalinousi]

Hi,

I've setup ISE 1.3 along with vWLC 8.0.120 and I wanted to use Sponsored Guest Portal for guest users when trying to connect to internet.

For this I google searched and found several documents. according them I ocnfigured ISE and you can find ISE configuration in attachement.

When I was trying to connect to internet, the traffic correctly redirected toward ISE and sponsored guest portal appeared for me.

When I was trying to log on with a guest username and password, I could do it but after login, I was moved back to guest sponsored portal. when I saw authentication logs in ISE there was below error:

Overview

Event	5417 Dynamic Authorization failed
Username
Endpoint Id	20:68:9D:82:C9:77
Endpoint Profile
Authorization Result

Authentication Details

Source Timestamp	2015-11-15 16:24:18.875
Received Timestamp	2015-11-15 16:24:18.876
Policy Server	ISE-TDC-NOC
Event	5417 Dynamic Authorization failed
Failure Reason	11215 No response has been received from Dynamic Authorization Client in ISE
Resolution	Check the connectivity between the following: ISE running Log Collector and Dynamic Authorization Client in ISE ; Dynamic Authorization Client in ISE and Network Access Device.
Root cause	No response has been received from Dynamic Authorization Client in ISE.
Username
User Type
Endpoint Id	20:68:9D:82:C9:77
Endpoint Profile
IP Address
Authentication Identity Store
Identity Group
Audit Session Id	fa60630a00000090807a4856
Authentication Method
Authentication Protocol
Service Type
Network Device	Tohid-WLC
Device Type
Location
NAS IP Address	192.168.234.2
NAS Port Id
NAS Port Type
Authorization Profile
Posture Status
Security Group
Response Time	15002

Steps

	11204	Received reauthenticate request
	11220	Prepared the reauthenticate request
	11100	RADIUS-Client about to send request
	11104	RADIUS-Client request timeout expired ( Step latency=15001 ms)
	11215	No response has been received from Dynamic Authorization Client in ISE

How is it possible?

I would appriciate for any help.

BR,

[Majid Jalinousi]

An exciting thing was, when I disconnceted/connected from wireless network, and everything was ok, means authoriztion policy "MCI-INTERNET-ONLY" was passed to vWLC.

How can it be done without  needing to connect/disconnet from wireless network?

Is this a bug from ISE or vWLC?

[Gerad Parent]

Hello

Did you ever nail down what caused your issue?  I am having the exact same issue.  The policy works, I can disconnect and re-connect with access but COA fails.

[Aileron88]

Do you have the CoA capability defined under the radius server on your WLC? It will either be called CoA support or RFC 5176. 

thanks

[Gerad Parent]

Hey Aileron,

Thanks for the response!  Yes, I have COA enabled.  I get my captive portal, hit my proper policy and authenticate.  The COA goes out but never gets a response.  I never see it on the foreign controller.  I did verify I can reach the service port from the ISE server.  Scratching my head pretty hard here.

[Gerad Parent]

A little additional information.  I have an foreign/anchor pair at one of my remote sites where this is failing.  I also have a foreign anchor pair here at headquarters that I proofed this on where things work.  I move the mobility tunnel from my remote site to headquarters and the captive portal works great.  COA is successful and everything works.

[Aileron88]

Hi,

Do you have an edge firewall at the remote site that could be blocking the CoA? It sounds very much like the ISE side is doing what it should, sending the CoA, marking the session as a Guest-Flow but the WLC isn't doing its part.

Thanks

[Greg Gibbs]

If it's working on the headquarters Anchor WLC but not the branch, it sounds like the issue is related to either the branch connectivity or the branch Anchor WLC. In addition to confirming that bidirectional CoA is not being blocked, you might also want to compare the configurations on the two Anchor WLCs.

I believe both the Foreign and Anchor WLCs need to have the same ACLs configured (or at least the same name). You might want to confirm that you have the redirect ACL and any Airespace ACLs you might be sending from ISE configured on both WLCs.

[Jurgens L]

You can get away buy just adding the ACL name on the foreign WLC (no rules required) and add the same ACL name on the anchor WLC with the required rules to redirect traffic.

Something to keep in mind which was helpful to me troubleshooting CoA issue when having a foreign and anchor WLC setup:

Here is the flow in an anchor-foreign setup:

1. The client connects to the SSID on the foreign WLC. The foreign WLC contacts the ISE server for MAB. ISE sends access-accept with the redirect URL and redirect ACL to the foreign.
2. Now the client is anchored to the anchor WLC where it gets an IP address and is put in CENTRAL_WEBAUTH_REQD.
3. When the client tries to access a website, the anchor WLC redirects the client to the ISE portal page. The client is presented with the login page.
4. After successful login, ISE sends a CoA to the foreign WLC.
5. The foreign WLC contacts the anchor WLC to let it know to put the client in the RUN state.
6. All the client traffic is forwarded from foreign to anchor, and goes out of the anchor WLC.

The firewall ports which are required to allow communication between the WLC and ISE are:

• UDP:1645, 1812 (RADIUS Authentication)
• UDP:1646, 1813 (RADIUS Accounting)
• UDP:1700 (RADIUS CoA)
• TCP:8443 Guest Portal or 8905 if you have Posturing. 

Reference:
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html#anc11

[Gerad Parent]

Greg,

Thanks for taking the time to respond.  I do have the ACL on both the foreign and anchor WLC's (all four really).  It does seem to point to the anchor wlc at the remote office, or potentially the firewall at that location, however I do not see any blocked traffic and with a packet capture inline nothing stands out as related traffic that may be dropped but not being logged.  I did go back and verify both ACL's and SSID's are named identically.  If I understand this the COA from ISE gets sent to the foreign WLC, and in my case there is not policy between ISE and the foreign WLC.  I did throw a rule up just in case, but the hit counter doesn't tick up and there was no impact.  When we did our initial build at headquarters we did not require policy for COA, and as mentioned my headquarters foreign controller and my remote office foreign controller both work at this location fine.  I appreciate you time and am not sure I gave you any information to share more thoughts.  If I nail this down I will come back and drop something on this thread.

[Gerad Parent · Accepted solution]

I resolved the issue.  I’ll give you some details so you can put this in your toolbox for the future.  We have an HA pair of 5520’s deployed in this scenario.  The COA was being sent from ISE to our foreign controller, as it should be.  COA does not go from ISE directly to the anchor (sharing because TAC asked to allow this on the firewall, and just to clarify really)  ISE never saw the COA response so it presented the portal again.  Back to the HA piece; we added network routes on the foreign wlc pair so we could reach both the primary and secondary firewalls oob on the service port, just in case we needed to get to the secondary.  The network route statement covered all of our internal networks.  The COA response from the foreign wlc MUST come from the management interface not the service interface.  I changed the network route statement to a much more refined /24 route that has one of our jump servers on it.  If we need to get to the controllers on the service port for some reason we still can from our jump server, and now the COA response comes from the management interface since there is no longer a network route covering our ISE servers.  What an exercise.

One other thing just to share and provide clarity on since I saw some others having this issue with a different resolution.  On your foreign wlc you have to allow COA on your radius server(s) configuration.  This setting does not have to be applied on your anchor controller, at least on current software.  Good luck if your reading this trying to resolve an issue.