Placement of Cisco ISE and WLC in Network Architecture

It depends on your requirements. ISE can go behind the DC firewall no issue. The WLC can go anywhere if you’re going to use FlexConnect for all SSIDs, or somewhere close to the core I’d suggest if you’re using either all tunnelled SSIDs back to the WLC, or a mix of tunnelled and FlexConnect.

Hi Craigbeck,

Thank you for sharing valuable input.

Requirements like could you please give some clues?

 

For instance, if we plan to route wireless traffic locally (Flex Connect) would make more sense to have it closer to the core and access points and avoid crossing firewalls?

Corporate SSIDs that require access to internal resources would have to pass through a firewall because the traffic has to be filtered.

Another requirement for Guest networks:

WLC and ISE shall probably be also connected via an separate interface to the DMZ for the below use cases:

WLC- to segregate guest network traffic from internal resources using a firewall.

ISE- for a guest portal

Thank you Craigbeck.

For ISE just want to add something here that our ISE deployment is distributed.  Recalling from my previous question

Solved: Cisco DNAC + ISE + WLC Deployment | Experts Exchange (experts-exchange.com) 

Do we still shall keep the ISE behind firewall?

HQ

3 x DNAC (cluster)

2 x PSN+pxGrid

2 x PAN

2 x MnT

Remote sites:

2 x PSN - site 1

2 x PSN - site 2 

2 x PSN - site 3

With regards to WLC, we have a pair of only 2 WLCs for HA at each site, which will need to integrate with DNAC and ISE. For the best connectivity approach. should we directly connect to the Collapsed Cores (VSS), or is it necessary to deploy a pair of access switches for this purpose? 

Or should we consider creating a shared services block within the Data Center and connecting all shared services there, including DNAC, ISE, and the WLCs?

Here is our current network_design.png

Appreciate your valuable input.

Hi Craigbeck

Any further suggestions as per the last post.

Thank you

For ISE, I'd say in that scenario, assuming only the DC has a firewall, it doesn't really matter as the deployment in its entirety is not able to be behind a firewall, given that some of the nodes will be at remote sites.

With regards to WLC, we have a pair of only 2 WLCs for HA at each site

Is that one pair for all sites, or one pair at each site? If it's one pair for all sites, put it at the core rather than behind the DC firewall. If you want to, implement a shared services block and connect the WLC, etc. there. Still though, put that outside of the DC firewall.

If you have WLCs at each site, what's the reason? Are you wanting to do SDA? If not, consider using FlexConnect. That would free-up a pair of WLCs that you can use as an anchor WLC in the DMZ.

For ISE, I'd say in that scenario, assuming only the DC has a firewall, it doesn't really matter as the deployment in its entirety is not able to be behind a firewall, given that some of the nodes will be at remote sites.

 

Hello Craigbeck,

I wanted to extend thanks for your feedback.

At our headquarters, our network architecture incorporates both perimeter and data center firewalls. The perimeter firewall serves the purpose of filtering both inbound and outbound internet traffic, managing the DMZ, and handling VPN Termination.

As for the data center (DC) firewalls located at our headquarters, they are primarily responsible for segmenting our network and controlling access to the server farm, as well as regulating east-west traffic.

On the contrary, at our remote sites, we currently only have a perimeter firewall in place.

In this context, are you suggesting that ISE should not be positioned behind the firewalls at both headquarters and remote sites, given the distributed nature of our deployment?

Could you also provide guidance on how we should configure Guest Access in this scenario if WLC and ISE shall be positioned on the Core side.

We have one pair of WLCs at each site. Our deployment does not include Software-Defined Access (SDA). The reason behind deploying WLCs at each remote site is to ensure uninterrupted operations due to nature critical business operations in the event of a VPN connection loss between the remote site and headquarters.

Thank you for your insights and advice

Thanks for adding some context.

Now I have a clearer picture (apologies if I misunderstood earlier), you should put the PAN and MnT ISEs behind the DC firewall. The remote site PSNs will be behind the remote site perimeter firewall. To enable comms between ISE nodes I would just allow all ports/protocols between them (the list is large and changes sometimes between software versions).

Guest access is difficult here. Do you intend to chuck guest users straight out of the local internet at each remote site, or do you want it all to go out of a central circuit, for example?

Thank you Craigbeck.

I'd like to ensure that the ISE design we're planning is both efficient and ideal. Can you confirm this for me based on your robust experience on ISE and Wireless.

Guess access would be straight out of the local internet at each site.

I have some additional questions. Sorry for that :)

