<?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 Hi Neno, in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947238#M38856</link>
    <description>&lt;P&gt;Hi Neno,&lt;/P&gt;
&lt;P&gt;As a matter of fact I did try turning it off and back on again - several times. Great minds think alike. Haha.&lt;/P&gt;
&lt;P&gt;I also observed the same problem with a 3560V2 running IOS 12.2(55)SE10.&lt;/P&gt;
&lt;P&gt;With help from the Partner Security Community, I think I have it figured out - pending testing on-site tomorrow.&lt;/P&gt;
&lt;P&gt;Note the caveats about using switch SVIs for redirection in this reference:&lt;/P&gt;
&lt;P&gt;&lt;A class="jive-link-external-small" href="http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html#anc15" rel="nofollow" target="_blank"&gt;http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html#anc15&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;The customer environment has the management networks wholly separate (think ACLs, VRFs and firewalls in a complex mix) from the user networks.&lt;/P&gt;
&lt;P&gt;From what I've observed, it appears the redirect (coming from the switch's management SVI on an RFC1918 address in an isolated VRF) cannot reach the user networks (all with public IP addresses).&lt;/P&gt;
&lt;P&gt;FYI Auth session looks all good:&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;PRE class="prettyprint" style="padding-left: 30px;"&gt;Switch#sh authentication sessions int gi0/4 det&lt;BR /&gt; Interface: GigabitEthernet0/4&lt;BR /&gt; MAC Address: 00e0.7cc8.9c62&lt;BR /&gt; IPv6 Address: Unknown&lt;BR /&gt; IPv4 Address: &amp;lt;redacted&amp;gt;&lt;BR /&gt; User-Name: 00-E0-7C-C8-9C-62&lt;BR /&gt; Status: Authorized&lt;BR /&gt; Domain: DATA&lt;BR /&gt; Oper host mode: multi-domain&lt;BR /&gt; Oper control dir: both&lt;BR /&gt; Session timeout: N/A&lt;BR /&gt; Restart timeout: N/A&lt;BR /&gt; Session Uptime: 53s&lt;BR /&gt; Common Session ID: 0A601608000000120032B3E5&lt;BR /&gt; Acct Session ID: 0x00000008&lt;BR /&gt; Handle: 0x05000006&lt;BR /&gt; Current Policy: POLICY_Gi0/4&lt;BR /&gt;&lt;BR /&gt;Local Policies:&lt;BR /&gt; Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)&lt;BR /&gt; Security Policy: Should Secure&lt;BR /&gt; Security Status: Link Unsecure&lt;BR /&gt;&lt;BR /&gt;Server Policies:&lt;BR /&gt; &lt;BR /&gt; URL Redirect: &lt;A href="https://mydevices.net.&amp;lt;redacted&amp;gt;" target="_blank"&gt;https://mydevices.net.&amp;lt;redacted&amp;gt;&lt;/A&gt;&lt;BR /&gt; URL Redirect ACL: CWA_R&lt;BR /&gt; ACS ACL: xACSACLx-IP-dACL_WebAuth-57a3a48b&lt;BR /&gt;&lt;BR /&gt;Method status list: &lt;BR /&gt; Method State&lt;BR /&gt;&lt;BR /&gt; mab    Authc Success&lt;BR /&gt;&lt;BR /&gt;Switch#&lt;/PRE&gt;</description>
    <pubDate>Sun, 07 Aug 2016 17:39:53 GMT</pubDate>
    <dc:creator>Marvin Rhoads</dc:creator>
    <dc:date>2016-08-07T17:39:53Z</dc:date>
    <item>
      <title>Challenged Getting redirect-url to Redirect (Wired ISE)</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947236#M38846</link>
      <description>&lt;P&gt;I'm having an odd problem with an ISE deployment.&lt;/P&gt;
