Guest Wireless traffic to Blue Coat web proxy

[Jason Wing]

In my lab I have a Guest Wireless network setup and fully functional. Here is a brief diagram:

Client -> AP -> LAN switch and WLC-Foreign -> Core router -> DMZ switch and WLC-Anchor -> Edge Router -> Internet

I have NME for credential management on the LAN as well.

The WLC-Foreign is a 5508.

In my DMZ, I have two networks - 1 for normal DMZ management and 1 for Guest Wireless.

I now have to add a Blue Coat web proxy appliance into the DMZ and have Guest Wireless traffic pass through it. I have tried multiple scenarios including connecting the WLC-Anchor to the Blue Coat directly and making the Blue Coat the gateway for my Guest Wireless network.

Does anyone have a good design for the DMZ networks and/or routing to enable the Guest Wireless traffic to go to the Blue Coat and then out to the Internet?

[George Stefanick]

Jason,

We have our guest going through the blue coat, but I didnt set up the bluecoat piece. BUT, this is what our deisgn looks like...

(Foreign Controller) ----> (DMZ: Anchor controller) The subnet the client receives is in the DMZ. That traffic is then sent to the blue coat, as all DMZ  and internal traffic has to pass though it. We did nothing special on the WLC side at all.

Let me see if I can grab my wired guy and get back to you on this in a bit. Or perhaps, Scott or Steve has a few ideas.

[Jason Wing]

Thanks George.

The other thing I should mention is the Blue Coat is an Explicit Proxy (not Transparent) so we have to direct traffic to it. It is not simply inline.

[George Stefanick]

Ok, I have more information.

All of our traffic and including the wired traffic point to the FW. There is a configuration and ACL (http and https only) on the FW that points to the bluecoat. The bluecoat then grabs the web content and sends it to the client.

We did nothing special on the wireless side of things. We dump the traffic right in the DMZ subnet. The FW then passes it to the bluecoat.

I will see what that configuration looks like on the FW in a bit ..

[Jason Wing]

I ended up using WCCP to solve this issue.

To refresh, here is the network topology:

Client -> AP -> LAN switch and WLC-Foreign -> Core router ->  DMZ switch and WLC-Anchor and Blue Coat-> Edge Router -> Internet

The change to the topology:

Client -> AP -> LAN switch and WLC-Foreign -> Core router ->   DMZ switch and Blue Coat-> Edge Router -> Internet

                                                                                                   |                   |

                                                                                            New DMZ switch with WCCP and WLC-Anchor

I added an additional DMZ switch separated from the rest of the DMZ by a L3 link. I put the gateways for the Wireless Management (which only applies to the Anchor Controller) and Guest Wireless WLAN on this switch.

The Blue Coat is already connected to the primary DMZ switch. I ran another cable connecting the Blue Coat to the new switch on the Guest Wireless VLAN.

The WLC Anchor has Management and Guest Wirless WLAN connections to the new switch.

The new switch is a 3750 and it is only capable of L2 WCCP. This is why I put the Blue Coat interface on the Guest Wireless VLAN.

How it works - Guest Wireless traffic lleaves the WLC-Anchor and hits its gateway on the switch. The WCCP config redirects web traffic (80 and 443) to the Blue Coat. All other traffic (DNS, ICMP, etc) travels on its normal path. We are planning on deploying this solution into production next week.

The WCCP config on the new switch:

ip wccp 0

ip wccp 70

interface vlan 6

ip wccp 0 redirect in

ip wccp 70 redirect in

[mohankumarm]

I am actually looking for a similar solution but using Inline( Transparent Proxy) for wireless Guest traffic to avoid manual proxy configuration on the guest laptops.We are using BC300SG Proxy solution here.

The topology is as follows:

Client -> AP -> LAN switch and WLC-Foreign -> Firewall  ->  DMZ switch-> WLC-Anchor.

The DMZ switch will be configured with two gateways- one for Wireless guest traffic on say VLAN 100 and the other for the standard management interface.

Solution Option 1

If Bluecoat connects to the DMZ switch on the same VLAN 100 as the Anchor, will the wccp redirection work and which interface will be configured for redirection ..is this on the Bluecoat connected interface or the WLC interface. Also there is a requirement to run dynamic service groups as well. In this case, is there any ACL to be configured on the DMZ firewall to redirect traffic towards Bluecoat?

Solution2

Is it better off using a separate DMZ switch for Bluecoat and WLC-Anchor as desribed above.

Thanks and regards,

Mohan

[Jason Wing]

Mohan - apoligies for the delayed response.

I ended up going with a design that is more similar to your Solution1. I really did not want to deploy an additional switch into the DMZ as this would be more of a 'one-off' design.