1. Is there a real benefit of putting ISE behind firewalls.
If just for guest portal, we can just firewalled guest VLAN behind perimter firewall allow traffic from the Guest VLAN to reach ISE on TCP/8443?

2. How can I ensure that when I push a configuration from the PAN to Site 1, it doesn't propagate or share any information with the PSNs at other remote sites? I guess PSNs share their information with all other PSNs in distributed deployment.


3. In the event that the PSN1 node at Site 1 goes down, how can I prevent it from sending Change of Authorization (COA) requests to the PSNs at the other sites?

4. I'm also curious about the bandwidth requirements for sending logs from the PSNs to the Monitoring Nodes. We have 20,000 users at the Main Site and 10,000 users at each of the remote sites.

5. Policies which exist on PSNs in Site 1 would also appear on PSNs in Site 2?

6. Can we plug the WLCs to 9300 access switch stack, which has uplink to Cores? Then I would just plug DNAC, ISE and WLC to these switches to simply connectitvity?

I've uploaded our current network designs here

HQ - https://imgur.com/a/NUtoeL7

Remote - https://imgur.com/a/2vZ5mLf

Thank you once again for the detailed response.

I have updated the diagram showcasing the guest access. Appreciate your tips. 

If I bring ISE to the core side and intend to utilize VRF, how should the setup be structured? What are the essential steps and Where VRFs must be initiated and configured within the network path? Could you guide on this please?

Moreover, another motivation for deploying ISE at the core is to alleviate the strain on the data center firewall due to database replication to remote sites. What are your thoughts on this?

Since the SSID shall be in Flex Connect mode then I would connect WLC to core switches where it can get most resiliency in terms of network connectivity and performance. The core is usually the most redundant, fault tolerance place in the network.  But the question is if I do it that way it is possible that Core will be engaging in switching layer 2 frames for your access vlans

Yes, DNAC cluster would be only at the main site.

If I bring ISE to the core side and intend to utilize VRF, how should the setup be structured? What are the essential steps and Where VRFs must be initiated and configured within the network path? Could you guide on this please?

VRF only helps here if you tunnel the guest traffic to the DMZ using an anchor WLC. In that case you would/could then add an interface on the DC PSN (or add a new PSN) and drop it into the DMZ, so guests can get to it from the secure part of the network. Logically the guest and the ISE interface are both in the same subnet this way.

In your current scenario though you don't have an anchor WLC so it isn't possible anyway. If you had MPLS between sites you could add a new VRF and use that to securely transport guest traffic to the DMZ, but this isn't possible either as you have internet and VPN between the remote sites and the DC.

That means your only option is to use local internet breakout, as you've already mentioned. You don't need to use FlexConnect for this, and actually you shouldn't as it complicates things hugely for no benefit whatsoever. In fact, I wouldn't FlexConnect any of the SSIDs in your scenario, as each site has its own WLC and all traffic would naturally go to the site's core anyway.

I wouldn't worry about ISE replication between nodes through the DC firewall. It's incremental so it isn't actually all that much once the deployment is built. I'd still say that behind the DC firewall is the best place for it. All of the HQ ISE nodes should go behind the DC firewall IMO. 

I wouldn't worry about ISE replication between nodes through the DC firewall. It's incremental so it isn't actually all that much once the deployment is built.

Is it correct that only PAN handles the synchronization and replication of the database to PSNs, while PSNs at remote sites do not need to establish direct connections with other PSNs? And how frequently the replication occurs?

Yes that’s correct.

Replication will happen when something changes, be it policy, profiler info, etc.

Greetings, Craigbeck,

I'd like to propose an alternative approach for the anchor WLC.What if we deploy two hardware appliances and a third virtual appliance as the anchor WLC?
Will this configuration function as expected, and are there any specific license prerequisites to consider? It's worth noting that we currently possess a DNA Advantage license for our Access Points.

Thanks

If you're using the local internet access at each remote site, you won't need an anchor WLC. An anchor is usually put in the DMZ at a central site, like a DC. In your scenario, you can just pump guest traffic out via the local firewall by making the firewall the default gateway for the guest subnet.

As per Cisco's recommended model for guest traffic isolation, it is advisable to place the Anchor WLC in the DMZ :) :)

I plan to create a Guest SSID with a dedicated VLAN, tunnel the traffic to the controller, and then trunk it to the edge firewalls. These firewalls will be responsible for filtering and controlling access between the Guest SSID and the corporate network segments. 

Is this level of logical isolation and separation sufficient?