&lt;P&gt;It's a greenfield ISE 2.1 distributed deployment with use case of wired MAB. The policy set is working, with the penultimate step (prior to deny) being to redirect to My Devices portal to register. We are using a custom pair of A-V attributes for the redirect-url and redirect-acl.&lt;/P&gt;
&lt;P&gt;My NAD is a Catalyst 3560CG running IOS 15.2(2)E5, the recommended compatibility release.&lt;/P&gt;
&lt;P&gt;CoA is happening as expected, with redirect acl and redirect url appearing in the authentication session details for unknown endpoints.&lt;/P&gt;
&lt;P&gt;The problem is redirection is not actually happening. The connect action in the client browser just spins until timeout. We see the same symptoms on multiple browsers across multiple clients (Windows and OS X).&lt;/P&gt;
&lt;P&gt;The client can resolve addresses (nslookup works fine). The client can also browse directly to the My Devices portal while subject to this AuthZ profile.&amp;nbsp;There are no web proxies in the environment.&lt;/P&gt;
&lt;P&gt;I have an open TAC case and the engineer said the config looks OK so far - he is labbing it up to see if he can reproduce before escalating.&lt;/P&gt;
&lt;P&gt;Has anyone seen anything similar?&lt;/P&gt;</description>
      <pubDate>Mon, 11 Mar 2019 06:58:31 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947236#M38846</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2019-03-11T06:58:31Z</dc:date>
    </item>
    <item>
      <title>"have you tried turning it</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947237#M38852</link>
      <description>&lt;P&gt;"have you tried turning it off and on again?" &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Hi Marvin, I am interested to see what the aaa and radius debugs look like as well as "show authentication session.."&lt;/P&gt;
&lt;P&gt;Also, what about wireless and/or another switch model and/or another switch with different version of code?&lt;/P&gt;</description>
      <pubDate>Sat, 06 Aug 2016 22:11:03 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947237#M38852</guid>
      <dc:creator>nspasov</dc:creator>
      <dc:date>2016-08-06T22:11:03Z</dc:date>
    </item>
    <item>
      <title>Hi Neno,</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947238#M38856</link>
      <description>&lt;P&gt;Hi Neno,&lt;/P&gt;
&lt;P&gt;As a matter of fact I did try turning it off and back on again - several times. Great minds think alike. Haha.&lt;/P&gt;
&lt;P&gt;I also observed the same problem with a 3560V2 running IOS 12.2(55)SE10.&lt;/P&gt;
&lt;P&gt;With help from the Partner Security Community, I think I have it figured out - pending testing on-site tomorrow.&lt;/P&gt;
&lt;P&gt;Note the caveats about using switch SVIs for redirection in this reference:&lt;/P&gt;
&lt;P&gt;&lt;A class="jive-link-external-small" href="http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html#anc15" rel="nofollow" target="_blank"&gt;http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html#anc15&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;The customer environment has the management networks wholly separate (think ACLs, VRFs and firewalls in a complex mix) from the user networks.&lt;/P&gt;
&lt;P&gt;From what I've observed, it appears the redirect (coming from the switch's management SVI on an RFC1918 address in an isolated VRF) cannot reach the user networks (all with public IP addresses).&lt;/P&gt;
&lt;P&gt;FYI Auth session looks all good:&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;PRE class="prettyprint" style="padding-left: 30px;"&gt;Switch#sh authentication sessions int gi0/4 det&lt;BR /&gt; Interface: GigabitEthernet0/4&lt;BR /&gt; MAC Address: 00e0.7cc8.9c62&lt;BR /&gt; IPv6 Address: Unknown&lt;BR /&gt; IPv4 Address: &amp;lt;redacted&amp;gt;&lt;BR /&gt; User-Name: 00-E0-7C-C8-9C-62&lt;BR /&gt; Status: Authorized&lt;BR /&gt; Domain: DATA&lt;BR /&gt; Oper host mode: multi-domain&lt;BR /&gt; Oper control dir: both&lt;BR /&gt; Session timeout: N/A&lt;BR /&gt; Restart timeout: N/A&lt;BR /&gt; Session Uptime: 53s&lt;BR /&gt; Common Session ID: 0A601608000000120032B3E5&lt;BR /&gt; Acct Session ID: 0x00000008&lt;BR /&gt; Handle: 0x05000006&lt;BR /&gt; Current Policy: POLICY_Gi0/4&lt;BR /&gt;&lt;BR /&gt;Local Policies:&lt;BR /&gt; Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)&lt;BR /&gt; Security Policy: Should Secure&lt;BR /&gt; Security Status: Link Unsecure&lt;BR /&gt;&lt;BR /&gt;Server Policies:&lt;BR /&gt; &lt;BR /&gt; URL Redirect: &lt;A href="https://mydevices.net.&amp;lt;redacted&amp;gt;" target="_blank"&gt;https://mydevices.net.&amp;lt;redacted&amp;gt;&lt;/A&gt;&lt;BR /&gt; URL Redirect ACL: CWA_R&lt;BR /&gt; ACS ACL: xACSACLx-IP-dACL_WebAuth-57a3a48b&lt;BR /&gt;&lt;BR /&gt;Method status list: &lt;BR /&gt; Method State&lt;BR /&gt;&lt;BR /&gt; mab    Authc Success&lt;BR /&gt;&lt;BR /&gt;Switch#&lt;/PRE&gt;</description>
      <pubDate>Sun, 07 Aug 2016 17:39:53 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947238#M38856</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2016-08-07T17:39:53Z</dc:date>
    </item>
    <item>
      <title>Hi Can you pls share the</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947239#M38859</link>
      <description>&lt;P&gt;Hi Can you pls share the Switch port config?&lt;/P&gt;
