Wireless guest access ranks as one of the top reasons why many of my customers implement Cisco ISE. It is relatively easy to implement and gives you a lot of control over what a guest can or can’t access on your corporate/protected network. Larger companies even implement DMZ wireless controllers in an Anchor-Foreign configuration. This adds an extra layer of security to keep unwanted wireless traffic completely isolated in a DMZ so that no traffic from unwanted/unknown devices touches the protected network.
Here are a few things to watch out for when setting up wireless guest access, FlexConnect, and Anchor-Foreign wireless controllers when the ISE policy node is in the protected network.
- Firewall settings
- The wireless controllers need to be able to communicate with each other.
- The ISE nodes need to be able to communicate with the Foreign (non-DMZ) controller.
- The clients need to be able to communicate with the ISE policy node on TCP port 8443 (default) for the guest portal. Add port 8905 if you are doing posture assessment as well.
- Routing
- Make sure there is a route between the protected network to/from the DMZ!
- I’ve had customers that didn’t have a route because they never needed one before.
- Wireless controller configuration
- The ISE nodes only communicate with the Foreign controller. No communication is between the Anchor controller and the ISE node.
- No network user or WLAN RADIUS configuration needs to be performed on the Anchor controller. This is because all authentications/authorizations occur between the Foreign controller and the ISE node. The Foreign controller passes the authentication/authorization information to the Anchor controller. You can run into session ID issues if you configure RADIUS accounting on both the Foreign and the Anchor controller.
- Any standard and FlexConnect ACLs must be configured on BOTH the Foreign and Anchor controller. The names must match exactly (spelling and case). The Foreign controller will pass the ACL name to assign the connection to the Anchor controller. If the ACL doesn’t exist on the Foreign controller, the controller basically ignores the CoA message.
- If no clients will be connecting to the Foreign controller at all, you don’t have to configure rules on the Foreign controller ACL list (e.g. blank ACL).
- Standard ACL: You can configure an all encompassing permit all Outbound rule (from WLC to client) to allow all traffic to the wireless client. You can then use Inbound rules (from client to WLC) to limit what the wireless client can connect to.
- FlexConnect ACL: You must either configure a rule for each inbound and outbound connection or create an all encompassing rule to allow all traffic with a source equal to any and a destination equal to the wireless client subnet. For the second scenario, the other rules will have a source equal to the wireless client subnet and then whatever you are allowing access to for the destination.
- I highly recommend configuring the guest WLAN to drop peer to peer traffic under the WLAN Advanced tab.
Cisco article: Central Web Authentication on the WLC and ISE Configuration Example – Anchor-Foreign Scenario