As per Cisco's recommended model for guest traffic isolation, it is advisable to place the Anchor WLC in the DMZ :) :)

That is correct, but it has its place, and in your scenario it would only really make sense to use an anchor at HQ as the network there is laid-out appropriately. If you want to follow Cisco's recommendation everywhere, you'd need an anchor WLC at each remote site, and that is overkill IMO.

In your scenario it doesn't really add much in terms of security if you don't have a DMZ at each remote site. You might as well just centrally switch the SSID at the site's WLC and connect a firewall interface into the WLC directly so traffic never has the opportunity to route across the site core. What model are your WLCs? Are they AireOS or Cat9K?

Cat 9800-40

If I connect WLC's another interface directly to firewall then I guess we wouldn't be able to LAG on HA SSO?

Thank you so much Craigbeck for your valuable, What is the difference between the three options.

1- Putting an Anchor WLC behind the firewall in a separate zone and tunnel the traffic to anchor WLC and then to the Internet through the Internet firewalls

2- Connecting seperate interface on WLC to DMZ because you earlier you have opposed this idea

you may need to put a single WLC interface into the DMZ. That would pose 2 immediate issues for me:


1. It would make me prefer to not put the other WLC leg(s) into the DC side of the network (therefore bridging the DC firewall).
2. I wouldn't be able to use LAG, so I would have no link redundancy for the WLC other than backup ports, which will introduce traffic drops in the event of a failure.

Select allOpen in new window

3- Simply create Guest SSID with a dedicated L2 VLAN on Core making the default gateway to the firewalls, tunnel the traffic to the centralized controller, and then trunk it to the edge firewalls then the firewall handle the Guest traffic

Yes, I am discussing it too on Webex Teams Space :). Hope I can reach you personally there :) :)

Option 1 is for a network where you have a DMZ and no direct way to securely get guest traffic to the firewall. Your HQ is a good candidate for this. 

Select allOpen in new window

DMZ is just another zone on the firewall. So, I can create an interface on the firewall?

Option 2 was something I opposed before I had more info and I made the (incorrect) assumption that your WLCs were AireOS. Now I know they're IOS-XE I have no issue with this approach. It is actually the most logical approach given your network outlay at the remote sites. 

Select allOpen in new window

So, I should have a separate Guest Switch to connect with the Firewall? :( 

Option 3 means you need to implement a VRF and additional routing on the core/firewall to keep it secure. You 
might as well just bring a firewall interface into the guest VLAN.

Select allOpen in new window

Is it possible without VRF? Just to create a VLAN on Core and make the default gateway point to the firewall. Guest traffic would first tunnel to WLC and leave traffic to firewall.

. Will you use DNS or will you use IP to direct clients to the portal?
2. If you use DNS, which DNS server(s) will you use? If you use internal DNS you will not be maintaining the desired security. If you use external DNS you need to use an external IP/hostname for the portal.
3. Will clients need to route via the internet to reach the ISE portal or will you route via S2S VPN? As per point 2, if using external DNS servers, you need to publish the ISE portal to the internet (firewall rules can restrict to only your remote site DIA IPs).

Select allOpen in new window

1- DNS

2- My intention was to utilize the firewall interface IP address of the Guest VLAN as the DNS servers and configure the firewall to act as the DHCP server for our guests. But this would load on firewalls unnecessarily. Subsequently, I aimed to assign a public domain name to the guest portal URL. To achieve this, I can create a DNS static entry on the firewall, directing it towards the internal IP of ISE, if desired to continue using the firewall as a DNS server

3- Why need S2S VPN? All the sites have WLC, PSN, and Local Internet breakout to handle wireless, authentication, and internet traffic. Remote sites don't need to come to HQ.

I am attaching diagram for both HQ and Site 1 for reference.

DMZ is just another zone on the firewall. So, I can create an interface on the firewall?

Technically a DMZ has a firewall separating both sides, so one to the internet and a separate one to the corporate network. Just using another interface/zone isn't really a true DMZ.

 So, I should have a separate Guest Switch to connect with the Firewall? :(

If you want it to be as secure as possible, yes. You should use separate interfaces at the firewall if you can, but it isn't mandatory. The only problem with not using a separate switch is you are bringing the guest traffic physically into the core, so you must make sure you have no direct L3 on the guest VLAN at the core if you do it that way.

 Is it possible without VRF? Just to create a VLAN on Core and make the default gateway point to the firewall. 

I may have confused you with the VRF. I was suggesting VRF at HQ if you don't anchor, or at remote sites if you want to route traffic through the core to the FW rather than just drop an interface into the VLAN from the FW. This is effectively what I've been saying.

Guest traffic would first tunnel to WLC and leave traffic to firewall.

Yes, this is standard CAPWAP with centrally switched SSID. Traffic leaves the WLC and flows to the firewall as the firewall is the default gateway for that subnet.

1- DNS

Ok, so need to provide secure DNS to guests that doesn't expose your corporate LAN but still allows guests to resolve the ISE portal URL FQDN.

2- My intention was to utilize the firewall interface IP address of the Guest VLAN as the DNS servers and configure the firewall to act as the DHCP server for our guests. But this would load on firewalls unnecessarily. Subsequently, I aimed to assign a public domain name to the guest portal URL. To achieve this, I can create a DNS static entry on the firewall, directing it towards the internal IP of ISE, if desired to continue using the firewall as a DNS server

So guests are routing internally to your ISE PSN? If you do this are you sending guests to the local ISE PSN at the same site? If so, ISE policy becomes a little more complicated (need a specific rule for each site for guest access), and a separate URL for each PSN).

3- Why need S2S VPN? All the sites have WLC, PSN, and Local Internet breakout to handle wireless, authentication, and internet traffic. Remote sites don't need to come to HQ.

If you were bringing all guests back to the same central PSN, the usual way is to either anchor, publish to internet, or transport via S2S VPN. Given that you're intending to send each guest to their local ISE PSN, this is no issue so can ignore.

Hi

To avoid any potential confusion regarding the points mentioned above, I've expressed them in topological terms to facilitate better comprehension.

L2 VLAN on Core without SVI.

L3 interface on Firewall

Guest SSID CAPWAP tunnel to WLC

Guest hit the guest network - default gateway will be edge firewalls which will handle filtering traffic and access to internet.

Redirect to ISE captive portal.

After successful authentication via SMS or Web Auth - Guest is granted access which will be through Edge Firewalls

Does this logical separation appear to be reasonably secure? However, there is one caveat: all traffic seems to pass through the Cores, even though it's operating at the L2 and not being routed. L3 routing is behind done only by firewall as Guest gateway is on edge firewalls.

Can we make it as secure as possible :)