&lt;P&gt;Do you have redirect ACL applied to port.If so remove it and check.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 12:29:53 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947239#M38859</guid>
      <dc:creator>Ridma Ransara Jayaweera</dc:creator>
      <dc:date>2016-08-08T12:29:53Z</dc:date>
    </item>
    <item>
      <title>Switch configuration was fine</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947240#M38860</link>
      <description>&lt;P&gt;Switch configuration was fine. It was as I noted earlier - the switch SVI subnet had an upstream ACL preventing access to the user subnet thus the redirection was never arriving.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 13:11:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947240#M38860</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2016-08-08T13:11:22Z</dc:date>
    </item>
    <item>
      <title>Good deal Marvin. Just to</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947241#M38864</link>
      <description>&lt;P&gt;Good deal Marvin. Just to confirm: You were able to resolve the issue after testing with the suggestions from Partner Support Community?&lt;/P&gt;
&lt;P&gt;Btw, I had one deployment where the customer had completely seperated network/out-of-band for management that resided on different VRF. This became an issue as that was the only SVI for the access layer&amp;nbsp;switches. I could not get it to work even&amp;nbsp;as the VRF could not be referenced in all of the RADIUS based configs.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards,&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Neno&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 15:54:23 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947241#M38864</guid>
      <dc:creator>nspasov</dc:creator>
      <dc:date>2016-08-08T15:54:23Z</dc:date>
    </item>
    <item>
      <title>Yes Neno - it started working</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947242#M38870</link>
      <description>&lt;P&gt;Yes Neno - it started working once I changed the configuration to give the switch an SVI in the user VLAN. That wasn't very operationally elegant though and would require assigning several hundred new SVIs across the campus.&lt;/P&gt;
&lt;P&gt;We then discussed and got approval to modify the ACL that's on the gateway interface for the management subnet (and disable RPF checks).&lt;/P&gt;
&lt;P&gt;We did that and the redirection is working in that use case as well.&lt;/P&gt;
&lt;P&gt;Bottom line is that some IP address on the switch needs to be able to talk to whatever user addresses will be getting redirected.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 19:28:59 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947242#M38870</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2016-08-08T19:28:59Z</dc:date>
    </item>
    <item>
      <title>Fantastic! Thank you for</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947243#M38880</link>
      <description>&lt;P&gt;Fantastic! Thank you for sharing the solution with everyone here!&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 22:39:02 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947243#M38880</guid>
      <dc:creator>nspasov</dc:creator>
      <dc:date>2016-08-08T22:39:02Z</dc:date>
    </item>
    <item>
      <title>You're welcome. Thanks for</title>
      <link>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947244#M38885</link>
      <description>&lt;P&gt;You're welcome. Thanks for the endorsement.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Aug 2016 23:47:04 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/challenged-getting-redirect-url-to-redirect-wired-ise/m-p/2947244#M38885</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2016-08-08T23:47:04Z</dc:date>
    </item>
  </channel>
</rss>

