CCIE Wireless v3.1 Lab- Central Web Auth Guest WLANs

network dojo now we come to the final style of guest Debi lands that we might have to configure in the lab and it's probably the biggest one by far and that is central web authentication leveraging ice as the portal and policy engine for this so this is different in compared to the ones that we've talked about before where all of the policy processes are happening over on ice and the controller is configured to coordinate with it so it's a new way of doing web auth that came about I mean it's been a while now it's probably like five years or so since this is first come out but it was introduced when ice came out so ice was the first server to actually allow this type of a thing so you're never gonna see this without ice it's the the most common get solution that we saw starting in 300 of the lab because that's where the ice server was first introduced in the lab and I have a hunch we're going to continue to see this to be one of the more dominant guest options that we have potentially maybe a close second or the next one would be connect and engaged if they want to get into some more interesting CMX type stuff buys I still have a feeling this is probably gonna be the dominant one so it's the one that you want to be the most familiar with and it's also one of the more complex ones because there's a lot of moving parts when we configure this there's a lot of interactions between the controller and the ice server and so we want to make sure that we understand how all this works now this video is going to focus on the controller side of the configurations well look at the eye side of the configurations in detail in the ice series of videos and in the lab you might actually see it broken up across two separate tasks one task to configure sort of the controller side of the equation and one side to configure more the ice portal side of the configuration so again a lot of moving parts this video will focus on the controller side and we'll assume that ice is configured correctly in the ice videos we'll look at all of that stuff there so you won't miss out on anything we'll tie it all in together but as we look at the controller config there's really three pieces of config that are important there is we need to define ice as a radius server with change of authorization support or sea a support we'll talk about CoA in more in detail in the ice series of video but do know that we need to enable CoA support and it is not enabled by default number two we need a redirection HCl configured on the controller the I server is going to invoke this ACL but it must exists first on the controller and finally third there will be the WLAN configuration needed to support this so these three pieces of config every single time a very important parts of these configs and if we get any one of these three things wrong something's going to fall apart so let's work our way through this I guess before we get to the config let's actually map out how CWA works because there's a multi-step process with you know things happening on both sides so let's look at this and this is going to hopefully make it so that it you understand why we do the configs the way that we do so in one side of the equation we have the controller with ApS down below and the client connecting up to that over here we have ice as our radius server and the controllers come to use the radius server here all right as we can figure out our WLAN the only off on the security mechanism on the WLAN is Mac filtering it's an open SSID Plus Mac filtering there is nothing configured under the layer three auth tab so clients will see it as an open SSID but when they connect they have to complete a Mac off and we're going to configure the the controller to send that Mac off out to the radius server and so every auth is going to be a Mac look up on the radius server so here's the flow the client's connects up to the AP the controller then sends the number the first mac off over to the server ice will be configured to see oh this is coming in from this particular guest WLAN this is this is gonna be a central web off so it's going to respond back with two important pieces of information a URL to redirect to plus a redirection ACL name so two important pieces of information a URL to redirect the client to and a redirection a CL name to apply to the client session this is the completion of the first step of the process so client connects up we do a mock off check to the radius server the radius server responds with a URL and an ACL name at this point the client moves into a central web auth state the client is then able to pull its IP address so this happens prior to the client even essentially being allowed to pull its IP address but we complete the first off the client is then placed in a central web off pending state pulls its IP address and then the client tries to pull up a web page and it's going to get redirected to a portal on the ice server so very much like a the local web off process where the client pulls an IP address tries to go to web page gets redirected same deal it's just that happens after the initial Mac lookup so the clients going to be pulling talking to a web page on the radius server so the client will be redirected to the radius server the cut the client must complete the portal and there are a number of different types of portals that we can throw at the client and that's irrelevant as far as the controller is concerned and how the process is concerned so far you know we'll look at that in detail but for now we're just going to say the client is redirected to the portal the client then completes the portal because all that's ice stuff over there we don't show it right now we're not worrying about what type of portal is but at the end of the day they get to the end of the portal process at the end of the portal process we fire off a change of authorization request CoA request and all CoA requests says is please Rio this client okay so the controller accepts the CoA request it then sends another Mac off so this is the second Mac off the radius server then responds with a permit the client is in a run state and is up and going on the network without you know any URL or ACL restrictions so that's the process there's sort of multi steps again we're connecting up to an SSID that's an open SSID with Mac filtering turned on and it's configured to use Mac auth against a radius server first Mac off goes through the Ray server ray server responds with the redirection URL and a CL client gets up pulls its IP address tries to go to a web page is redirected to the portal on the server the client completes the portal process at the completion of the portal process the radius server sends a CoA request the controller sends a second Mac off for the same client the radius server then responds with a permit the client has completed the CWA process so as we look at the configurations needed on the controller we have the WLAN that the client is connecting to we have ice configured as a radius server that supports CoA otherwise it's going to ignore this request and we also need the redirection ACL that's going to be leveraged for this process and so that's kind of where the three parts come in the WLAN the ACL and radius with CoA support all right now we kind of have an idea of the process of central web off let's go ahead and take a look at the controller configuration the nice thing is it's the same config regardless of whatever portal is happening on the ice server that's irrelevant to the to the controller side of config it's the same config to regardless so radius server we've looked at adding radius servers before nothing special the only thing that you need to change from the default is that support for CoA is enabled because by default when you create a new server it is disabled so we do have to make sure to enable this and that's this is one of the reasons why I just turned this feature on every time unless I'm told not to but otherwise we just need the IP the shared secret correct port and CoA support easy enough number two we need that redirection ACL make sure you know how to write this in your sleep so we're going to create an ACL give it some name this name is going to be invoked in a nice policy so this is going to have to match with what you can figure i seeee to respond back with I always named mine redirect but call yours what you want so we're going to need four rules in here we need to make sure that the client can use DNS and that the client can talk to the ice portal server so it's gonna look very much like that preauth a CL they configured in the last video but let's just run through it so do we want to lock them down to using a specific DNS server or any DNS server I typically just go generic and let them talk to any data server so I just say you know at any source any destination but destination port of DNS this would be an inbound rule we need to permit and then the DNS reply back so this time DNS would be the source in an outbound rule so this allows two-way communication from the client to the DNS server and back next we need to allow communication to the ice portal server so what three I can type so this time the destination is actually the ice server five we're using TCP ice by default uses port 8 443 on it's portal and you should call that out technically you could just generically say any tcp the only problem is there that then they can pull up the management GUI of the i server you probably don't want that so this is the appropriate way to configure the portal without giving them access to managing the ice server that would be an inbound permit and then the response we always kind of write these in pairs so assignments be coming from the ice server still TCP but the source port now is 8 4 4 3 standard portal port that would be an outbound rule permit so obviously in the lab the IP will be different but know this have this memorized and you should be able to rattle it off very quickly now you might have to adapt to this maybe they want more stuff allowed prior to authentications maybe they want you to only specify a specific and DNS server that's ok but this structure here will always be there you might add more specifics to this you might add extra stuff if they ask for extra stuff but this core will always be there know this and have it memorized okay so my redirection ACL and I don't apply it to anything it just it must exist on the controller and then it will be invoked in those the the response to that initial Mac OTT that we saw so we're not gonna actually going to apply this anywhere it just must exist and it must be named the same as what the policy calls finally the Debbie land and then create a new one from scratch here so I'll call it guest 3 all right so there's going to be a few peace few key pieces of configuration on here probably need to turn it on yes assign it to an interface but on the security side it's an open SSID with Mac filtering open SSID Mac filtering nothing on layer three I says our radius server Triple A override enabled otherwise we're not going to accept the URL redirect in the the ACL name and we need to come in and say on the next date I snack otherwise it's not going to understand that we're doing CWA this allows the controller to know oh hey oh yeah we're doing CWA with the I server so I'm going to do the CWA stuff so again the important parts of this yes turn it on yes assign it to an interface but it's an open SSID with Mac filtering nothing on layer 3 Isis your radius server Tripoli override enabled ice neck that's your core they might ask you to do more and that's fine nail session timeouts DHCP address required that's just extra stuff and that's fine if they ask for that but no the core things that need to hit need to be there okay so now I have those three things I have a radius server that supports CoA I have my redirection a CL all ready to go and I have my Debby land configured correctly let's go ahead and test this out I ice is already configured for its side so we're not going to worry about that so I'm going to connect up to guess three once I finally see it do a quick repair you all right so I'm going to connect before I even pull this IP address we've already completed the first Mac off so I connect controller sends the Mac off out to the radius server the radius server responds with the URL and the redirection ACL name I am then placed on to the network and I should be able to pull my IP address so if I look at my client state oh you know what I got a bad piece of config from earlier let me let me fix this I still had a Mac entry a local Mac off entry for my client that's going to mess me up here so definitely we don't want any local entries which apologies that's from a previous video let's reconnect sorry try again all right so we connect we do the Mac lookup radius responds back with the URL the ACL name and this point I'm in a central web off state I should be able to pull my IP address this time assuming there we go let's take a look at our client state before I even move anywhere forward and I have to look in the CLI now cuz I can't use the GUI while I'm in the state even if I had management via wireless turned on but if we take a take a look here we're not fully in a run state yet let's take a look at the the detail stats here which actually area have it up here okay so as we scroll down I want to point out a couple things so one we are in a central web ah so this is different than the web off required it knows that we're doing CWA thanks to that I snack process so at Triple A with I snack we understand that we're doing central web on we see that we have an ACL called redirect applied to our session and we have the URL so these are the things that we learned from the controller or from rice we we got the URL sorry we got the the redirect ACL name we got the URL and I believe due to the formatting of the URL the controller was able to deduce that we're doing central web ah okay so that's where we're at now at the completion of the first mac off check i've also pulled my IP address now i should be able to try to go to a web page and get redirected to the ice server so note by default it is redirecting me to the dns name of the eye server on port 80 443 so make sure that your client knows dns and now I'm on the portal so this is the part where I complete the portal so this is all ice stuff so the controller is just waiting sitting around so I just need to to complete the portal so I'm gonna log in continue okay so I this page is the completion of the portal process at the completion of the portal process I sends the CEO a request the controller responds to that sends a new Mac off look up to the ice server I server then responds back with a permit and now I should be in a run State so if I look at my client state now I should be in a run state in the ACL and you redirection URL have been removed so here we go I'm in a Run State I no longer have an ACL applied and I no longer have a URL redirection I'm fully complete and up and running on the network now so that's what we're going to see through the course of this process if I look at ice and take a look at the ice logs we'll see all those steps that I talked about so again a lot of moving parts and we haven't even looked at the moving parts on the ice side of the configuration we're only looking at the controller so far so on the ice section of the videos we'll definitely see all the ice parts that need to be working but here we go so we have this should be the first one so here is the first off it is a Mac based off so it's going to be a Mac look up so we just based it off of the MAC address ice was configured as such to understand what's going on and it sent back this Cisco AV pair to say okay apply a redirection ACL called redirect and apply this URL URL redirect that gave us what we need client pull this IP address was redirected to the ice server as I went through the portal process I had to put that username password into the portal that's this entry right here so this is the validation of the credentials that I supplied in the ice portal itself so it knows that I put in this username and it validated the password and said oh yep we completed the portal authentication the next entry is the CoA request here so we don't see in a user name but if we look at the details I completed the portal I sent a CoA request and so if you ever see the word dynamic authorization translate that to Co a change of authenticate change of authorization so dynamic authorization succeeded this is the CoA request and then we got the second Mac look up inside of here and so we see so we're hitting the mAb rule which was a Mac base look up we are seeing that the user name associated with this overall process which can kind of muddy the waters was this a user off look up was it a Mac off look up it was the Mac check is what it was but it's the second one inside of here and so at the end of the day it just sent back a general permit so permit access is why it sent this got us into our full run State so you can see the step by step in the logs of the overall process that we called out with inside here all of those configurations important in making the various steps of this process work so if you haven't practiced CWA much probably want to review this a few times it's definitely very common in the lab it's going to be something that you want to make sure that you understand how to make work now I won't actually make it work in the anchoring scenario let's talk about this in an anchoring scenario are there any special caveats to know if we are anchoring a guest WLAN and it's a CWA based WLAN so the normal anchor config applies so you know we need the WLAN and both the foreign and the anchor controller we need to make sure mobility group memberships are up we need to make sure that the double ends are configured identically for each other all the normal anchoring type stuff that we talked about in the anchoring video but a couple things to keep in mind where is the auth coming from who's talking to the radius server well if you remember the anchoring video layer two auth comes from the foreign controller layer three off comes from the anchor controller what type of authentication is this well it's a layer two off when we look at the double and what did we turn on we turned on Mac filtering that's a layer two off we didn't turn anything on on the layer three tab and so it's the foreign controller that would be the one communicating to the ice server where does the where as the ACL need to be applied that redirection ACL where does it need to exist the answer is on both controllers it must exist on the foreign controller and it must exist on the anchor controller because that's the anchor controller that applies that because the anchor controllers one dropping it off onto the wired network so all ACL work is enforced on the anchor controller but in order for the anchor controller to get it the foreign controller is actually becomes sort of a middleman for the anchor controller which is applying policy but the foreign controller is the one talking to the ice server and so the the four controller sends the Mac look up to the eye server the eye server sends the the URL and the ACL name to the foreign control of the four controller then forwards that information up to the anchor controller it will not forward the ACL name to the anchor controller if the foreign controller doesn't also have the ACL configured now quick time-saving tip you don't actually have to configure any rules on the foreign controller you could just have an ACL called redirect no rules on the foreign controller create the redirect ACL on the anchor controller with all the rules and everything would work just fine but if you want to be do extra work you could put the rules on both the foreign and the anchor does the anchor controller need to have ice configured as a radius server not really because it's not directly talking to the ice server so as you configure the W lands yeah I mean it doesn't hurt to configure ice as a radius server on the anchor controller and call a down on the W and you don't have to but it doesn't hurt either but those would be the important parts make sure that the redirection ACL exists on both the foreign and the inker it's the anchor rules that that apply though the foreign rules are irrelevant the foreign controller is the one talking to the controller because this is a layer two based authentication and then on top of that all the normal anchoring stuff is also required as well so anchoring very common in the guest style WLAN so make sure that you practices both standalone as well as in an anchoring scenario

Channel: Network Dojo

Views: 1,113

Keywords:

Id: JM4iYuABAC4

Length: 26min 0sec (1560 seconds)

Published: Tue Jan 08 2019