Guest portal interfaces question

[Darkmatter]

It's the first time i'm setting up guest portal on ISE, so please bear with me.

Physically, the GUEST network will be isolated from the LAN and residing in the DMZ, for which i'm planning to use a dedicated interface on the WLC that will host the new guest SSID and GUEST network, which in turn will go to the firewall via it's dedicated VLAN.

The goal is to have guest portal on a separate interface on ISE (2 VM appliances) since i read this is the recommended best practice.

Now the thing i'm not really getting is the Guest portal 'allowed interfaces' settings.

Multiple docs i read state that in order to fully isolate guest traffic, one should use another interface to host your GUEST portal and configure and ip on it (on your ISE boxes via CLI).

Let's say the GUEST network is 192.168.100.0/24.

Does this mean the interface needs to have an ip in the range of the GUEST network? So something like 192.168.100.254?

Or can it be an address of another network in your LAN?

Let's assume a guest connects to the GUEST SSID, RADIUS traffic will then come into this newly configured interface instead of the LAN interface and once the GUEST is matching your policy and allowed access, HTTP/HTTPS traffic will flow in/out of the GUEST network, from AP's on the WLC, to the internet and your GUESTS, back and forth?

Does it work the way like i'm describing here or the flow is completely different?

[ahollifield]

It can be any IP you want that makes sense for your network design.  This could be an IP directly in your guest VLAN or through another DMZ controlled by firewall rules.  

RADIUS traffic will still terminate on the normal LAN from your wireless controller.  The guest redirect HTTPS traffic will be the traffic to hit the alternate interface.  

[Darkmatter]

Thanks for your response, but not fully clear yet.

Can you maybe trow in a few examples?

[ahollifield · Accepted solution]

Sure so lets assuming the following:

ISE PSN gig 0: 10.10.10.10

ISE PSN gig5: 192.168.10.10

Client connects to guest wireless---->WLC--->RADIUS MAB request to ISE PSN 10.10.10.10

ISE responds with captive portal URL and ACL---->URL points client to 192.168.10.10---->Client connects directly to 192.168.10.10

Client signs into splash page ----->ISE sends CoA via gig0 to WLC----> WLC reauthenticates with a new MAB request to 10.10.10.10----> Client joins guest network.

[Arne Bier · Accepted solution]

As @ahollifield  pointed out, the "control plane" (so to speak) is the RADIUS traffic between the WLC and ISE - and that goes to the PSN's gig0 IP address.

As for the client (guests) on the open SSID, they get an IP address via DHCP when they land on the VLAN that you made available on the WLC for the Guest SSID (192.168.100.0/24) - but this doesn't mean the ISE Guest Portal Interface has to reside on this VLAN too. It could - but it doesn't have to. You can put the ISE Guest PSN interface in a DMZ (e.g. ISE Gig 5 = 172.16.1.100), and then have a FW rule that allows TCP/8993 from the 192.168.100.0/24 -> 172.16.1.100 

I just wanted to point that out - you can "shield" your ISE PSN from guest users by placing the interface in a DMZ and putting a FW rule in place. Having said that, the ACL on the WLC should do the same - allow pre-auth clients to only do DHCP, DNS and TCP/8993 to PSN. And then after auth, allow DHCP, DNS, TCP/8993 to ISE, and block RFC1918, and allow everything else (in that order).

This separation gives a nice warm fuzzy feeling of security - and it's also handy in the case of a suspected DDOS - you can simple shut the Gig5 down and not risk degrading the rest of the PSN's operations (RADIUS/TACACS etc.).

It also comes at a small cost of complexity - when you look at the ACLs on the WLC, you need to remember which IP addresses are for Gig0 and which are for Gig5. I find this confusing when looking at a WLC config - I see the IP address of Gig0 listed as RADIUS server, but then the ACLs for the guest WLAN contain those strange IPs (for Gig5) - it can be confusing if you don't have the documentation or context. 

[Darkmatter]

Many thanks to both of you @Arne Bier and @ahollifield!

This info is golden to me and probably future community users as well. Nowhere i could find this topic well layed out and explained like you guys did.