Cisco ISE Guest Portal (second Interface) via WWW Internet

[joshhunter]

Hello, Has anyone deployed a Guest Portal 'exposed' via the Internet to cater for SD-WAN Local Breakout Guests?

A second Interface (or another) is assigned to provide the Guest Captive Web Portal. The primary interface is reserved for the Management of the Cisco ISE Appliance. 

Typically, the Guest would reach this second interface serving the web portal via the DMZ via a Guest Anchor Solution or similar. In a SD-WAN solution, the Guests may be in a separate VRF with Guest Internet Only. Therefore, how does the guest reach the Captive Portal without VRF Route Leaking or similar?

In our solution, the Corporate and Guest ISE are the same box. If we only allowed 8443 in is this enough to protect the ISE as the second interface would be exposed to www. 

Thoughts please. 

[Arne Bier]

Hi @joshhunter 

From a design perspective, the IP subnet that the ISE Guest Portals are on, are independent from the IP subnet that the guest users are on. They can be the same, but don't have to be. How the guests reach the ISE Portal is based on L3 routing design. 

If you don't have the luxury of deploying a separate ISE instance in your DMZ just for guest wifi, then having the ISE Guest Portal on a separate ISE interface certainly makes sense. IIRC the admin interface is only reachable via Gig0. And the WLC ACLs should really lock down access to TCP/8443 in the pre-auth case, and in the post-auth case, the ACL should deny all IP subnets apart from internet.

I think most folks would say that putting your guest and corp on same ISE is unwise. Probably right because bad actors have a talent for sometimes doing the unthinkable. Recent CVEs demonstrate that. We think that even though we restricted access to TCP/8443 that they don't find some insane way of compromising the endpoint. If your corp sits on that same box, then you have a shared fate. 

Might not hurt to run a penetration test against the public facing side to see if it can get anywhere. 

[joshhunter]

Hi @Arne Bier  Thank you for your reply.

We would certainly be using the second interface for the Guest Portal. Unfortunately, it is the same ISE Appliance being used for both Guest and Corporate. 

It is defining the risk associated with having this second interface behind a firewall only allowing Port 8443 inbound but essentially NAT'd and reachable from the internet. 

[Arne Bier]

Why don't you create a local VLAN for the Gig1 interface and then have users connect to it. Only the connected users should be initiating connections towards the Internet. I would not make ISE reachable via the internet. The ISE Guest Portal Certificate obviously needs an FQDN from a public domain, but that does not mean you must tie that to a public IP. Perhaps I misunderstood your setup. A diagram would be clearer. 

Bottom line. Guests should land on a non-public IP subnet and so should ISE. These can be two different VLANs but doesn't have to be. The default gateway for the guests should then be the FW that leads to the internet, and if ISE is not on that VLAN, route to ISE as well.