ISE Guest portal with reverse proxy

[Mohaninj]

Has anyone implemented ISE guest portal behind reverse proxy or Load balancer. My customer has a public cert on the load balancer(F5) ,which they want to leverage for guest authentication, instead of having a separate public cert on ISE. Currently LB is not inline for authentication flow (Guest client – WLC – ISE).  I think for reverse proxy setup to work (refer flow2), when client receives the redirect portal (guest.mycompany.com) from ISE, DNS should resolve the IP address of VIP on LB and LB should forward the request to ISE without changing the clients source IP and portal URL (to preserve session ID) details. Is it a workable solution or LB should be in line for initial authentication as well. Any inputs.

Setup: Guest client - WLC - ISE

[Arne Bier]

It's a common and tested solution to have F5 LB in line between client and the PSN's.  BRKSEC-3699 goes into a lot of details and there is also an ISE/F5 document from Craig Hyps - https://community.cisco.com/t5/security-documents/how-to-cisco-amp-f5-deployment-guide-ise-load-balancing-using/ta-p/3631159

You are right.  The PSN nodes should have static FQDN setup for the Guest portal (e.g. guest.mycompany.com) and the client will resolve that FQDN to be the F5 VIP.

The biggest challenge with these setups is that there must be persistence logic enabled on the F5 (usually done with iRules) to ensure that the F5 always sends traffic to the same PSN after the initial Radius MAB auth.  If this is not done then nothing will work.

The SSL bridging (I think this is what F5 calls it) is a good thing and it could offload the PSN's from doing TLS.  But to be honest I don't know what's the real point because ISE doesn't give you an option to create http based portals. So the F5 will build a TLS connection to ISE anyway (as far as I can see).

I always put the cert on the PSN's as well as on the F5.

[Mohaninj]

Thanks Arne for your response.

However, In the current setup LB is not in line between NAD and PSN. The requirement is to only redirect ISE portal access via LB. For initial authentication, client will directly reach ISE on MAB auth (client-WLC-ISE) and when ISE responds with guest portal, it should get redirected through LB (Guest portal access -VIP of LB - ISE). by assigning a static FQDN for each PSN (e.g. guest1.mycompany.com for PSN1 and guest2.mycompany.com for PSN2), I think we can address the persistency issue.  Hope this approach should work.

[Arne Bier]

Why can the WLC not send its MAB traffic to the LB?  If the MAB requests do not reach the F5 then the F5 has no context of the call flow and won't be able to build persistence.  Case in point:  Let's say you have 10 PSN's all acting as portals.  WLC sends a MAB request to PSN 5.  How do you expect the F5 to know that the client's TCP session then needs to end up on PSN 5?  It cannot know this without being part of the conversation.

It's inherent in ISE's design to only create a customer portal session (URL contains a hash that is unique to that user's session) - if the TCP connection never gets made to that URL then PSN will kill the session (timeout). Perhaps with other vendors you can steer a client to any of the available 10 web portals - but not with ISE.  It's a very strong security design - but it make designing for it very tricky.

[Mohaninj]

Hi Arne,

Sorry for the delayed response, I was on travel last week.

I agree with your point, ideally LB should be inline to maintain the session persistency. In this case, LB is not inline between NAD and PSN. Only guest web page (redirect URL) should be redirected through LB and persistency in this case can be achieved with policy logic on ISE  & by creating a DNS entry for each PSN guest portal with individual LB VIP. I've tested this scenario in the lab and it is working as expected. here is the flow.

Step1: client associates to open SSID with MAC filtering

Step2:  PSN responds with redirect URL (Guest portal - e.g. guest1.mycompany.com based on authz policy logic)

Step3: Client redirected to guest portal, which is a load balancers virtual IP (VIP) (host entry created in DNS for guest1 to resolve LB VIP)

Step4: SNAT client's IP with LB interface IP (to maintain TCP session) & forwards the request to PSN on 8443 port

Step5: PSN authenticates the user and responds to LB, LB forwards to client

Step6: PSN sends a COA to NAD with session ID details and client session gets a new ACL

[paul]

That works just fine.  As long as you have different FQDNs for the guest portal for each ISE PSN it will work just fine.  I would personally take the same cert on the F5 that allows guest1, guest2, etc to work and put them on the PSNs instead of adding another component to the process, but what you laid out should work.