Security

Hi All,

I’m redesigning the a guest network as they’re having issues with it and it wasn’t easily scalable in its current format.  First of all these “guests” all have active directory account but are all BYOD.

Network:

Master - Master controllers at the core
Local controller at each remote sites 

Here are the requirements of their guest network.

• Guest traffic must be tunnelled from local to master controller 
• Guest traffic must be proxied before breaking out to the internet
• Must be a simple design
• Must be easily scalable
• Guest all have active directory credentials

Originally I configured a GRE tunnel between local and master and used the “send via tunnel” option in the guest role to send HTTP and HTTPS traffic through the tunnel to the master. However as you have to specify the tunnel ID in “send via tunnel”  in the guest role, it would require an additional guest role per school which isn’t a route I want to start going down.

I’ve got a couple of idea of how to set this up..

1. Setup a Guest SSID, VPN to master, send authenticated guest traffic over VPN, source NAT the traffic at the master and use DHCP to deploy proxy settings.
2. Use existing Corp SSID, turn of machine auth, if machine auth fails put client in a role / VLAN that tunnels back to the master, source NAT the traffic at the master and use DHCP to deploy proxy settings.
3. Use existing Corp SSID + device finger printing to put client in a role / VLAN that tunnels back to the master, source NAT the traffic at the master and use DHCP to deploy proxy settings.
4. Use existing Corp SSID + clearpass? 

How would you design this?

J 

1.  Create a dedicated VLAN for guest traffic on the local controllers that are not bound to any interface.

2.  Extend that traffic via layer2 (not layer 3) GRE tunnel to the master controller (tunnel vlan x).

3.  Make the Master side of the GRE tunnel untrusted so that you can authenticate guest clients centrally at the master controller

3.  Assign that GRE tunnel on the master controller to a physical interface that will be routed in any way that you want, maybe using an external DHCP server, router and proxy.

4.  You do not need any "redirect to tunnel" or any special ACL on the local controller side; you just put clients on that dedicated VLAN that is tunneled back to the master controller.  The master controller will take it from there, since the traffic will be untrusted on that side.

1.  Create a dedicated VLAN for guest traffic on the local controllers that are not bound to any interface.

---

@cjoseph wrote:

1.  Create a dedicated VLAN for guest traffic on the local controllers that are not bound to any interface.

2.  Extend that traffic via layer2 (not layer 3) GRE tunnel to the master controller (tunnel vlan x).

3.  Make the Master side of the GRE tunnel untrusted so that you can authenticate guest clients centrally at the master controller

3.  Assign that GRE tunnel on the master controller to a physical interface that will be routed in any way that you want, maybe using an external DHCP server, router and proxy.

4.  You do not need any "redirect to tunnel" or any special ACL on the local controller side; you just put clients on that dedicated VLAN that is tunneled back to the master controller.  The master controller will take it from there, since the traffic will be untrusted on that side.

---

Thanks Colin. That's definately something to go on. I'll have to set it up in my lab. :)

I can see an issue here. With 20 - 30 local controller there would be that many GRE tunnels. Can I assign all of these GRE tunnes to the same physical interface?

Also as there could be say 100+ guests per local controller, 3000 or maybe more in total it might benefit to the DHCP locally and source NAT the guest traffic? Thoughts?

I do something very similar to this, except I L2 GRE back to a dedicated guest controller master out in a DMZ.  20-30 GRE tunnels is no big deal, it can scale much more than that.

So, all my locals advertise a guest SSID, its VAP is in vlan 10.  I have an interface vlan 10 on each local controller with an IP address in vlan 10 (not really necessary to assign an IP on the locals though), each local has interface tunnel 1 which is in vlan 10.  No physical interface is in vlan 10.  The tunnel is trusted on the local side and the initial role for the guest VAP basically just denies a user from being a dhcp server and permits everything else.  Like Colin said, you don't have to do a "redirect tunnel 1" on the acls, but I do, except for DHCP.  It's a little redundant to do it since everything is in vlan 10 anyway.

Once a user browses the web, his traffic hits the guest controller, which they must because the guest cotnroller is the default gateway for vlan 10.  The guest controller has a GRE tunnel to all locals, all are untrusted and traffic goes into the logon role before authentication.  On the guest controller, you set up your CP as normal. 

I use an external DHCP server for guests which is best practice I think.  Controllers can't really do more than 512 hosts at this point.

