Centralized Traffic Flow with Guest Access (Cisco Wireless LAN Controllers) Part 2

Wired Guest Access

Wired guest access allows wired guest clients to use the controller for network access. This is useful in that a single device handles both wired and wireless guests. The controller supports up to five wired guest LANs.

To achieve this, the controller acts as a bridge between the wired client Layer 2 ingress VLAN and the Layer 3 egress VLAN. The wired client will have an IP address from the L3 VLAN and not the L2 VLAN. For example, if the wired guest VLAN is in VLAN 10 and the egress interface on the controller is in VLAN 12, the wired client will have a VLAN 12 IP address. The controller requires a Layer 2, or Guest LAN, interface in the wired guest VLAN to bridge the traffic. This is referred to as the ingress interface. Figure 14-19 shows a sample guest LAN interface.

Although the configuration is for wired clients, you still need a WLAN for those clients as seen in Figure 14-20 so you can configure the proper ingress and egress interfaces. When creating the wired WLAN, you would select guest LAN.

When you select Guest LAN when configuring the WLAN, the security tab changes to reflect the supported wired guest security settings.

Figure 14-19 Guest LAN Interface

Figure 14-19 Guest LAN Interface

To set up a wired guest LAN from the controller GUI, follow these steps: Step 1. Create your ingress and egress interfaces.

Step 2. The ingress interface is L2, so there is no IP address. Make sure you select the Guest LAN check box.

Step 3. Egress is any other dynamic (or management) interface you want to use. Wired and wireless can share the same egress interface.

Step 4. Under the WLAN tab, create the Guest LAN, not a WLAN as illustrated in Figure 14-20.

Figure 14-20 Guest LAN Configuration

Step 5. Select the correct ingress and egress interfaces, as demonstrated in Figure 14-21.

Figure 14-20 Guest LAN Configuration

Step 5. Select the correct ingress and egress interfaces, as demonstrated in Figure 14-21.

Figure 14-21 Ingress and Egress Interface for Guest LAN Step 6. Enable web auth security, and so on.

Figure 14-21 Ingress and Egress Interface for Guest LAN Step 6. Enable web auth security, and so on.

Tip If more than one controller is on the network, you cannot have an ingress interface on both controllers for the same VLAN. Because the traffic is Layer 2, the client traffic can be picked up by either controller, and the client can see multiple authentications or other odd behavior.

Wired guest access is supported with guest tunneling as well. The setup for wired guest tunneling is the same as that for WLANs except for the ingress interface on the anchor controller. In this case, because the client traffic will be coming from the foreign controller via Ether IP the ingress interface would be set to none. Similar to wireless guest tunneling, the egress interface on the foreign controller can be anything—such as the management or a quarantine interface—because the client traffic on the foreign controller will never traverse that interface.

Troubleshooting Wired Guest Access

When configuring wired guest access, you need to remember several important points.

■ The controller can support only five wired guest LANs.

■ The ingress wired VLAN must be strictly L2. It can exist only in the VLAN database. There can be no Layer 3 interface for that VLAN on the switched network.

■ show vlan should list the VLAN.

■ show interface vlan vlan ID should show nothing:

■ show interface vlan vlan ID should show nothing:

■ Even if the VLAN interface has no IP address and is administratively shut down, it will break wired guest access.

■ Open, web authentication, and passthrough are the supported authentication policies.

■ You would use the same debugs that you would use for troubleshooting wireless guest access.

Remember that the guest VLAN needs to be trunked across all switches from the access switch the wired guest client will be connected to all the way back to the switch the controller is connected to.

An interesting caveat to wired guest access is the model of switch that serves as the core Layer 3 device and where the switch resides in the network topology. If you are using a 3500 series switch, for instance, the switch will not forward a packet that is destined to an SVI MAC address that it owns. This becomes a problem for wired guest access if the 3550 is between the wired client and the controller in the network (see Figure 14-22). The wired client will get a DHCP address, but when the browser is opened, the client will never see the redirect page. A packet capture will show that the DNS query by the client never makes it off the switch. This is because the DHCP request by the client is broadcast and the DNS query is unicast. The switch will flood a broadcast packet out all ports, but when the client sends a unicast packet, the switch will drop it because it owns the destination MAC address of the default gateway of the egress VLAN. This means DNS will fail because the controller cannot bridge the packet if it never receives it. With no DNS, the client will never send the HTTP GET and the controller will never send the redirect.

Figure 14-22 3550 Series Impact on Wired Guest Access

Figure 14-22 3550 Series Impact on Wired Guest Access

Larger multilayer switches like the Catalyst 6500 are not subject to this issue because those switches handle their SVI MAC addresses differently.

Notice that in the third example (in Figure 14-22), the controller is connected to a switch on the same side of the core switch as the wired guest client. With this topology, the controller is able to bridge the unicast traffic from the client to the Layer 3 egress VLAN before it gets to the core switch. In this case, wired guest accounts will succeed.

Summary

The wireless controllers allow you to centralize guest traffic on your network and authenticate guest users. Depending on your goals, you can provide a completely open guest network, authenticate guests against the local WLC database, or use external RADIUS or LDAP servers for authentication. It is important to understand how web auth works and what network resources, such as DNS and correct firewall configurations, are required to allow the feature to function properly. You must also be aware of the physical devices on the network, such as your switching infrastructure, that could inadvertently block wired guest access to the controller. If you are going to implement auto-anchoring, you need to correctly configure both the anchor and foreign controllers to correctly tunnel and load-balance the guest traffic through the network. When all of this comes together correctly, you will have a robust and secure guest solution for both your wired and wireless guest users.