cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
 
ISE 2.3 Patch 7 has been posted. This will be the last patch for the ISE 2.3 release!
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.

1560
Views
2
Helpful
21
Replies
Beginner

Guest portal redundancy

Hi,

what is the best way to make sure if ISE01 fails guest traffic for the portal will go to ISE02 automatically and without a load balancer?

Thanks,

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Guest portal redundancy

Since the NAD can only fail over radius traffic I would think the only way you can have correct redundancy is to use a load balancer

If radius fails on PSN1 then failover to PSN2

I wouldn't want it any other way otherwise you're asking for trouble

21 REPLIES 21
Cisco Employee

Re: Guest portal redundancy

Since the NAD can only fail over radius traffic I would think the only way you can have correct redundancy is to use a load balancer

If radius fails on PSN1 then failover to PSN2

I wouldn't want it any other way otherwise you're asking for trouble

Beginner

Re: Guest portal redundancy

Thanks Jason,

Can I have my authorization results web redirect returns fqdn on the responding ise node? I know we can have the ip address of the responding node or (we can type) the static fully qualified domain name. I was hoping I can use something like how the ip is used in the cisco-av-pair as a variable (cisco-av-pair = url-redirect=https://ip:port/portal/gateway?sessionId=SessionIdValue&)

maybe replace ip:port/portal with fqdn:port/portal

Cisco Employee

Re: Guest portal redundancy

I don't think so and how would you expect it to work?

Can you explain more? Can you step by step give your logic?

If your radius goes to PSN1 then you will want your redirect to go the same PSN this is how it works

Check this out

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/117620-configure-ISE-00.html

Beginner

Re: Guest portal redundancy

2 ISE nodes L3 separated. 2 WLC's.

How do I make sure that guests on WLC1 access a page on ise1 can access the page when ise1 fails.

I have a page that shows the users that they should not be connecting a device that is machine authenticated to this specific SSID "This a company device and should not be connected to this SSID, Please use the secure SSID to connect"

I need that page to be accessible from all controllers regardless of which ISE is down. each ise has a unique FQDN and a unique SSL cert for that FQDN.

Hopefully that makes it clear. Let me know.

Cisco Employee

Re: Guest portal redundancy

I am going to ask we take this into a WebEx with Eddie

Sent from my iPhone

Beginner

Re: Guest portal redundancy

Eddie is OOO until Friday and I'm working on this now and tomorrow

Cisco Employee

Re: Guest portal redundancy

Contact me direct then

Jakunst@cisco.com<mailto:Jakunst@cisco.com> setup webex

Sent from my iPhone

Contributor

Re: Guest portal redundancy

I believe what you are asking for is default behavior. You configure a primary and secondary radius server in the WLC and whichever radius server (PSN) is active and processing the current session will provide the redirect to the WLC and therefore authenticate the guest. Otherwise you can create an authorization profile per PSN with a static redirect hostname per profile. Then create two authz rules, one for each PSN and match on either the radius server or ISE Host Name to then return the corresponding authz profile.

Beginner

Re: Guest portal redundancy

I tried using the RADIUS server in my authz but I don't think the RADIUS request is carrying the ise server name in the request and it did not work.

Enthusiast

Re: Guest portal redundancy

We do this all the time.  To clarify for anyone else watching this thread, default behavior vs. what looks like your desired behavior:

If you leave it as default redirect functionality, ISE will return the internal FQDN of the PSN and you do that with one portal.  You then manage different trusted certs on each box with your certificate group tag, hopefully with certs that are publicly signed so that your guests trust them.  But, based on guest network routing, DNS (if your guests have public DNS but internal FQDN to return), or Certificate contents that vary from the internal names - all of that is often not acceptable for guest networks.


How to resolve:


Use NetworkAccess:ISE Host Name as the condition to figure out who handled the RADIUS request, and therefore you know where to send if you need to forward somewhere other than the internal FQDN of the ISE PSN that responded (i.e. if you have a custom URL/Certificate that differs, want to send to an IP for some use case, etc).

Here's an example of two different authorization rules that have two different results, redirecting to FQDNs:

AuthZ Policy:

         <rule name="Redirect Guest - Toronto" status="Enabled">

            <Conditions relationship="AND">

              <Condition type="ADHOC">Network Access:ISE Host Name CONTAINS tor-ise-01</Condition>

            </Conditions>

            <identityGroups>

              <identityGroup name="Any"/>

            </identityGroups>

            <Results relationship="AND">

              <Result name="Redirect-GuestWifi-CAN-Toronto" type="Standard">

                <nadProfileName>Cisco</nadProfileName>

              </Result>

            </Results>

          </rule>

   <rule name="Redirect Guest - London" status="Enabled">

            <Conditions relationship="AND">

              <Condition type="ADHOC">Network Access:ISE Host Name CONTAINS ldn-ise-01</Condition>

            </Conditions>

            <identityGroups>

              <identityGroup name="Any"/>

            </identityGroups>

            <Results relationship="AND">

              <Result name="Redirect-GuestWifi-EU-London" type="Standard">

                <nadProfileName>Cisco</nadProfileName>

              </Result>

            </Results>

          </rule>

AuthZ Results:

      <Profile description="Redirect Guest to Portal Page - Toronto" nadProfileName="Cisco" name="Redirect-GuestWifi-CAN-Toronto">

        <option name="Attributes Details">cisco-av-pair = url-redirect-acl=ACL-REDIRECT,

cisco-av-pair = url-redirect=https://guest-toronto.customer.com:port/portal/gateway?sessionId=SessionIdValue&portal=9ba17502-84cd-11e5-878f-0050568f7652&daysToExpiry=value&action=cwa</option>

        <option name="Access Type" value="ACCESS_ACCEPT"/>

        <option name="Service Template" value="false"/>

      </Profile>

      <Profile description="Redirect Guest to Portal Page - London" nadProfileName="Cisco" name="Redirect-GuestWifi-EU-London">

        <option name="Attributes Details">cisco-av-pair = url-redirect-acl=ACL-REDIRECT,

cisco-av-pair = url-redirect=https://guest-london.customer.com:port/portal/gateway?sessionId=SessionIdValue&amp;portal=9ba17502-84cd-11e5-878f-0050568f7652&amp;daysToExpiry=value&amp;action=cwa</option>

        <option name="Access Type" value="ACCESS_ACCEPT"/>

        <option name="Service Template" value="false"/>

      </Profile>

Feel free to reach out if you have any questions.

Beginner

Re: Guest portal redundancy

Thanks for you input. I thought that this was the default behavior with web redirect. My main issue is that I'm unable to have ( ISE will return the internal FQDN of the PSN) rather I get redirected to the portal with IP not FQDN.

cisco-av-pair = url-redirect=https://ip:port/portal/gateway?sessionId=SessionIdValue&portal=e6e7ae71-7de7-11e7-bdcb-70db9827dcfc&action=

I can hard code ISE FQDN and use your recommendation or find a way (default way as per your statement) for ISE to return the FQDN on the PSN.

Enthusiast

Re: Guest portal redundancy

Ignore that your default AuthZ profile says IP:PORT - I know, could be somewhat confusing.

Go ahead and test it, If you do not set the options requiring IP or FQDN in the Authorization result it should dynamically replace the URL with FQDN (internal) when redirected (in production).  If you test via the Preview Page, it will only do IP, but in a real session redirect it will use FQDN.  Test and let me know, if you have a problem with returning FQDN, please let me know the version of ISE you are working with.

My solution above is for a case where for example, you have Gig1 in a DMZ with different routing and different name that can be resolved externally if your external clients are using external DNS. (If your server is ISE01.CUSTOMER.LOCAL and your clients in your guest network use Google DNS, you'll never get there). This is just one example, there are several other use cases that you do this for, but may not be for your use case especially if your internal FQDN of your responding PSN is resolvable from your guest IP space from all locations (i.e. if you use internal DNS). 

Good luck,

Jared

Advocate

Re: Guest portal redundancy

I think there are multiple topics at play here.

To clarify some points:

  1. Web authentication to ISE via CWA assumes that the PSN that processed RADIUS is also one that serves the web portal for CWA.
  2. By default, #1 occurs automatically and does not require special config as IP:PORT variables are automatically substituted with proper values of PSN IP or FQDN and portal port.  If portal on non-GE0 interface, then be sure to set 'ip host" command at CLI to properly associate an FQDN to the interface.  DNS should then resolve FQDN to IP.
  3. If need to redirect to a specific FQDN or IP, then Jared's suggestion is valid whereby you match request to RADIUS PSN and return authorization for same PSN using static IP/name, or else to a LB which has intelligence to persist web traffic to same RADIUS server.
  4. It sounds like you wanted to return a static portal page that informs user "This a company device and should not be connected to this SSID, Please use the secure SSID to connect".  If so, this is not really a web login page and could potentially be returned by any PSN.  One option is to return FQDN of external web server that displays this message and ensure redundancy for that server just like any other critical web service in customer deployment.  Another is to use load balancer, but ask was not to use LB.  Another option is to use intelligent DNS that is able to return available server.  And yet another is to use Anycast, where routing determines reachable PSN, but IP reachability and portal accessibility are two different things.  If simply trying to handle case where PSN is down, then IP reachability may suffice.

Craig

Highlighted
Beginner

Re: Guest portal redundancy

Thanks Craig,

I would like to get it to work with option #2 you provided. The problem is that I'm getting this bug "

Cisco Bug: CSCvb63696 - ip host error on partial matched FQDN"


Do you know of a work around to this?! it would be optimal if I can get this working with the ip host command.