So guests are routing internally to your ISE PSN? If you do this are you sending guests to the local ISE PSN at the same site? If so, ISE policy becomes a little more complicated (need a specific rule for each site for guest access), and a separate URL for each PSN).

Select allOpen in new window

Yes, guests will be sending requests to local PSNs situated within their respective sites. How do we manage and achieve secure DNS for the URLs?

Thank you Craigbeck. Your response is very helpful and informative.

I have updated the design: Connecting WLC to the DMZ switch, which is also serving as an L2 switch for internet facing servers. Does this make any difference from the previous design or make it more secure? (L2 transit VLAN on Core, L3 on firewall)

It's a little more secure, yes, in that the WLC sends the traffic straight to the DMZ switch, which is logically the other side of the edge firewall. It's effectively the same solution as at the remote sites, and is the same as the diagram I posted previously.

It's effectively the same solution as at the remote sites, and is the same as the diagram I posted previously. 

Select allOpen in new window

Yes, that's correct but here the caveat is that it's a DMZ switch, which is also connecting to internet facing servers. The switch is only L2, not L3 traffic. L3 is on the firewall.

Does it pose a security risk?

Yes, that's correct but here the caveat is that it's a DMZ switch, which is also connecting to internet facing servers. The switch is only L2, not L3 traffic. L3 is on the firewall.

Doesn't matter. It's the same concept - just another switch :-). It's exactly what you need.

Does it pose a security risk?

No.

Just seeing a small problem here. 

Using a one interface from the WLC to the DMZ won't allow me to configure redundancy as depicted below, primarily because the 9800-40 model has just four fiber ports available. To achieve below preferred redundancy 4 ports needs to be used :)

Please correct me if I am wrong

Hello Craig Beck,

I know this thread is closed but just wanted to add something.

WLC 9800 with dual home (DMZ switch & core Switch) won't cause any routing problems because the WLC will utilize a single gateway, which is connected to the core switch?

Kindly need your advice.

The WLC will have a management IP. That management IP is usually a SVI (VLAN interface) on the WLC. A default gateway will be configured on the WLC to allow it itself to reach remote subnets, but that has no effect whatsoever on client traffic.

For client traffic you will create a VLAN (or VLANs) which will just be trunked down the appropriate interface or Port-channel. That's L2 only so no routing involved.