I'm not sure why you would want to tie the guest vlan (10 in my case) to any physical interface though, it's not necessary as I see it.  Just leave that vlan internal to the controllers' GRE tunnels and their vlan 10 interfaces.  Post-authentication, guest traffic will route out whatever interface the guest controller's default route takes them out of.  Source-natting on the guest controller's egress interface is a very good idea so you never expose the guest subnet to your internal network.

---

@mike.j.gallagher wrote:

I do something very similar to this, except I L2 GRE back to a dedicated guest controller master out in a DMZ.  20-30 GRE tunnels is no big deal, it can scale much more than that.

 

So, all my locals advertise a guest SSID, its VAP is in vlan 10.  I have an interface vlan 10 on each local controller with an IP address in vlan 10 (not really necessary to assign an IP on the locals though), each local has interface tunnel 1 which is in vlan 10.  No physical interface is in vlan 10.  The tunnel is trusted on the local side and the initial role for the guest VAP basically just denies a user from being a dhcp server and permits everything else.  Like Colin said, you don't have to do a "redirect tunnel 1" on the acls, but I do, except for DHCP.  It's a little redundant to do it since everything is in vlan 10 anyway.

 

Once a user browses the web, his traffic hits the guest controller, which they must because the guest cotnroller is the default gateway for vlan 10.  The guest controller has a GRE tunnel to all locals, all are untrusted and traffic goes into the logon role before authentication.  On the guest controller, you set up your CP as normal. 

 

I use an external DHCP server for guests which is best practice I think.  Controllers can't really do more than 512 hosts at this point.

 

I'm not sure why you would want to tie the guest vlan (10 in my case) to any physical interface though, it's not necessary as I see it.  Just leave that vlan internal to the controllers' GRE tunnels and their vlan 10 interfaces.  Post-authentication, guest traffic will route out whatever interface the guest controller's default route takes them out of.  Source-natting on the guest controller's egress interface is a very good idea so you never expose the guest subnet to your internal network.

---

Tying the vlan to a physical iterface is for when you have a separate external router that will be the default gateway, doing the natting and possibly the DHCP for the master controller on that guest Vlan e.g. a linksys.  I did not make that clear sorry.

---

@mike.j.gallagher wrote:

I do something very similar to this, except I L2 GRE back to a dedicated guest controller master out in a DMZ.  20-30 GRE tunnels is no big deal, it can scale much more than that.

 

So, all my locals advertise a guest SSID, its VAP is in vlan 10.  I have an interface vlan 10 on each local controller with an IP address in vlan 10 (not really necessary to assign an IP on the locals though), each local has interface tunnel 1 which is in vlan 10.  No physical interface is in vlan 10.  The tunnel is trusted on the local side and the initial role for the guest VAP basically just denies a user from being a dhcp server and permits everything else.  Like Colin said, you don't have to do a "redirect tunnel 1" on the acls, but I do, except for DHCP.  It's a little redundant to do it since everything is in vlan 10 anyway.

 

Once a user browses the web, his traffic hits the guest controller, which they must because the guest cotnroller is the default gateway for vlan 10.  The guest controller has a GRE tunnel to all locals, all are untrusted and traffic goes into the logon role before authentication.  On the guest controller, you set up your CP as normal. 

 

I use an external DHCP server for guests which is best practice I think.  Controllers can't really do more than 512 hosts at this point.

 

I'm not sure why you would want to tie the guest vlan (10 in my case) to any physical interface though, it's not necessary as I see it.  Just leave that vlan internal to the controllers' GRE tunnels and their vlan 10 interfaces.  Post-authentication, guest traffic will route out whatever interface the guest controller's default route takes them out of.  Source-natting on the guest controller's egress interface is a very good idea so you never expose the guest subnet to your internal network.

---

Thanks Mike. How large is your VLAN 10?

I use a /21.  I also ensure guests can't communicate with other guests, at L2 and L3.

---

@jrwhitehead wrote:

---

@mike.j.gallagher wrote:

I do something very similar to this, except I L2 GRE back to a dedicated guest controller master out in a DMZ.  20-30 GRE tunnels is no big deal, it can scale much more than that.

 