On your DMZ switch, you need the gateway for your guest traffic (vlan 100 as you mentioned). Bluecoat and WLC-Anchor needs to be on this vlan. Next, configure layer 2 WCCP to forward only HTTP and HTTPS traffic to the Bluecoat. I started out with WCCP option 0 and 70 but had to add many others to accomidate ports that common mobile applications use.

Connect another interface on the Bluecoat to the DMZ management vlan. I also use this vlan for the management of the WLC-Anchor.

Now as the traffic leaves the WLC-Anchor and hits vlan 100 on the DMZ switch, WCCP will redirect only the traffic you specify to Bluecoat. If Bluecoat permits the traffic, it will forward out its management interface. Now the request is in the DMZ management vlan. You will need some type of route to point this traffic to point this traffic to the Internet.

NOTE - I initially wanted all traffic to go through the Bluecoat but it fumbles the DNS needed for the initial web redirect. This is why I use WCCP to only redirect the web traffic to Bluecoat. DNS goes straight out as I use public DNS servers.

I deployed my solution about a month ago and it has worked well. I hope this information is helpful to you.

[mohankumarm]

Thanks very much indeed and definitely will be very helpful for me as we are deploying a very similar solution:)

Regarding the http/https traffic that will go via Bluecoat, only one common WCCP service profile has been configured between the Cisco and Bluecoat devices for L2 WCCP to allow ip traffic for Guest VLAN traffic and the upstream firewall allows only http/https traffic from the DMZ, so should be no problems here i think.

Regarding the DNS, we are using public DNS servers as well, so wondering where this will be configured straight out to the Internet.

[Jason Wing]

To reach the public DNS servers you need their IP addresses to be specified in your DHCP scope. I used the internal DHCP server on the WLC-Anchor. The Guest VLAN traffic will also need to know how to get to those public DNS IPs because this traffic will not be directed to the Bluecoat. If you dont have any routing setup in your DMZ environment, you can use static routes specifying the next hop toward the Internet for the public DNS.

[mohankumarm]

Hi Jason,

Many thanks for your reply and sorry for my late reply.

Have just started to test the solution after firewall rules were added to allow http/https traffic outbound to the internet from DMZ BC Proxy only, and also the initial request to public Google DNS servers from the Bluecoat proxy.             Clearly, this solution did not work!

In the setup we have WLC, BC-Proxy, Amigo pod connected to the Cisco DMZ Switch on two VLANs - Management and Guest. DGs are configured for the management and guest vlans on the switch. DHCP scope for the DMZ are defined on the switch. Config snippet on the switch are:

int vlan Management

ip add ____

int vlan Guest

ip add ____

ip  dhcp pool Guest

network 192.168.100.0 /24

dns 8.8.8.8

ip wccp 100

ip wccp redirect-list 100

access-list 100 permit ip 192.168.100.0 0.0.0.255 any

BlueCoat and Cisco DMZ switch negotiate WCCP v2 without any issues with L2 for forwarding and GRE for return

All devices have been configured to point to  the public DNS 8.8.8.8 and the strange thing is that the public DNS server (Google 8.8.8.8)  was not reachable from the DMZ! despite static host routes and default  routes on the switch towards the firewall. The logs on the firewall (Nokia/Checkpoint) suggest DNS request going out to the Internet and no response back to the DMZ.

Now, if we have to send the initial DNS request via the switch and bypassing the BC proxy, how do we go about it..

Do all the devices need to be pointed to the switch for DNS?

What configs are required on the switch to process DNS requests and send this to upstream firewall?

The firewall rules to be added for sending DNS requests from the switch to the Internet.

Modification in WCCP redirect list to send only http and https to the BC device.

It would be great if you can share some of the config details on DNS and its processing via the switch.

Many thanks indeed.

[m-ko]

Jason and Mohankumarm, have you ever make it works without problem? If you have a workable soluton, I hope you can share.

Thanks

[Jason Wing]

Yes I have a workable solution.

Client connects to guest network on foreign controller. EoIP tunnel from foreign controller to anchor controller in DMZ. The WLAN and Interface for guest wireless have to be configured exactly the same for the EoIP tunnel to come up. Using WCS Lobby Ambassador for credential mgmt.

DMZ has two networks - one for DMZ management and one for guest wireless. Internet edge firewall is gateway for mgmt network and DMZ switch is gateway for guest wireless network. Trunk connecton between DMZ switch and anchor wireless controller passing vlans for both networks. Blue Coat web filter has two connections to DMZ switch - one for mgmt and one for guest wireless traffic. Using L2 WCCP on DMZ switch to forward guest wireless traffic to Blue Coat. Have specified about 70 different ports to accomodate all the apps people use. I would like a better solution for this part, as it is not favorable from an administration perspective.