The good news is that ISE is working really well for me, and (the better news for you) that I am running out of ISE-related puns. But here is a picture of Mr. Freeze anyway:
Thinking about it, from purely a lab point-of-view, the Guest portal is probably not that essential. It'll be a virtual lab, so actually testing the wifi will be difficult. However, an IP Phone connected to a laptop (or other device), now there is a viable possibility.
So, that is what we do do next.
Here is the current port configuration:
Setting up the phone was a bit tricky, it's my first time playing with a Cisco phone, so a little learning curve and lots of Googling, I got thrown off by an couple of "errors" but apparently these can be ignored. I don't need the phone to be 100%, just working enough to allow the phone to get onto the network.
Initially, I could not get it working on VLAN 21 (for the data port), but that was due to forgetting to add the necessary VIFs to SW1 and SW2 (because of the rebuild a couple of days ago). Once I had the brainwave that this was the missing component, whilst bathing the twins, and confirming this was the case, a quick fix and the correct VLAN is now being used. As a side note, UNetLab works really well on a Kindle Fire 10, and SSH works well through JuiceSSH. I have not tried VNC integration yet though.
For the phone to work, we need a few things. It needs to be pointed to a TFTP server, and this is done by adding an option in DHCP. In the DHCP server, right-click on IPv4 and select "Set Predefined Options", then click on add and add the following:
Once this is added, under the scope we add the option and point it to the TFTP server:
The VLAN VIF does need the "ip helper-address" command to point to the DHCP server, but this is it as far as DHCP goes.
The TFTP server needs a few files. Naturally we need the firmware files, and I am using 7.5.0. I did try 8.X, but whilst troubleshooting decided to downgrade (in case I was going too high).
The other files are the OS79XX file (as I am using a 7940 IP phone). This needs to have one line, which is the firmware version:
This file gets called first, then the phone looks for another couple of files. We have the SIPDefault.cnf file:
Not sure if the proxy stuff is needed, this was added for troubleshooting. The we have the phone-specific config file, which needs to be named SIPMACADDRESS.cnf, where MACADDRESS is the MAC address of the phone:
The we have the xmlDefault.cnf.xml file, not sure if this is necessary for the 7940 or not, but I have it anyway:
The phone does say thats it's still "unprovisioned", but this is related to the proxy_backup and proxy_emergency commands. This is not a show stopper, but I did send a long time chasing this one.
The phone now connects happily, as does the laptop connected to it:
Let's return to ISE and see what that tells us.
We get a green tick, but not a whole lot else. So, are we missing something?
The Live Log is rather useful here:
We can see the denied logs from the previous post, and we can also see that we do, in fact, have an endpoint profile for the phone. We have two successes though, one for MAB, which lists the phone, and one for Dot1x, which lists the workstation. This is confirmed by the switch:
So, the phone uses MAB (Mac Authentication Bypass) and the laptop uses dot1x. It's good to know that these both work as it's the only reason I bought the 3750X switch.
The cool thing is that we can confirm that naughty old Bob is hitting the right policy when using the laptop:
Still making really good headway now. ISE is pretty intuitive, most of the hard stuff is remembering what to add on the actual network devices. Most of the commands either begin with an A (aaa), R (radius) or d (dot1x). Remember this and the rest can probably be figured out through a decent bit of context-sensitive help. But do check out the post on troubleshooting ISE, as that's a real bonus in getting things to work!
We have not really pushed the boundaries though. ISE is a big product with lots of options, so what else can we do? We could do something like permit some traffic, and deny others, using a downloadable ACL.
To create a downloadable ACL we go to Policy > Policy Elements > Results >Authorization > Downloadable ACLs:
We can check the syntax as well, which is a useful feature.
We then need to turn this into something we can use, by creating an Authorization profile:
Now we should be able to attach this to the Bob-Wired-OK policy (and now I am pleased that I created this):
How does this fair?
Well, Bob can still reach the server via HTTP and HTTPS, but the dACL is being used:
Line 11022 shows that the dACL is being sent, it's just not being used by the client. Let's eliminate the phone from the equation and move the laptop to gi3/0/20:
We are definitely getting the right details, the ACL is being applied. I posted yesterday about troubleshooting ISE, so working through that I added as many of the commands as necessary, but still Bob can get to the web page. We also do not see any hits on the access list (which I changed to add the "log" option):
So, I hit the Googles again. Turns out, one of the commands I was missing (ip device tracking) was the one I needed (go figure!):
Now, while the ACL hits do not increment, we do get the desired result. We also fill in one of the blanks in the auth session output (the IP Address):
So let's move the laptop back to the phone connection, and just make sure that it still does what it is supposed to:
Bob still cannot get to the 10.1.4.101 web page by HTTP or HTTPS. I call that a success! So, what's next? What can we do with ISE? I am kinda tempted to set up the portal for guest access, but not sure if I really need to, maybe we should look at MAB instead.
Yep, let's look at MAB, but let's have a new post for that.