CCIE Wireless Training Video :: Guest Networks

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
today's topic is going to be wireless guests so some of the things we'll talk about today the goals of a wireless guest Network some of the methods we can use to achieve those goals and then we'll be running through configuration examples of some of the most common guest setups that you'd run into and a lot of the features that you're going to want to be aware of so first off the goals of guests networking in my opinion at least we have two major goals when it comes to a wireless guest Network first we actually have a network that we're having we want people to use so we need the network to be you know as easy to use as possible and as easy to support as possible we want to give our users the best user experience that we can while meeting our other goals and we want to not overload you know the helpdesk or make it cumbersome on the back end to have to support this guest model now the other major goal that we have and often times it conflicts with the first goal is security we want to protect our internal network from what's happening on the guests because the guest is a little bit more Wild West in terms of often times we're getting you know people on the guest network that we may not want depending on our security method and we we never can know the state of their PC so even if they aren't a malicious user themselves their PC may be infected with viruses or worms or it's compromised in some way that could be used as a staging point to attack our internal network so you know oftentimes these goals are conflicting with each other in terms of an easy-to-use network that's easy to support but also a network that is going to be secured and protect our internal corporate network from any potential attacks so how can we achieve some of these goals and what's the the solution is ultimately going to give us the best of both worlds at least as best as we can get so the first goal of having an easy-to-use network is generally driven by what type of a network we have in terms of authentication so you know like an open network compared to you know web redirects or you know pre shared key type networks that's definitely not drive the user experience in terms of how easy it is for them to use so let's kind of talk about the different types of networks we could use for our guest Network and some of the pros and cons of each of them now the classic type of network that we use in guest is some flavor of an open network so we're not using a sort of pre shared key we're not using AO to that wax or anything like that so at the most basic level it could just be a plain open network with no layer three authentication so basically a client connects pulls an IP address and boom it's on whatever network you placed it on the client doesn't have to do anything special other than saying connect to this network now from a client perspective that's phenomenal because they don't have to do anything special and especially when you start talking about devices like you know smartphones or tablets where sometimes it can be a little bit of a pain to go through the web redirect process and you know sometimes you actually lose your connection to the network and have to redo this over and over throughout the day if you're there for a long time they love it but it gives you zero control and zero visibility into your clients connecting so all you really can see is their MAC address and you know if you want snooping on where they're talking to but we can't control who gets on our network and we can't do things like you know pop up some acceptable use page and say you know you have to agree to this stuff before we let you on so the lawyers typically don't like that but if your company from a security standpoint and from a legal standpoint doesn't mind it it's by far the easiest thing to support and by far the best user experience that you can get but it's usually not an option available to you most of the time we need to get some sort of a layer three authentication method on top of that open network so the two options we really have for that is we could just have just a generic web app generic but we could rather than force them to log in with user credentials we can just redirect them over to some sort of acceptable use policy page so they get on the network they try to go out to a web page they get redirected to this page of yours that tells them everything that they should and shouldn't be doing on your page and they actually have to click accept you know maybe they have to type in some sort of information like their name or their email address or something like that optionally but they aren't required to put in any credentials they just have to accept whatever you tell them and so from a legal perspective it's nice because you know the lawyers are happy because they've accepted some sort of agreement that they won't do anything naughty on your network and that kind of covers their back ends from a legal perspective I guess but you aren't controlling who's on your network so anyone can still get on your network just fine it's a little bit of extra work so it's it's still not you know limiting who can be on your network so if it's important for you to do that that's not really an option then you're going to move into the option of a full layer three web authentication where now they still connect up redirect to a web page but that web page is asking them for a username password now a username password could either generally be shared across to everyone so we just have one username password that every guest uses or we could have a per user a per guest username password authentication so here we're at least somewhat controlling you know either basically controlling you can get on or we're enforcing a lot higher level of control over who can get on to our guest network obviously with the shared username password that gets to be pretty well-known you obviously all the corporate employees know it and then they start giving it out to everyone and so it's better than nothing you know some stranger just trying to sit in your parking lot probably doesn't know it but it's not a secret there's not a huge secret by any means so we can keep some people off of our networks but of the people that are on our networks we can't really track too much so it all looks like the same person to the network that just different MAC addresses but it's very easy you know we don't have to have this username provisioning process that every single time a new guest comes in they go through the process of getting their own user account so from a support standpoint it's a lot easier to support and less work but less control moving over to a per guest username password now we have a lot higher degree of control typically these per user our guest user credentials are also expiring so they're only valid for a certain lifetime so even if it does get out in the wild it's only worthwhile for a certain period of time so we get a lot higher degree of control over who can get onto our guest network but with the added cost of the back end expense of you know now we need people that can actually provision these guest accounts maybe it's you know one or two people that are up at the front desk or it could be you know every employee has the ability to do it so you know there's training that goes along with you know getting people you know taught how to use the system to provision the credentials it's a little bit more support on the back end when something's not working right but usually one of these three things plane open open with just an acceptable use page or open with a full web login credentials and you can optionally throw in an acceptable use page on the end of that as well is typically where we're falling in somewhere in that because the pros and cons of these you know on an open network any client can connect to an open network so that's usually not a problem adding in the web redirect usually works for for most any guest type device anyways a guest device is going to be some sort of a laptop or a tablet or something like that so they all have web browsers and they should support that usually fairly easily and another reason that that's nice is that usually when corporations write policies on their laptop some corporations will actually enforce policies on their laptops to say these are the types of networks we're going to allow our corporate assets to connect up to and if they want you to connect up to a guest network they're going to assume the guest network is some flavor of an open network so policy as long as the corporation is cool with you connecting to guest networks will allow that open network connectivity some of the the downsides though to the open network is you know real common downside is DHCP starvation issues so if you have a real big facility and you get lots of people walking through it often times you know our phones or whatever will automatically just connect up to a No Network so even if they don't ever authenticate you know you're doing some sort of a username password authentication even if they don't authenticate they still use an IP address so if you have enough of these people in your facility like a hospital or a college or something like that where there's just tons of people always milling through you can quickly burn through your IP range pretty fast oftentimes in those types of areas you need really big DHCP scopes and you really need to jump a drop-down the least time so those leases are always being given back as long as those you know people wants those people leave it doesn't take very long for the DHCP address to get back into the pool and available to someone else but it is something that people oftentimes have to fight in these types of environments there is no encryption over-the-air on an open network now normally there's no expectation of encryption over-the-air so that's not that big of a deal honestly if people want to get encryption over-the-air that's usually where you'd say ok just spin up a VPN connection to your company and then everything going across that VPN connection is encrypted so if you want some sort of a security that's one way for them to get the security but again it's not expected so it's not really that big of a deal not to be providing encryption across the air so yes a few pros and cons but there's more a lot more pros to it and you know the pros really drive towards why we use these as our main method of guest networks the other options that we have for guest networks often times I'm asked when I was back in the corporate world or sorry in the Cisco partner world you know people would say well how about a WPA pre shared key network so that that has a few you know positives around it so with a WPA pre shared key style network we get some form of an authentication so it's akin to that shared username password that we would have in the open network side so it's the same key for everyone but it's still a password and it's better than you know nothing so we are someone controlling who can get on our network with appreciate key network once they're on our network we're giving them encryption so you know it's an added bonus you would think to your guests that the only little service you can provide to them and it also helps prevent against that dhp starvation attack people don't pull an IP address on the VP a preacher key Network until they actually authenticate up to the network so if you don't authenticate you don't pull an IP address so you don't have to fight that DHCP starvation issue if it is a problem in your environment so you're thinking okay great what's the downside because all I'm really seeing is positives here well some saw some downsides you can run to with a pre-shared key style network one not everyone's going to be able to connect to it you know it could be a corporate policy thing where they don't allow you to connect up to pre shared key style networks very very small percentage would fall under that some people might not be as savvy with using their stuff again some supplicants are better than other stuff against in terms of you know how it would interact with you if some will just pop up and say okay let's pre shared key and you type it in boom you're good some of them are a little bit less so in terms of their ease of use so requires a little bit of extra savvy on the guest user standpoint but other than that I mean those are the main two detractors there but still you know we try to drive towards those open networks but if you really needed to target a few of those things especially like the DHCP starvation attack issue that might be a decent alternative to an open network now adding in layer 3 on top of that you know if you actually still need to do acceptable use pages and stuff like that that adds on another layer of complexity and we won't really get into that today but that is another thing that you're going to need to sort through in terms of that the other thing that we could really do would be like a wp8 with an e authentication and that's just really not very viable that would be you know you know you want some sort of security you want to prevent this DVP starvation attack and you also want to do a per user or per guest user credentials all that eat what I guess we give you that but then the battles you're going to fight with EEP is okay well what type are we going to use that everyone supports that pretty much drives you towards eeep because ETLs we need a client certificate there's no way we're going to do that and eat fast and leap aren't supported across every client so okay now we're using peat and now we have this server certificate that's going to be pushed down to the client for the client to validate and not every client is going to be able to validate that they're going to be given cert warnings probably unless you have a publicly signed cert signing your your radio service or so almost never done there so I would say either do some sort of an open network or in specific instances that you need to target specific issues you could do a WPP a pre shared key network but I wouldn't ever get into a neat style network and I definitely went doing sort of web stuff because that's pointless all right so those are some of the ways you know some of our options for our guest networks and some pros and cons for those now let's talk about the design of our network and getting that security so the main tool that we have to give us security in terms of protecting our corporate network from the yes network is going to be separation we want to separate that guest network as much as possible from the corporate network so that they never really interact with each other except through some sort of controlled point of access between the two networks that you can you know have a heavy amount of control over what if anything those guests are able to communicate to on your corporate network so we'll talk about the different types of designs that can achieve that separation pretty much from best in terms of the most secure methods all the way down to sort of the least desirable secure methods okay so what's going to be the most secure method I'm going to start drawing some of the stuff out so let me flip over to another view here so the most secure method that we're really going to have in terms of that separation would be completely separate wireless networks so we have a wireless guest network and we have a wireless corporate network now no one does this for a very good reason if you have two separate networks in the same RF space they're going to be competing with each other they could see it you know depending how you have things configure they could see each other as rogues even if they aren't seeing each other as rogues they're going to mess with the trailer from an RRM standpoint or an interference standpoint so no one does this it's not really a valid option so how can we get that separation well you know having a shared you know 180 supports both corporate and guess well the best solution and is the one that Cisco is going to drive you towards is to have your internal controllers where all your access points are located and then you have a DMZ and within the DMZ you have wireless LAN controllers there and you tunnel those guest clients to that DMZ controller so what would that kind of look like here so up here we have a DMZ and we have a wireless LAN controller in between the DMZ and your corporate network you probably have a firewall and then down here we have Corp with you know one or more Wireless LAN controllers and we have a bunch of EPS are all up on these internal controllers in the corporate network so all the corporate networks are just dropping off locally on the controllers but our guest networks can be using the mobility anchoring feature and so those would tunnel up the guest network specifically to this Wireless LAN controller that lives in the DMZ so it'll happen as a client connects up to the access point the access point sends it up to its controller via cap web instead of dropping it off locally the controller then tunnels it through an Ethernet over IP tunnel to the wireless LAN controller in the DMZ and at that point they drop off on the network so the clients logically live in your DMZ and you control your policy using a firewall which you know is an advanced you know security device as you know staple it's a stateful firewall can do a deep packet inspection very easy to control policy using a firewall you already probably have polished enough policy in place to protect yourself right off the gate but with a firewall we're saying okay what if anything can these guest clients talk you on the corporate network so the clients never even live technically in the corporate network they live in the DMZ from a logical standpoint so it's very secure and we can use something like a firewall to control the policy of what these clients can talk to if anything on our corporate network so by far the most secure meant that we have the downside to this is that we have to buy additional controllers that live in the DMZ so from a cost perspective you know we're buying additional controllers that you sometimes ApS never even associate up to historically we've also had to buy the more expensive controllers 4455 hunters that can terminate these tunnels with today's code we can do that with a 2500 series controller so now it is even more affordable to do which is a nice change but historically has been a bit of a price jump to to have this DMZ model here and another nice thing about this DMZ model is it spans multiple sites so not only can I have you know if this was you know site a can tunnel to this DMZ I can also have sites you know B through Z over here with their controllers tunnel across you know some sort of a LAN connection and drop off into the DMZ so this can scale to many many sites if you want or you could have you know in a very large design you can sort of have an East Coast dmz west coast dmz type thing for redundancy or whatever it's going to be but the awesome thing here is you're you only have to apply policy in one place so no matter how many sites if they're all funneling into the DMZ I only have to apply policy at this DMZ firewall and that makes life a lot simpler if I had to apply policy in 20 different sites it's a lot easy for me to goof up the policy in one of those sites or if I needed to make a change I had to make a change across 20 different sites so from an administrative standpoint it's awesome and it scales really real well but again the one downside is that you have to buy additional controllers and I guess you know here you actually have to have a DMZ for this to make it work so on a very very small location it might not be a possibility just because it doesn't have a DMZ or whatever that's definitely the best option in general once you get at least to a medium size network and that's generally where you want to try to drive to if it's going to give you you know the best results from a security standpoint as well as administration massive amounts of scalability it's a pretty good design if that's not available to you because either you don't have a DMZ or more likely cost becomes the factor you just can't justify the cost of yet another controller just to terminate this stuff we do have some other options that are still pretty good another option that we have you know we pretend we still have a DMZ and we have a firewall and then we have our Corp Network I want to draw one controller here so we have our internal controller with our ApS on it and what's going to happen on here is now we don't have this other controller though that were tunneling up to so we have to drop this traffic off locally but what we can do is rather than just drop it off of some network that's routed internally in the corporate network we have two options here we can either have a separate interface on the wireless LAN controller that plugs into a switch in the DMZ or if the DMZ is so small that the DMZ really is the firewall you know it could plug directly into the firewall itself on a specific port in the firewall so in that respect you know on the wireless LAN controller we would drop it off on a specific VLAN and that VLAN is assigned to an interface and that interface is just wired all the way into the DMZ so technically you're dropping it off directly in to the DMZ so we still get the benefits of you know the firewall controlling policy in terms of what can talk into our corporate network from the DMZ to Corp but it's a little bit more limited in that one this design requires some sort of a layer two connection up into the DMZ or up to the firewall device itself so if we want to string a physical wire you know if it's copper we're limited to that hundred meter copper distance if it's fiber we can go a whole lot farther another way you could do it would be if you didn't want to have a separate physical connection and back out of this we could just drop it off on a VLAN so if we had a switch here we would drop it off on a VLAN that plugged into the switch and then ultimately the switch itself could either plug into the DMZ or into the firewall directly so if the controller isn't close enough to the firewall to do it we could as long as we had a layer two path somewhere through our network and that VLAN was unrouted so the VLAN just trunked all the way up to the DMZ or all the way up to the firewall that's another way to get around that distance limitation but ultimately what's happening is one way or another we're dropping the clients off on a specific VLAN and the only place that that VLAN goes is directly into the DMZ so we're still living in the DMZ we're still controlling policy through a firewall this doesn't scale nicely like the last one did you know if we had site B over here it's extremely unlikely that you have a layer two connection between site B and C and D and D and so on to where your dmz is so sometimes you do but oftentimes you don't so it doesn't scale across any sort of layer three boundaries and typically we have layer three boundaries across R and again not always but oftentimes we do so it doesn't scale as well as that other solution does so if you had to replicate this at every single that means every single site needs its own DMZ and it also means that you're applying policy and every single site so you're not generally applying policy in one spot anymore you're applying policy in many different spots but you don't have to buy another controller and this works honestly really well in just a really small network I've I've used this method and in small networks before like a school or something like that where cost was a big factor so they couldn't justify another one but they did have a firewall and so sure you know what Wireless LAN controller is not that far away we just pipe it right over and we still get all those benefits of using the firewall and having a DMZ so it's easy to to control with policy it's just doesn't scale very well so a question couldn't you still build a mobility anchor in HQ controller and route the client off on the DMZ VLAN ah yeah that's a good out that is a good option so that would help its scale yeah yeah that's a very good suggestion so that would help with that scalability option so that that is definitely something that you could do now oftentimes if we are scaling to a large number of sites and we have controllers in every other site you probably can afford to buy one more controller and put it in your DMZ so once you start getting into that scale question I would hope that you could afford that extra controller but if you couldn't that would be a decent solution yet tell it to the controller in the Corp and then drop that off into there so good suggestion another way that we could kind of achieve this that's a little bit more scalable would be so rather than jumping off on layer to VLAN that lives in the DMZ we can control separation through verbs so with virtual routing and forwarding if you're familiar with that basically we assign different ports to different verbs and each verb has its own unique routing table within a switch so a switch could have a guest verb and a corporate verb and the guest berth would have only the network's that would lead it into the DMZ or to a firewall or something like that so the route table lookups would funnel it into the vmz because in the Gasper if it wouldn't have any of the networks that are in the corporate network now this is a solution yet it does provide separation but typically the switches that are used with firsts are pretty expensive most often times or you know so you're buying you know like sixty-five hundreds or these big bulky switches that cost a lot of money and usually if you can afford that you can afford a controller in your DMZ so most of the time while it is an option to give you separation if you can afford it you can afford a controller probably in your DMZ the last option really is pretty much just pretends you don't have a DMZ or you can't get to a DMZ so with the last option really all we're doing is we just drop the traffic off locally and the VLAN and subnet live in your corporate network and so what you do is you just create an ACL and apply it to the SVI that's the default gateway of this corporate or of this guest network when you use the ACL to say okay the things that you can talk to and these are the things that you can't talk to you just have to make sure you write your ACL well enough so that you don't accidentally allow unintended access into your corporate network so if it's a real simple ACL it's pretty easy to control but the longer that ACL gets the easier it is for you to miss something and it's hard to test everything unless you have some really established penetration testing type tools in your network so I always use this as the last resort so if I don't have a DMZ that I can get access to I'll use this so most of the time you know smaller networks is where I'm doing this but the downside here is you know you have to write these ACLs for every single guest network so if you had 10 sites you would have to write 10 different ACLs and it's a lot easier to make a mistake we start talking larger numbers like that so that would be the last resort in my my opinion as much as possible I try to get the two a DMZ and try to be using something advanced more like a like a firewall or something like that to control my policy but nacl works everywhere so it's always something available to you pretty much no matter what your network is okay so enough about the background here let's actually get into some demonstrations of the configurations so in my network I have a number of controllers here we're going to start off on controller 2 so on controller 2 I have a couple of access points so I have two access points on my controller and I have a couple rabba a layer 3 a dynamic interface so I have e LAN 13 so I can drop traffic off the low place will pretend a single controller set up here all right so usually the first thing you know I have my interface drop it off onto so VLAN 13 will be my guest interface so let's just look at some of our options in terms of the web pages that we can be using so the web pages for internal web authentication it's going to be under security web auth web login page so we're gonna have a couple options just built in to use the controller as our web server so when we do these layer 3 web redirects the controller itself is actually the web server so it's the one providing the web page to the client so we have this default internal web page looks pretty ugly if you haven't seen it this is it so you know not customized to your environment at all the most customization you can do is you can change this text here so you can change the bolded text up top this down here and the little Cisco logo on the top right you can turn that on and off but that's all you can do so if you wanted to tweak that here's we can show or hide the headline is the bolded part and then the message is down there hi there thanks for coming so if I apply that now I can see that here's my custom message so that's about all you can do with that but it's simple it's always available to you the other thing that we can do for an internal internally served web page is going to be a customized so rather than using that really generic you looking web page we can actually code our own web pages and install them on the controller and I'll actually demonstrate that a little bit later so now we can actually create web pages that look like the rest of our corporate web pages and we can put our own images and look feel to it but it's still being served up by the controller so that's a decent alternative if you don't want to be directing them out to some sort of external web server which is the last option external so here rather than serving up the website on the controller we actually send them off to some external web server the external web server is then responsible for providing the web page as well as any sort of authentication measures so both the web page and the authentication are happening off of the controller on an external redirect so that's not very common the external web redirect except in maybe larger environments but we'll start off with the internal the other the one last thing you can do here is we can do this redirect URL after login option so normally what would happen my web client comes up I try to get to Google com they redirect me to the web login page I log in and then normally it would go ahead and let me go go back to google.com well if you want you can actually say after you login I'll send you to a web page of my choosing so you can have your own your page com and then what after they log in they get redirected to your page comm or whatever it's going to be you know oftentimes it's our corporate web page or whatever it's going to be so that is one option there so we'll go ahead and start off just using the the internal default username pass or web page now if we want to do a username password authentication another thing that we're going to need to have up and running is a username password to authenticate with so that's going to be if we do it locally on the controller it's going to be controlled under this local net users so security triple a local net users new and then I could just say you've guessed one with a password of guest one now if I do it just like this this user account is permanent it does not expire so it would be good for forever if I check guest user this makes it a limited lifetime user account so after so many seconds this account will expire so typically I'm going to do this if I'm giving per user per guest user credentials if I want to have just a shared username password that's used across to everyone most of the time that I would make it a permanent account and that way I'd never have to worry about it expiring so I'm going to leave it as a permanent account here the other option we have for authenticating is we can actually send this off to an external web server like a CS or sorry an external radius server like a CS and a CS or the radius server could do the authentications for us and send back a response a or an a to the wireless LAN controller so we'll show you both of these as well all right so let's go ahead and just do a real basic web page our W LAN so let's create a new W and call it guest pod one since I'm on rack one over at Procter labs there let's turn it on and I'll go ahead and assign it to VLAN 13 so the client should pull an IP address and VLAN 13 so this would you know typically on a single controller solution this would be the unrouted VLAN that I try to get into the DMZ or to the firewall otherwise this would be the VLAN that I applied the Akal to to control what the guest can talk doing what they can't we do none for layer 2 security and then we go ahead and turn on the web policy for layer 3 so we're typically only going to use one of two options within here 90-odd percent of the time it's going to be authentication if we want to have them put in a username password or if we don't want to require user name password wheelers want to give them that acceptable use page that would be pass-through so we'll show you pass through real quick and then we'll show you the often authentication with pass through locally on the controller we do get the option to ask for an email address client would have to you know L know except well use page type in whatever their email addresses so if you want to collect that check the box if not just leave it unchecked and that's honestly all we have to do to get guests but some of the other things that will commonly do with QoS will put them in the bronz quality of service queues so they have the least priority access to our RF networks or our internal devices we get better access since they'll be at silver typically or even higher if it's like a VoIP or video or something like that so what will knock them down to bronze other things that we might be doing session time up becomes kind of important especially when we do these layer 3 web policies because the session timeout basically says once you're up on my network I start a countdown timer and after that countdown timer runs out I D authenticate you and then you have to do a full Rihanna keishon and what that's going to imply is that they have to do whatever web authentication whether it was passed through or web off they have to do that all over again so if it's a short time they're going to be keeping on you know getting redirected to a web page to real aughh in so on a guest network typically why what you want to do is Jack this up to you know at least something like you know 2 hours 4 hours 8 hours you know whatever your average guest stay is on a given day so they're not always having to you know Rio Dental Cait and redo that web redirect so I'll go ahead and jump them up to something higher here a little bit more reasonable I think this is maybe four hours or something like that so or you could flat-out turn it off I don't know if I would would do that but definitely at least get it higher than thirty minutes because otherwise every 30 minutes they're going to be doing a web redirect and that's frustrating from a user standpoint some other things you could do in here you could do like a DHCP address requirement required so you're not allowing them to use static IPS because what guests would ever use a static IP in your network it's a common configuration a lot of other stuff is just personal preference type things but those are two common things that you might want to do in a guest network sorry another one that might be kind of common with a guest network peer-to-peer blocking if you want at least give your guests a little bit of security even though it's an open network you can prevent at least a wireless client to wireless client attacking or something like that by setting the peer-to-peer blocking to drop and that's generally pretty safe on a guest network because usually no peer-to-peer stuff going on on a guest network and one last thing I've seen people do is on the radio policy sometimes they say okay guess you're only on the 2.4 radios and I reserve my 5 gigahertz radios for my corporate stuff so that's another way of preventing a guest client from messing around with your corporate stuff so now your corporate devices don't have to fight for bandwidth alongside of guests so another option that you could use for your guest clients now as we move forward with some of our technologies like up to the 11 AC that's a 5 gigahertz only technology and a lot of these newer technologies are probably only gonna be 5 gigahertz so while these new clients should be definitely backwards compatible you may or may not want to force them under the 2.4 an hour just depending on what sort of client experience you want your guests to have but it is a way to enforce separation okay so we'll go ahead and just leave it at all ok so now I should be up and running I have a guest network with a pass-through so it's just going to send me to the acceptable use page and then as long as I accept I should be up and on my way so let's kind of watch a client associating it and just see what the process is does the DHCP lease time affect the client session time out No so the DSP lease time just says how long is my DHCP lease valid for so within a given client session you know if my client sessions four hours long if the dhp leased time is you know one hour usually at the halfway mark is when they re up so that they'll read up every half hour and that's fine that's usually pretty quick and that won't force them to do you know another web redirect or anything like that because they should getting the same IP address every time so that shouldn't affect you know that redoing the web logins or anything like that so pretty independent okay so I have a client out here I can get up to it and I'm just using the anyconnect client so let's see I already had it remembered so I have our even connected so I've connected up I've got an IP address on ten ten thirteen one fifty so I'm Beale and thirteen so let's look at my client session and see where we're at so if I go to monitor clients there's my client so right now it is in this Web author required state generally the clients going to go through three different states that you could possibly see on your controller to begin with it'll connect up before it gets an IP address it will be in a DHCP required state once it pulls an IP address then it will move into this Web author acquired state now in the web author acquired state it can't do much of anything basically this is the state that you get prior to it you know fully authenticating so you know before that web redirect happens it'll be in that even after the web redirect happens but before you've logged in you stay in this web off required state now in the web bathroom quired State or the previous state until you fully authenticate there's really only two things you can do by default one you can pull an IP address so you can do DHCP stuff just fine number two we can do a dns resolution so we could resolve WWE Google comm or whatever it is as long as you learn about a DNS server you can do those DNS reservations but that's it until you actually fully authenticate you can't do anything else so in order to get the web redirect to happen then what you would do is you go to your client open up your browser and normally what you would have to do is you would have to type in a URL it has to be an HTTP page so port 80 HTTP on the HTTP won't work non port 80 stuff that won't work by default there's a couple other ports you can turn like a DAT or there's one another port that's kind of common with proxy servers but normally what we're talking about port 80 webpage then you would actually type in a resolvable DNS name so you know WWE google.com now my client is not on the internet so I can't reach out to any real web pages and I don't really have any internal web pages that I can do so if you don't have an actual DNS name you can type to trigger this web redirect the other thing you can do just for our testing purposes is type in the virtual interface IP address so for my controller my virtual interface IP is 192.168.0.1 s server you know add a minimum and possibly you know a DNS suffix for them to use and then they're going to have to reach out to some address that whatever server you taught them know so if if they're using your DNS servers your DNS servers need to resolve the IP address or if you kick them out to like Google's DNS server or some sort of public DNS server it has to be a public URL so if they try to get to their you know internal corporate web page that wouldn't work because it's not resolvable by an external DNS server so once we get the the redirect it's going to redirect to an HTTPS page and by default the cert used for the HTTPS page is just a self-signed cert so they're always going to get this web this certificate error I can kind of show you a little bit later how to try to get around you know this certificate error by installing a public cert and doing a couple other things but we'll go ahead and just go it you know step through the cert error and you'll see that the address that I was redirected to if you can read I know it's a little small on here was its HTTP colon slash slash the IP address of the virtual interface on the controller so on the controller if I look at my interfaces my virtual interface this is the IP address used for you know serving up a webpage on the controller so this is where they're getting redirected to 1/9 to 0 to 1 in my case or whatever your virtual interface IP address is going to be so normally we'll actually see the IP address in the URL by default so since I did a pass-through page I don't have to type in a username password all I have to do is hit accept once I hit accept that's the end of it now my client would move into a run state so if I go back to my client we'll see them at a still not quite through yet let's see there we go now let's refresh just took a little bit there we go now my client moved into a run state the restrictions I had before in terms of what I could talk to I've been removed and now I can talk to anything that I'm allowed to talk to on VLAN 13 so that's the client progression DSP required weboth required and then finally into a run state so you know pretty simple there I'm not controlling who can get up onto my network but I am at least forcing them to accept some sort of acceptable use policy now let's flip that over and do a web authentication instead of pass-through so sorry if I go to my W lands we'll just flip it over to web auth so layer 3 authentication okay and then all I would need to do is just bounce my client session get it back into fresh state I'll be at a web bathra quired state so let's just remove them and let's go ahead and attempt to reconnect all right might have already done it so let's check now so I have my client session back in a web auth required so let's go ahead and trigger that redirect one more time HTTP the virtual IP address otherwise you know fully resolvable DNS name I think since I still have my web browser open I don't have to suffer through that cert warning since I've already accepted it once but we'll see there we go now I need to type in my username password guest 1 was the user account that I created there we go so all those are the two different main methods we have for web you know pastor only or an actual user name pass through user name password option all right let's say I want to actually kick out my authentication out to an external radius server to do that first we're going to define our radius server so I'm going to configure a radius server under security triple a radius authentication create a new one real quick and I have an ACS server out there at ten ten to ten five and I just need to share its secret here and then on my radius server I probably have to re log in here real quick now you can create a username password on my radius server so this is a cs5 - you'd see a different interface on a cs4 or ice is a little bit different as well but the steps are going to be basically about the same we have to define our network device so who's going to reach out to us looks like I already have one in there let's create a Melo until you'll see - time ten one twelve ten so the management IP address and that shared secret create a user account to login with so let's see if I have a user okay that's for a new one called ACS guest same password let's see if this works and then just a real simple policy that's going to allow the south indication I think I should already have this in place so whoops in the access policies I should be already set to use internal authentication and I have a default rule that's going to permit so this will give me a just the generic permit that I need but on the controller side oops what we need to do is once we have our radius server here we'll just go back into the W and go to security and then we go over our Triple A servers and we'll call out the server that we want to use and then down below just make sure that the radius server is in this used for authentication list here so we see right now it's going to try local first and it's going to reach out to radius and then if I actually had LDAP servers it would reach out there so that's fine so as long as I use an account that's not on the local controller it's going to fail over to radius and then we should be good and since I have a yeah I don't have an ACS guest account here it should move over to radius so let's try to kick that off and see if that's working again we'll just remove our client session force a brand new authentication attempt happening here and we'll just give it a second to reconnect there it is again we should be in this Web author acquired state because it did pull the IP address pretty quick so now I should be able to kick off the web redirect and this time just put some different credentials in there so ACS guest see house guest submit login successful I should see now I'm in a Run State and if I really want to go over to my Abe's sorry in my ACS server and see in the logs that I had you know a radius request now by default it's going to use pap as the the protocol that's used in this authentication so just need to make sure on your whatever radio server you're using your long pap as a protocol to be used if you want to change what protocol is used on that external keep on doing that sorry external look up that would be controlled under controller and the web radius authentication you could choose chap or md5 chap as an alternative to PAP but PAP is the default and sometimes this takes a while for me if I look at my radius authentication I should see an entry for that web off attempt that I had so still we have an internal web page but we're sending that authentication attempt out to an external radius server and this would typically be done for a couple reasons you if you want to do a a per guest user credentials you could populate that onto the radius server and then that guest would be accessible on every single it doesn't matter work what controllers coming from because there they can all point to ACS or your radius server and now I only have to populate that user account in one spot and the other benefit here is if you just want you know maybe a little bit better logging he already logging radius requests and probably have a system in place for that now you can also get your guest authentications in the same place that all your internal authentications are happening as well so now you get all of your logs in the central spot so that's another benefit they can use for ACS authentications but there it is again we can see it's PAP ASCII there's the user account that I use so that's the example of external authentication and the last thing we'll show you before we give to a duel our setup would be the preauth ACL so as I said before the only thing you can do by default once you get connected up when you're on that web author require state is DHCP and DNS let's say you want to allow your guests to do additional stuff before they actually authenticate you know sometimes you might want to do this if it's if you're using your guest network as sort of a BYOD network and so maybe on the BYOD sort of guest network you would open up access you know maybe to your mail servers so that you know PDAs can at least connect up pull an IP address automatically and get email you know company email without having to do that web redirect which is a real pain in the butt on the smart phone so whatever the reason is going to be basically what we're going to do is we're going to create an ACL and apply that as a pre authentication ACL so we're going to find that our security access control lists will create a new one call it pre off and then we just need some permits so whatever we permit will be allowed before authentication anything that's not permitted will not be allowed you know pretty self-explanatory the one thing you need to keep in mind as you do a pre auth ACL is that in order for a web redirect to be triggered it actually has to hit a deny so if you just allowed all HTTP traffic you would never get a web redirect because it has to have a failure you know in a web web lookup or a web page attempt so if you need to allow some web activity just make sure you explicitly allow only the web pages that you want them to get to and then that way any other web pages would kick off the web redirect let's just say something real simple like I want to allow them to ping stuff on there or talk to stuff on their local subnet just as an example so we'll say they are on the 10 10 13 Network so if it's from the 10 10 13 Network destined to the 10 10 13 Network doesn't matter what protocol it is will permit it everything else will be denied so if I real quick or reconnect before that I can actually show you that it doesn't work and then we'll turn it on and show you that the preauth ACL kicks in so clients let's get rid of this guy force him to reallocate or reassociate and start the process over again all right so once I get an IP address okay I have I could just do something simple pull the command prompt try ping my default gateway 10 10 13 that one doesn't work that's what we would expect now let's go ahead and configure that pre-op ACL so we go into our WLAN security layer 3 and then in the pre-op ACL down here we just go ahead and specify the ACL we want to use apply all right now we'll balance our client looks like that bounced for us when I made that change okay now it's back on pre-op ACL should be in place let's see if I can ping there we go but I would not be able to ping off subnet for instance 12.1 because the pre-op ACL is denying it now if I try to go to you know trigger by your web redirect since it's hitting a deny role the redirect actually happens and with a with an ACL you never have to have an explicit deny there's always the implicit deny at the end just like a normal I OS based ACL so ACS guest is yes guest and once I do this I move to the Run State the pre-op ACL is removed and at that point I should be able to ping off subnet there we go so that's an example of using preauth ECL okay so now let's get into the dual controller scenarios where we're tunneling our guests into you know a theoretical DMZ controller so we'll pretend that WLC to the one that I've been on this whole time is our internal controller and then we'll make WLC one our DMZ controller so the technical terms for these would be the internal controllers your foreign controller and the controller that lives in your DMZ the one you're tunneling it to is referred to as your anchor controller so if you think of like a layer three roam normally once you start on controller eight and you layer three roam to controller be controller a keeps an anchor entry of the client and controller biggest the foreign entry that's where the anchor controller anchor foreign entries or names come from so rather than anchoring it on WLC to where it initially starts it's going to send that anchor entry all the way up to controller one and then controller two will have the foreign entry so the client could then roam between foreign controllers you know controller two to any other controller on the internal network just fine and that anchor entry two stays put on controller one so a few things that we need to get going with this before we can get this up and running we need that you know the internal controller and the external control are to be in each other's mobility group list so usually the first thing you watch make sure of is you want to check the mobility domain name or group name just depending on what we're you're reading this it's called domain name and the config but most people refer to it as the mobility group name you want those to be different generally because once we add these to each other's mobility groups list if they share the same mobility group name what's going to happen is the APS on controller two will learn about controller one is a potential controller to failover to if we use the same name generally you do not want your APs failing over from an internal controller to a controller in the DMZ so the way to prevent that from accidentally happening is just make sure your domain names are different between your internal controllers and your controllers in the DMZ so controller one will be my anchor controller it's named as WL see one controller 2 is internal foreign is controller 2 so they do have different names so I'm set there now add them to each other's lists so go down to mobility management mobility groups and we just have to add them on both sides so I usually like the edit all option here gives me a little easier copy paste I just need to add in the other controllers mobility group name so double you'll see two in this case and we'll apply double you'll see one okay so after a minute or two of these should move into an up status if they don't move into an up status it usually means you type something wrong you know wrong back address IP address group name or they're having communications issues if you get them into a control plane up but data pane path down most of the time that's something that goes wonky on the back end I should have to reboot the controllers to get it all that state at least in this code seven zero one one six that's what I've run into okay we have them in each other's mobility group list the next step let's get these guys using the exact same WLAN so I already have it configured on wc2 I need to get configured on WLC one now it's very important when you configure it on WL c1 as well as any other controllers are going to be working with this Auto anchor system they have to be configured as identically as possible because if there's any small setting changes even one little checkbox and one controller can break the process of tunneling that client up to the DMZ controller so typically what I'll do is I would either use something like a template from WCS or prime infrastructure or whatever management platform you're using and that's one really easy way to make sure that it's identical across the board or I just kind of have them up right next to each other and I'm just configuring at the same time and so I can reference you know page by page we're trying to be as identical as possible now there's a few things that don't have to be the same the wln ID can be different so I'll just make this different for illustrative purposes this number can be different and that'll be fine but let me get this guy up so I can just be doing some copy-paste work so that's one difference that is okay the interface that you select can be different and that's okay so I'll choose VLAN 11 on my anchor controller the dmz controller WLC to the internal controller is VLAN 13 because oftentimes you have different interfaces in the dmz then you would on the internal network so that's understandable security though everything under here is got to be the same so what are we doing we are doing web authentication I'm going to take this preauth ACL off all right looking identical there I'm going to turn off the use of the radius server although this I think this might be one one place where you can do differences where you can have different radius servers listed but all the checkboxes should absolutely be the same so we're looking to get there so QoS I believe I was under bronze again screen by screen if you're doing this on a manual process because one little checkbox can break this whole thing and on advanced so what did I do I did DCP required at a session timeout different and I believe peer-to-peer dropping blocked I'll see any discrepancies I think I'm a tentacle so we'll apply apply okay last step so I added them to each other's mobility group list I've configured the WLAN as identically as possible with just the very few limited exceptions WLAN ID interface are the two most prominent ones that you can make difference now we need to configure this tunneling so I need to configure it on both sides both the foreign and the anchor so on the foreign if I go back out to my W lands list the little blue box over onto the right side choose mobility anchors and then it's going to ask us what is the IP address of the anchor controller so I'm going to say it is 10 10 111 10 which is wireless LAN controller 1 click on mobility anchor create so this is going to say on the stubby LAN send all the stuff over to controller 1 and oh I'm in a data path down I might end up having to do a reboot we'll see what happens here because it should have come up by now all right but then we'll do the same thing on controller 1 get into that mobility anchors entry but it is the anchor switch so we choose local on the anchor controller but we need to make sure we do this on both sides because if we forget this step on the anchor controller the handoff won't happen in that u IP tunnel won't be established ok so this is up up so maybe it just was a timing thing let's check one more time real quick because it's got to be up up on both sides of the equation all right well this isn't going to work so I'll just give it we did get full up up on controller 1 so usually I see it symmetrical where if if I get into this wonky state where the data path never comes up I see the same thing on both sides of the equation so I'll point out one other thing here while I'm hopefully waiting for controller 2 to come up so before we saw when we did that web redirect it actually redirected it to the IP address of the virtual interface of the controller so if I look at my URL I got past it but it was actually HTTP colon slash slash an IP address instead of an IP address if I wanted to actually get like a DNS name in there you know guest dot your company dot-com or whatever so you're not showing them your virtual IP address you can do that it's a configuration in the virtual interface on it's going to be on the anchor controllers where it comes into play so if I go into my virtual interface I've pre-populated this because you do you're supposed to reboot it anytime you make it a change to the virtual interface so I've kind of pre done this so you don't have to suffer through a reboot but just type in the DNS host name so don't put HTTP or anything like that or slashes or anything like that it should just be a DNS name so I pre-populated guest proxy labs comm so when my client gets the redirect instead of seeing the IP address in their url bar they'll see HTTP colon slash slash guest a proctor labs comm looks a little bit nicer and this is also one of the steps required if you want to try to avoid those cert errors you have to be result you have to have a DNS name in your url because the certificate is referencing a host name and the host name is not the IP address the host name is you know should be guest at Proctor labs com in this case so in order to avoid the cert warning this is one of the things that you will have to do the other thing that you're going to have to do is to make sure that your clients can resolve guest Proctor Labs com2 the IP address of the virtual interface that's going to be another thing you're going to need to avoid the cert warning the last thing you're going to need is you need to install assert that your guest clients are going to trust and we'll get into that in just a second so let's see if this guy ever came back up nope all right well let me save config and I'm just going to reboot this guy because I've seen it just stick in this data path down forever and the only way to get out of it is a read so once I get this reblued we can start talking about few other things and then we'll start demoing the process here all right commands reboot go for it okay so while that reboots I guess if so if you want to install a cert to avoid these cert warnings on your controller you know on the back end you would have had to use something like open SSL to generate the CSR you send that CSR which is a certificate signing request out to you know Verisign or GoDaddy or thought or any of those you know already trusted third-party CAS out there and then once you get the response back to install it we're going to go back to security web off and then certificate so here we see that the default self signed certificate that was automatically installed but if we want to install our own we would just have to get the the file into some sort of a TFTP or FTP server and we check the box to download SSL certificate and we just gotta say okay where is it you know what server is serving up this SSL certificate the path to it the name and oftentimes there's a password associated with it with the cert file itself type all that stuff and it's going to snag it install it and after installs you will have to reboot the controller bolts the controller comes back up now anytime we do a web authentication web page it will use the cert that you just installed here and the cert is different from the sort used for just GUI access so you know the GUI administrative access I have here that cert is actually a totally separate cert so this sword is explicitly for web auth purposes and there's you know for a good reason because you know the web off is probably referencing this guest Proctor labs calm or guest at your company com whereas if you want to install a cert for GUI administration that would probably be based off of the actual host name of the controller so that's kind of why they separated so if you want to try to avoid those cert warnings the steps being on the virtual interface define that URL within DNS resolve the DNS name of the virtual interface to the IP address of the virtual interface and then install a web search that is generally trusted by everyone automatically so something from a Verisign or one of those trusted CA is out there if you have all those in place that should prevent the the cert warnings that are so very common on a yes Network all right what else custom web pages so if you want to install a custom web page you know we've just been using these sort of pre canned real generic e web pages hosted by the controller but if you want to your own webpage the best place to start is if you go to Cisco comm and you go to the downloads page 450-500 controller or whatever controller you want to use one of the things you can download from with and there is a web auth bundle and they've got these pre-configured web pages of lots of different styles you know some of them are web authentication some of our pass through you know this or that and then all you need to do is just take the files that they've already created and then just edit the HTML of it so just edit the text and the pictures and the look and feel of it but they've already got the backend code that's required for the actual authentication process so you know can actually authenticate a user and send the results back positive or negative or whatever it's going to be so grab that and use that as a starting point and then just tweak the visible part of the web page and then once you have that you actually have to bundle it into a tar file and then you install the tar file on the controller so to install that tar file you go to commands and we're downloading a file and it is a web off bundle and I have one already 10 10 to 10 on my WCS servers TFTP and it's called wireless tar so what's going to do is going to go ahead and download it extract it because it will have you know probably multiple files and then they become available to use for web authentication so it's grabbing it it's extracting it okay so I could then go to security web off web login page and flip myself over to just customize downloaded and now use the customize page so we can kind of see what that looks like let's see is controller to back up yet okay it's back let's see if we get our tunnel up or our mobility okay now I'm up there let's make sure we're up on controller one real quick okay so I think we should be good okay getting back to that so we we made sure that the controllers were in each other mobility group list we're in an upstate we want to probably use different group names though to prevent those ap failover options we configure the same WLAN as identically as possible with very few exceptions and then we configure the mobility anchoring on both sides of it so let's kind of see what it looks like once we're doing this okay so I should have a fresh state so let me look at the client session first so once we're doing the tunneling we're going to see the client session on both the foreign controller as well as the anchor controller so let's let's look at that and see what kind of differences are on the two different controllers so first the foreign controller this is the controller where you know the APS are at so on the foreign controller you know we see oh I didn't do that let me clear this out just make sure we're starting fresh all right so we have a fresh session here do each we should see it on okay we're seeing it on both all right so internally on okay I guess I was just miss I was just off so on the foreign controller now the foreign controllers WLAN is assigned to Beale and 13 so we see technically from the foreign controller is assigned a VLAN 13 but we're in an export for enroll so we have it sent to this clients session out to the anchor controller and we can see which anchor controller we send it out to so if we had multiple anchor controllers for you know redundancies sake or whatever it'll actually just sort of round-robin you know every new client just gets sent to the next anchor controller on the list so we can see which anchor controller we send it off to 10 10 11 10 which is controller one and we notice on the foreign controller we're already in a run state so that's one big difference you'll see so on the 4 controller you start off in a run state now what about on the anchor controller this is going to look a lot more like what we've been seeing up to this point so here we have the IP address on VLAN 11 so it pulls an IP address on whatever VLAN is assigned by the anchor controller so we see it as I'm VLAN 11 there we see it is the export anchor so it has the anchor entry but it is you know tunneling out to a foreign controller and the foreign controller is telling out to is 10 10 1 12 10 so we can see that and we are in that web off required state so this is more what we would expect to see all right let's go ahead and start the web authentication process here so now what we should expect to see here is when we redirect will redirect to a URL that says guest up rocket labs.com instead of the IP address and two we should see that custom web page so let's go ahead and hopefully we'll see that ok so it didn't like that so we do see that it used guest up proctor labs comm but I ran into this a specific purpose that I want to make sure that you understood is once we in the URL if we say you know use a DNS name instead of just the IP address we need to make sure that that DNS name actually in fact does resolve one for cert purposes if you try to avoid that but to the webpage will actually won't even come up because now it's trying to resolve guest Proctor labs comm so if I can't resolve guest stop Proctor labs calm to the virtual interface IP address the webpage won't even display so what I need to make sure I do is on my WCS over here which I happen to have up I create in my forward look up zone a new host record for guest Proctor labs comm and matched up to 192 dot 0 to 1 by virtue ups get the right IP address here so we can resolve that and the other thing that we need to make sure that we do is make sure that your your clients the guest clients actually know about a DNS server that can resolve this so this pretty much implies they have to be using your DNS servers internally you can't just be pumping them out to Google's DNS servers because Google's DNS servers won't be able to resolve this alright now that I have that done let's see if this works look I have to start over here I killed my browser as tries again okay so HTTP 1 9 2 0 1 should trigger the web redirect I'd read reticles guess proctor labs calm all rights not liking it could be a DNS you shoot here so let me just check out my client so nslookup guessed up your live.com Z&S lookups is one of those things that we should be able to do there it resolves let me try it one more time could be like a remembered failure or something like that alright let me try flush DNS you can do it now we're starting to see the interaction of lots of different things kind of possibly causing the problem but this is a little more there we go so now it's actually it was able to resolve to it once I flushed it sold DNS resolution cache I'm still getting the cert warning because I don't have you know I trusted cert installed or anything like that but I am getting the URL up there properly once a result to the virtual interface IP address the page is actually able to display and once this comes up we should see that different page which is the custom web page that I had from before and in my case it was a custom web authentication so it should be prompting for a username password and you only need to install a custom web page on the anchor controller because the anchor controller is actually serving up the web page it's the anchor controller that's not doing all the layer 3 authentication so once we get this internal external guest stuff going on all layer 2 auth happens at the foreign controller all layer 3 auth happens at the anchor controller so if you had actually like an AOL 2.1 X type network tunneling to a DMZ controller the radius request would come from the foreign controller because that's a layer 2 up anything layer 2 in foreign layer 3 anchor so now I'm getting a better page here down below I can see you know username password so I would need to make sure I actually have a username password down here so let me create one real quick just call it guest guest and then it should be all to off and I guess as long as this page was coated correctly I don't know if it is haven't rested it should authenticate up and get me into a run-run stay as long as this web page code is actually good all right so that's basic auto anchoring now a little bit troubleshooting with that if you sorry and once that now I get to that I should see on my anchor controller I'm in a run state since I successfully authenticated so the anchor goes to the normal DSP required weboth required run on the foreign controller you just pretty much right go right to a run state itself you will see a little bit of difference depending on you know which control you're looking at now if you aren't seeing the client make its way to the anchor control you see it on the foreign but you don't see on the anchor here are the things to look for one make sure that the controllers are added to each other's mobility group list so you should see the anchor on the foreign side and the foreign on the anchor side and it's made its way into an upstairs step number one number two make sure that you have W lands configured and that you have a mobility anchoring set on both sides so on the DMZ s the anchor side is set to local on the foreign side it's referencing the anchor controller in that mobility anchors list and then number three make sure your W lands are configured as identically as possible so just go screen by screen you know what's different here anything okay next screen what's different here if you go through those three things typically you're going to find the problem of why the entry isn't making its way all the way over to the anchor controller so a little bit of troubleshooting tip you can use for that all right we'll do one more feature and they'll pretty much grounded out in the naval just open up for questions if you have any so with this mobility anchoring if I had other controllers let's say I wanted to do the same thing on controller for where controller for was an internal foreign controller and anchor to controller one I could do that so let's do that I just need to just follow those steps that I just talked about make sure that you know we're in each other's mobility group list here I'm going to add 1 2 4 & 4 to 1 hopefully I don't run into that same issue on controller 4 and then I would configure the W landing controller for make sure it's identical to what's on controller 1 and pull these up real quick all right so turn it on and I'll just leave this on the management interface because America's I'm tunneling it none what policy it's good to play server should be nothing QoS at Braun's vance it should be that session timeout and peer-to-peer blocking drop all right and then compare the auto anchoring so mobility anchors controller for sends it over to controller one controller one already is set to be the local anchor so should be pretty much it now if I have clients that connect up to controller for or classic connected up to controller to when they tell the controller one it's the same SSID same wlm so they all will be pulling IP addresses on VLAN 13 is or VLAN 11 unless they actually want to have different controllers or different for controllers the guests get different IP addresses you know different subnet so you know controller to clients to get VLAN 11 and controller for clients could get VLAN 12 that's the foreign mappings configuration and you only have to do it on controller one so really all you do is on the double and you choose the foreign Maps option and then just have a mapping of controller to VLANs so you just need to figure out which controller is which because it just shows you the MAC address but if I look at controller for so it's the one that ends in six f00 okay so it's a controller for so controller for I'll put them on VLAN twelve add mapping and controller to will put them in VLAN eleven so this is going to override what you have configured just globally on the WLAN and you just keep repeat this process so for every foreign controller I could map them to unique VLAN if I really want to excuse me so now if I connect up so let's balance my client here and then just see where it falls all right let's try to reconnect here this poll is connected so I'll see if I can find it there I might have to disconnect and reconnect here okay so it's trying to pull an IP address but let's just see where it ended up so on the DMZ controller so we see it's coming from ten ten one twelve ten so it's coming from our s9 controller - I would expect that it gets placed on VLAN 11 and it takes that was where our mapping was now let's force this over do it an API controller for I'm just I'll just shut down the VLAN or the W land on controller to disable it this will force client over to controller for coming up so now on my anchor controller am i seeing it yet apologize for my sniffles here alright so here's the entry all right so it's not sending it off to the anchor controller we don't see that mobility role of a foreign so let's try to figure out what that is based off of the troubleshooting I gave first let's check the tunnel maybe the tunnel didn't come up or the mobility oh we might be running into the same issue alright so maybe I'm too quick on the trigger or maybe I'm gonna have to do that reboot again but what I would have seen was now when it comes in from controller for it would set it to VLAN 12 based off of that foreign mapping so it's a way to get clients on different subnets paying on which controllers they're coming in from on the same WLAN so that's pretty much the things I wanted to show you about guest networking any questions about guest networking or anything I didn't talk about already I mean there's there's other things you can do with guess once we start getting ice in there you can get into stuff like Central web auth and all the functionality that I Springs and that's a topic for a totally different day that's probably more of a topic for Peter our security guy but this is you know basics of guest here lots of things you can do in just kind of watching the progress happening how you're doing the different configurations and what they mean things like that so really appreciate you guys this time so definitely stay tuned for you know future sessions we have it up on our blog you should be able to find the different view lectures are going to be doing I typically do one one every month and the topics they're going to cover so appreciate your time and hopefully we'll see you next time
Info
Channel: IPexpertInc
Views: 39,075
Rating: 4.9136691 out of 5
Keywords: CCIE Wireless, CCIE Wireless Lab, iPexpert, CCIE Certification
Id: _N8C1rVjMPk
Channel Id: undefined
Length: 90min 38sec (5438 seconds)
Published: Thu Feb 27 2014
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.