So, all my locals advertise a guest SSID, its VAP is in vlan 10.  I have an interface vlan 10 on each local controller with an IP address in vlan 10 (not really necessary to assign an IP on the locals though), each local has interface tunnel 1 which is in vlan 10.  No physical interface is in vlan 10.  The tunnel is trusted on the local side and the initial role for the guest VAP basically just denies a user from being a dhcp server and permits everything else.  Like Colin said, you don't have to do a "redirect tunnel 1" on the acls, but I do, except for DHCP.  It's a little redundant to do it since everything is in vlan 10 anyway.

 

Once a user browses the web, his traffic hits the guest controller, which they must because the guest cotnroller is the default gateway for vlan 10.  The guest controller has a GRE tunnel to all locals, all are untrusted and traffic goes into the logon role before authentication.  On the guest controller, you set up your CP as normal. 

 

I use an external DHCP server for guests which is best practice I think.  Controllers can't really do more than 512 hosts at this point.

 

I'm not sure why you would want to tie the guest vlan (10 in my case) to any physical interface though, it's not necessary as I see it.  Just leave that vlan internal to the controllers' GRE tunnels and their vlan 10 interfaces.  Post-authentication, guest traffic will route out whatever interface the guest controller's default route takes them out of.  Source-natting on the guest controller's egress interface is a very good idea so you never expose the guest subnet to your internal network.

---

Thanks Mike. How large is your VLAN 10?

---

jrwhitehead,

With that being said, you can create a number of VLANs at each controller (say 3) and add them to that guest virtual AP, not to any physical interfaces.  The tunnel interface can have as many VLANs as you want tunneled back to the DMZ controller:

(host) (config) #interface tunnel 20
(host) (config-tunnel)#tunnel vlan ?
<WORD> VLAN IDs of the VLANs this tunnel should be part of.

(host) (config-tunnel)#tunnel vlan

The guests can then be vlan pooled into all of those VLANs using the headend controller and those VLANs can be terminated using the DMZ controller:

Here are the general steps

create VLANs 10,11,12

create virtual APs  on each controller that has vlan 10,11,12

create tunnel between each controller and the DMZ controller carrying Vlans 10,11,12 and make it untrusted on the dmz side

Make the DMZ controller the default gateway for those VLANs, OR trunk those VLANs physically from the DMZ controller to an external router that will handle it from there.  Make sure your DMZ controller has an ip cp-redirect address that all three of those VLANS can reach so that it can bring up the page for all your clients, centrally.  Make sure you use an external DHCP server, for all your clients so that your troubleshooting for that component can match the rest of your infrastructure.

Hi All,

I'm going to set this up soon and have a question. I'm going to have 20-30 VLANs in this pool all of which I will source NAT on the master controller. I want all guest traffic to go out of a particular interface which is not the same interface that the default gateway goes out over. Is there a way to do this without changing the default gateway?

In a nutshell I want to source NAT the guest traffic and specify which IP the traffic is coming from (and therefore which interface the traffic will be going out over.

Thanks
James 

This is where I'm at.

Create above guest VLANs on master and local controllers.
Don’t assign guest VLANs to an interface.

Assign DHCP helper address on Guest VLANs on master (windows server is doing DHCP)

Add the guest VLANs to the Guest VAP

Create a GRE tunnel from local controller to master (tunnel ID 1,2,3,4,5,6,etc)

Assign guest VLANs to the GRE tunnel

Make GRE tunnel trusted on local end and untrusted on master

Default gateway on guest VLANs should be master controller

Source NAT the VLANs on the master controller
The gateway on interface which guest traffic goes out over is ISA server (guest proxy server)

• This can be done by changing the default gateway on the master to be the ISA server

Commands to create GRE tunnel

• conf t
• int tunnel 1
• tunnel vlan 61,62,63,64,65
• mtu 1492 (to ensure GRE tunnel "fits" in IPSEC tunnel)
• trusted (untrusted on master)
• tunnel src & dst on local
  • tunnel dest <master controller IP>
  • tunnel source <local controller IP>
    
    
• tunnel src & dst on master
  • tunnel dest <local controller IP>
  • tunnel source <master controller IP>

ip cp-redirect-address 192.168.0.254 (IP on a VLAN on master)

show int tunnel <ID> (to ensure the tunnel is up)

To scale this solution do the following:

• Add extra guest VLANs to master and all local controllers
• Add the extra guest VLANs to the GRE tunnels
• Add the extra guest VLANs to the guest virtual AP profile on the master controller
• Add extra DHCP scopes on Windows server for these extra guest VLANs

Anyone see any issues with that?

James

Mike i was wondering if you can share your config , i am trying to setup something similar.