cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2665
Views
50
Helpful
8
Replies

F5 LTM health monitor probe for ISE guest web portal

Arne Bier
VIP
VIP

Hi

My current F5 LTM deployment uses health probes on a pool of PSN's, but only for UDP/1812 requests.  I would also agree that doing UDP/1813 in addition to 1812 is not required, if 1812 is already been checked.

But my question is regarding the checking of the PSN web portal server health.

Is it good practice to set those up in addition to the radius auth health probes, and in particular, checking whether the guest portal login process is working (i.e. a synthetic login that tests whether a dummy service account user can successfully log in?)

Or would it suffice to perform a simple https GET to the PSN and expect a HTTP 200 OK back as indication of good node health?

thanks in advance

Arne

1 Accepted Solution

Accepted Solutions

paul
Level 10
Level 10

You don't load balance the guest portals typically.  The guest portals are accessed via URL redirects directly to the PSN that authenticated the guest users initial session so you have inherent fate sharing if the RADIUS keepalive fails to a particular PSN.  If you are using portals for other reason, sponsor, my devices, etc. then you could consider load balancing them.

I usually only load balance UDP 67, 1812, 1813 and TCP/49 in my ISE deployments.

View solution in original post

8 Replies 8

paul
Level 10
Level 10

You don't load balance the guest portals typically.  The guest portals are accessed via URL redirects directly to the PSN that authenticated the guest users initial session so you have inherent fate sharing if the RADIUS keepalive fails to a particular PSN.  If you are using portals for other reason, sponsor, my devices, etc. then you could consider load balancing them.

I usually only load balance UDP 67, 1812, 1813 and TCP/49 in my ISE deployments.

Hi Paul

That makes a lot of sense and it also comes up in Craig Hyps documentation.

I asked the F5 guy how he relates the PSN that did the redirect, to the http request to the same PSN, since we normalise the URL in the Access-Accept redirect AVP to something like https://guest.company.com (at which point we lose the unique hostname of the PSN that will process the portal request).  What happens next?

I would like to know how this is done, but as far as I know, they used another virtual server and a bunch of iRules to make the correlation.

We have two data centres and the customer prefers one DC to be the primary active one. 

Just a quick follow up.  Just focusing on the Guest Portal for a second, there is still some sense in having a http monitor probe for Guest Portals because it may be that the radius auth worked, but that the web daemon on that PSN is not working.  This results in a nasty user experience.  Our F5 expert has written some extensive iRules that will work around that, by proactively taking a PSN out of the pool if either

radius auth UDP/1812 fails

or

https probe TCP/8443 fails.

I guess this is a philosophy of "total good health" of the PSN - if any ISE component fails a health check then avoid that PSN until the issue is resolved.

I have also learned that the https virtual server looks at the persistence table of the UDP/1812 virtual server to determine where to proxy the https request - this answers my question about how the F5 ensures that user lands on the correct guest portal PSN.

The F5 LTM is an amazing product and I would encourage anyone to have a play with it (the eval is downloadable for 90 days) - Craig Hyps and F5 have written outstanding documentation on how to set it up.  Writing iRules is not that simple, but it may not always be required.  A bit of tcl never hurt anyone ... ;-)

Yep makes sense to fate share 1812 with 8443 for an availability perspective. I still prefer to map the obscure individual PSN names I outlines in my last response.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

Also the guest1, guest2 concept is what you would migrate to when the customer offloads Internet at the remote sites and wants no internal access at all for the guest traffic. You would use public DNS, bring the guest portal over the Internet back to DMZ interfaces on your PSNs or dedicated guest PSNs in your DMZ. More of my customers are going complete isolated guest networks at the remote sites with no internal network access.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

I am sure there are ways to do the portal mapping on the F5s but I don’t like adding complexity to a process that already has many steps that need to all work correctly to provide guest services. If the customer wants to obscure the PSN names I will simply setup obscured names as SAN fields in the cert. Assuming there are two PSNs in each DC I would do:

guest1.mycompany.com -> DC 1 PSN 1 IP

guest2.mycompany.com -> DC 1 PSN 2 IP

guest3.mycompany.com -> DC 2 PSN 1 IP

guest4.mycompany.com -> DC 2 PSN 2 IP

Then you simply setup for Guest redirect authorization profiles:

DC1PSN1-Redirect redirects to guest1.mycompany.com

DC1PSN2-Redirect redirects to guest2.mycompany.com

DC2PSN1-Redirect redirects to guest3.mycompany.com

DC2PSN2-Redirect redirects to guest4.mycompany.com

Then instead of having one redirect authorization rule at the bottom of your Guest wireless policy set you have 4 and use the Network Access->ISE Host Name condition to specify the ISE PSN as a condition:

If ISE Host Name = DC1PSN1 then result is DC1PSN1-Redirect

If ISE Host Name = DC1PSN2 then result is DC1PSN2-Redirect

If ISE Host Name = DC2PSN1 then result is DC2PSN1-Redirect

If ISE Host Name = DC2PSN2 then result is DC2PSN3-Redirect

I have used this same process for 8 PSNs in an AsiaPac deployment with regional PSNs. It is just rule writing, but now I don’t need to worry about F5 logic getting the portal mapping right.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

Very clever approach.  I will keep that one in my back pocket for next time.

In my case the F5 method of working was chosen because this customer has done it before with a previous (separate) 40 node PSN deployment here in Australia and they had some issues that were found in lab testing that mandated some hectic iRule logic.  But it doesn't have to be like that in other deployments.

Not that it's a major cost issue, but adding loads of SAN's does drive up the cost of the cert (for most public CA's) - in the great scheme of things the cost of the cert is insignificant to the cost of the rest of the gear.

These kinds of design discussions are great and I would like to share more like these.  I am not saying one approach is better than the other - they are all valid approaches and we (as architects) just have to pick the ones we are happy with .

Yep makes total sense. It is nice to know the F5 has the option. I know the F5s pretty well, but only mediocre at iRules. I usually have to cobble things together from the Internet.

Thanks for sharing!

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: