Mobility Conductor VRRP

Now that I’m done fooling around with windows and VMware and everything else I don’t really focus on, it’s time to get to something I DO focus on. Aruba environments! Starting with VRRP…

Building redundancy between 2 Mobility Conductors is done using VRRP(Virtual Router Redundancy Protocol) (https://tools.ietf.org/html/rfc3768). This is the first step of setting up the Redundant Mobility Conductor. Configuration is quite simple, and it shouldn’t take any time at all to get things up and running between the 2 conductors as long as your L2 segments are complete and communicating. To complete configuration, you’ll need 1 additional IP address in the same VLAN as both conductors.

Here is a snippet of the configuration I’ve used on my devices:

vrrp 30
priority 120
authentication fecifi
ip address 10.1.10.30
description "Primary-MC1"
vlan 1
preempt delay 60
advertise 5
no shutdown
!

I’ll go through these line by line to explain what they are.

  • VRRP 30
    • This sets up the VRRP instance on the MC. There are a couple things to remember regarding this protocol:
      • VRRP is a L2 protocol. No routing involved and it will never leave the VLAN.
      • VRRP will broadcast. This means that if you accidentally have two different instances of VRRP on a single VLAN using the same number, they will hear each other and it could cause big issues. To be sure you don’t pick a VRRP ID that is already in use, you could put a packet capturing device on the VLAN and listen for VRRP packets. Each packet will list the VRRP ID, authentication, and Priority; among other things. I’ve included a pic at the bottom.
  • Priority 120
    • This is the device priority. The higher this number, the more priority will be given to the device. The range available is 1-250. I typical put my main device at priority 240, and then count backwards by 10 from there. Probably overkill, but it makes sense in my brain and I’ve used it for a while. By using 240, I know that there won’t be any default devices that accidentally take over (default is 120). Also, if I need to change the top priority device for some reason, there is wiggle room at the end of the range. The redundant MC will have priority 230.
  • Authentication fecifi
    • Pretty self explanatory. This is the key that stops other devices from accidentally joining the instance. It is not a secure key and it is not masked in the configuration with stars(******). Although this is an optional field, I highly recommend you always use it. A few years ago while I was breezing through the configuration of some new controllers, we accidentally used the same VRRP ID and ended up causing problems with the production controller cluster. Not a happy place to be in the middle of a warehouse shift!
  • IP address 10.1.10.30
    • This is the virtual IP address of the protocol. It is the 3rd address mentioned above for VRRP and is configured the same on both devices. No subnet needed because it’s L2 only!
  • Description “Primary-MC”
    • Just a description of the configuration. I normally put the desired device priority.
  • VLAN 1
    • This is the VLAN that VRRP is going to run on. This needs to be the same on both conductors.
  • Preempt delay 60
    • Preemption is the act of failing back to the primary device after a failover. For the MC, this is not really important. If you are accessing using the VRRP address and your database is synchronizing properly, it shouldn’t matter which physical server you are on. However, the delay is mentioned during the AMST course, so I wanted to add it for the sake of getting used to configuring it. I don’t believe Aruba recommends it as a configuration piece. The delay setting is in seconds.
  • advertise 5
    • This is the advertisement delay for the VRRP broadcasts. You can see this in the packet capture below as well. Each broadcast is roughly 5.01 seconds apart. The default setting for VRRP hello advertisements is 1 second.
  • no shut
    • Quite obvious….bringing the interface “up”.

Packet capture:

VRRP packets captured on Wireshark

On the redundant MC, the configuration is almost the same:

vrrp 30 (same number)
priority 230 (Lower than the primary)
authentication fecifi (same key)
ip address 10.1.10.30 (shared virtual address)
description "Secondary-MC2" (description of secondary device)
VLAN 1 (shared VLAN)
preempt delay 60 (do not fall back for 60 seconds)
advertise 5 (advertising interval)
no shutdown (bring the vrrp interface up)
! (exit)

That sums it up for the configuration. We can then check the stats out using the “Show vrrp” command. If you have multiple instances, just specify the number at the end:

show vrrp 30

Virtual Router 30:
Description Primary-MC1
Admin State UP, VR State MASTER
IP Address 10.1.10.30, MAC Address 00:00:5e:00:01:1e, vlan 1
Priority 120, Advertisement 5 sec, Preemption Enable Delay 60
Auth type PASSWORD, Auth data:
tracking is not enabled

Final Notes

  • Be sure that your clock is set on both devices. If there are off, the VRRP instance won’t be established.
  • VMware network interfaces must allow Promiscuous Mode and Forged Transmits for VRRP to work. The conductors will not come up if those two settings are off.

For troubleshooting, the following commands can be run on the conductor level:

  • logging system process vrrp subcat all level debugging
  • logging system process vrrp level debugging
  • logging network process flaps level debugging

Now, get to labbing!

‘Till next time…

Getting To Work!

Here I am again with the latest “learn VMware and server stuff from the guy who knows nothing” update…

Lots of things happened since I published my last snippet, which actually sat on my computer for a week before copying it over. Sure would be nice if I could just SSH into WordPress and upload my stuff that way. I got stuck on some new interface with blocks and crap. Formatting wouldn’t work….”aint nobody got time for that!” 

Whatever, it got published and here I am trying out Word to see if I could pre-plan some pics and dreading my next upload…back to the “lots of things” thread…

            The problem I was having with VMware reverting itself went unresolved. I came back from a work trip and discovered that it had yet again rebooted and reconfigured itself after I put all of 15 minutes into copying over 8 new VMs for Aruba stuff. So I took it over to my boss’s house one morning since he is the VMware “guru” of our organization to sort it out. As it turns out, the SD card in my server was hosed. That’s why it was taking 25 minutes of booting to get anything done. Popped that thing out and boot time shrunk to about 6 minutes. Glory. We reloaded VMware onto 4 new SAS drives that he had lying around and we were up and running. I added the other 2 SATA drives that I had purchased as well and there was no issues with mixing the two, so now I’m good to go with drive space. Looking forward to getting into the real stuff soon.

Since VMWare is now working, I went and pull an ISO of Windows 2019 server. This will be doing all sorts of clever things like NTP, RADIUS auth, DHCP, and DNS. All those seem pretty trivial (and there are plenty of tutorials on that already) so I’m not going to go through it all in my blog. I’m here for the ‘Rubas!

Windows 2019 link: https://www.microsoft.com/en-US/evalcenter/evaluate-windows-server-2019?filetype=ISO

Make sure you get the desktop version. If you don’t need the desktop version because you are some datacenter CLI guru, why are you still reading this?

On to some other OVAs…

As I mentioned at the start, for an almost complete lab environment you’ll need to get the following at asp.arubanetworks.com :

  • Mobility Conductor OVA (2 installs)
  • Virtual Controller OVA (3 installs)
  • Airwave ISO (more on that in a second) (single)
  • Clearpass is optional although they use it for RADIUS auth. I’ll grab it eventually, but for now I’m just going to auth through 2019.

I decided to use version 8.7 for the lab. 8.8 is out but I think the requirement for ACMX is only 8.3 or so. Hopefully, I won’t be too advanced or elite for them when I take the test, lol. 

Before I start installing OVA files, there is 1 configuration snippet that you should do in VMware. We need to configure vSwitches because it asks which one you want to use in the wizard. You can change it afterwards, but I think it’d be easier to create them first.

Network Setup!

First, to identify which physical port is where on my server, we plug in an active ethernet cable into each network port and mark them accordingly:

While hanging out with my boss, he mentioned that sometimes VMware will number the ports in a weird fashion. This is why you check this first. 

Now that they are identified, lets created a few switches. I need 3 vlans. I’d prefer 10, 20, and 30, but I didn’t feel like dealing with wondering where VMware itself was going to end up and I had already tagged myself out of access at one point, so I just left it at the default vlan and tagged everything at the switch.

Click on the Virtual switches tab under Networking:

I just named them vSwitch(0,1,2,3) and associated them with the physical port number. 

Next, I went to “Port Groups” and created a port group for each VLAN that I need, which ended up as 1, 20, and 30. (VM Network is vlan 1. After my first run-through with the entire lab, I’ll configure the tagging correctly. For now, I just want to get started as quickly as possible.)

Keep in mind that the VLAN tag for each of these is 0. This is because I’m going to send the traffic untagged to the physical switch and I have access ports setup on the switch to tag the traffic for me. Depending on how you setup your environment, this may be different.

Lastly, the only security configuration that needs to be done is the Promiscuous Mode and Forged Transmits under the vSwitch network interface security settings. Without these enabled, L2 functionality is limited and VRRP will not work:

OVA installation!

Installing the OVAs is about the simplest thing you can do in this entire project. 

Just click this little button here and run through the wizard:

Here is the final layout of my VMs:

Aruba-CX is the OS for their new switches. Just playing around with it. I like it so far.

The OVA files will automatically choose the RAM, CPU, and Drive space needed. I left every option on the wizard default except choosing the network interface each will be using.

Airwave and Windows were installed as ISO files. I’ll go into that on the next round.

‘Till next time…

Resurrecting My Server

SO!
 
As mentioned in my last post, I have this reclaimed server from my datacenter (DL360 Gen9). I also mentioned (I think) that I touch a server about once a year, so this is very quickly going to become a circus. You’ve been warned. All the hard drives in the server were removed but the configuration was left. Since all the configuration is there, I have 16 VMs registered, 18 Networking….things, all kinds of firewall crap, and no storage.
 
At first, I went through and unregistered all the VMs. Then I went and removed all the networking instances except the VMware mgmt interface. Clean slate, right? Wrong. I rebooted and they all came back. Then I booted the server (each time take 20 minutes for some reason) and found a configuration option where I could set VMware to all the default settings and start from scratch. What. A. Godsend! Right?  Nope. Still reverted back. So then I gave up and moved over to my other problem…
 
That problem was getting the drives installed. After consulting with a friend, I picked up 2 sata 3 SSD drives from micro center and swapped them out on the cradles that the old drives were installed in. Popped them in and they lit up, but never really did anything. They also don’t show up in VMware as available storage. With this, I assumed that I needed to go into the server settings at boot and designate them as new storage -probably by adding them to a RAID controller or something.

I rebooted the server and went into the system settings via F9. In here, I selected the RAID controller and then “Exit and launch HP Smart Storage Administrator”. The screen goes blank, and then “Welcome to Grub!” Shows up. Then nothing…for at least 15 minutes.
 
While exercising my lack of patience I started troubleshooting that problem through several other avenues. I looked into reinstalling the server tools, reinstalling the boot loader, etc. I even “phoned a (different) friend” and he said that the SATA drives wouldn’t work with the SAS controller that was in the server. There was a list of things I was going to have to do to get them running, or I’d be going to Newegg to buying some SAS drives. Luckily, I was smart enough to say “Well, whatever, I’ll just let it sit there.” I should have taken the hint when I noticed that it took 20 minutes for the server to boot up and load all the drivers. I came back from a trip to get the kids new bikes, and there was the RAID screen, all ready for me to provision! With a few clicks, I was up and running in no time at all. Success!
 
While I was troubleshooting all this hard drive non-sense, I downloaded the following VMs in preparation for my new environment:
•Aruba Mobility Conductor 8.7.1.1
•Aruba VMC 8.7.1.1
•Aruba Airwave 8.x
•Windows Server 2019 – 180 day evaluation can be renewed 6 times from what I read.
 
At some point, I’ll also need to download a Win10 desktop for testing. 
 
Next I might be setting each of these VMs up on ESXi(6.0) and fixing the networking settings depending on what happens with this configuration issue.
 
Also, comments are always welcome. Please ask questions and share knowledge!
 
 
‘Till next time… 

ACMXing at home

ACMX labbing at home!

Changing directions a little bit for my blog as I’m now able to build a lab and begin studying for my AOS8 ACMX exam. I’ve been to 2 troubleshooting courses (version 6 and 8) as well as being an Aruba Edge Professional for 3-4 years. Now that I’m able to devote time to it, I wanted to explain my lab setup, problems I had, and tips I find along the way. I’ll also be documenting each step of the lab (referencing my training books) to further increase knowledge and share with my fellow engineers.

Last year, I had submitted a proposal to get myself and another engineer the necessary equipment to setup a lab at our homes. Unfortunately, this quote came out to around $28k or something ridiculous. There were definitely some perks involved -things that were “nice to have”- and a decent amount of hardware such as wireless cards, phones for VOIP, Cisco crap, etc. Once that got rejected because of cost (of course) we moved on.

This year, I’ve been much less busy with travel so I could devote more time to training and building this lab again so I took it a different direction and decided to price something out that would get the job done for the least possible cost. After speaking with my Aruba rep, this was able to come up with. 

Here are the items necessary for a full ACMX lab:

  • (2) Mobility Conductors
  • (2-3) Controllers (you could split your cluster to tackle Multi-tenant when needed reducing this to (2)
  • (2-3) APs – Model doesn’t matter as long as they are AOS8 supported on the version you are running. One needs to have “Instant” Functionality. Shouldn’t be a problem with AOS8 8.6 or later.
  • (1) Switch
  • (1) Windows server with AD, DHCP, DNS, RADIUS, NTP
  • (1) Clearpass (somewhat optional)
  • (1) Airwave server
  • (1) Skype Server – Haven’t investigated integrating this into a home lab yet.

Total cost: A bajillion dollars

Items needed after converting to “low cost home lab”:

  • A VMWare server capable of running:
    • (2) Mobility Conductors
    • (2/3) Virtual Controllers
    • (1) Airwave Server
    • (1) Windows Server
    • (1) Clearpass Server
    • (1) Skype server (?)
  • A Switch
  • (3) Access Points (1 instant capable)

As I progress and review my training manuals, I’m going to see if the switch is actually necessary. I have 4 ethernet ports on the back of the server and if I can get my power injector to power the APs, it may not be necessary at all.

Total Cost: It depends!  ©Sam Clements inc.

My employer had just swapped out a few servers in our datacenter for better ones. While being in the right place at the right time, I was able to snag a DL360 Gen9 server with 2 CPUs/28 cores and 256 RAM. This was quite a steal at 0 dollars. My Aruba rep was able to mail me an old switch that was not being used anymore due to them upgrading his lab environment to Aruba-CX models. I had 3 APs lying around my house from various giveaways and previous jobs. 

So, all this ended costing about 300 bucks. This was because the server needed 2 new hard drives, I had to pickup an old monitor, keyboard, and mouse to work with the server. And of course a VGA cable because at some point all the crap you’ve thrown away over your entire networking career is going to come back to haunt you. (Walmart to the rescue.)

To keep these short and segregated, I’ll wrap this up here. Next, I’ll discuss the crap I had to go through to get my VMware server working properly.

Till next time…

Beacon placement tool

Installing and running the largest single location Meridian installation (7.2 million sq. ft.) in the world is fairly straight forward. It just requires a lot of walking…and a lot of placing. Through that site we learned some tricks for deployment. But my most recently created tool for beacon deployment was invented at our most recent deployment (probably the second largest in the world at 6 million).

Since our initial largest deployment, some best practices of beacon placement have changed. First, running a hallway was done by alternating sides of the hallway at 30ft (minimum). Elevator and open area placements were also tweaked, but it was the hallway one that prompted this tool.

The new best practice for hallway deployment of beacons is to line them down the middle of the ceiling at ~25 ft. This is so your client doesn’t bounce right and left as they navigate down the hall.

This changed things for us because the tool that I had previously created was made for applying pressure to a wall and not a ceiling. Because of the wall placement, we needed a 90 degree bend at the end for horizontal pressure. I made this tool out of a paint pole (for placing out of reach) and a drywall sanding attachment. It has a universal joint attached to a sandpaper mount for sanding drywall mud after it’s dry -giving you that nice smooth texture. Through some cutting and taping, I was able to modify that tool for the purpose of placing beacons. Worked great. But then the specs changed, and now I need vertical pressure.

So, on to it!

We had tried sticky tape to hold the beacon onto the tip of the pain pole but we couldn’t get easy controller of the stickiness. The beacon would either fall off, or the tape would be too sticky and it would pull the front of the beacon off as we were pulling down. Deal with that at 12 ft in the air. Not fun. Then the tape would wear out and we’d have to change it. PITA.

Our solution was simple. I can’t take all the credit for it. Most goes to my boss David for the idea, but I built it this morning and that credit is MINE.


This is a lightbulb changer. You’ve probably seen them. You stick in on a paint pole to change the light bulb in that fixture that is 35 ft up on the ceiling. You know the one. It’s got cob webs all over it and it’s ugly, white, and  probably from the 90’s. I almost changed one once when I was 13. I was able to scale the staircase walls like Splinter Cell, but when I got half-way up, I lost my nerve and decided I didn’t want to die that day. My mom is probably grateful.

13 year old Joey being awesome



This grips the beacon great, but because it’s so deep, we needed a stop block. There is a hole in the bottom of the changer, so we ran to Lowes and grabbed a few of these 1/4 x 4.5 inch bolts.


I put the changer and paint pole together and drilled out the middle using a 13/64th drip bit so the bolt would have something to grab. When the changer is on the paint pole, you can drill the perfect hole into the end of it with the assistance of the changer that already has a hole. Then I screwed the bolt into the hole until it was about a half inch deeper than the end of the changer.

This keeps the beacon from being able to move too far into the changer where it wouldn’t be able to stick to the ceiling.

 

Now, we just put a piece of double sided tape (NEVER use their included tape)  on the beacon and place it on the ceiling…

 

DONE SON! No tape to replace. No beacons to reassemble after they fall on the ground and bust into 4 pieces. Just stick, place, and move on. Hope this helps!

…till next time!

Basic Training

An introduction to wireless for uneducated users. For installations into small environments…

I recently came into a situation where I realized that there were a lot of small office deployments happening at another office. The engineers at that office had no formal training in wireless and barely knew there was a 2.4 and 5Ghz range. This blog is directed towards training brand new users on deploying wireless into small office situations with minimal formal education. (As in wireless training…not…high schoolers) -Also as cheaply as possible using tools they already have access to.

*This is by no means training for wireless experts or a how-to for designing enterprise environments. This is merely a write-up with the premise of “Something is better than nothing!” As most of us wireless engineers know, these are the complete basics of a decent wireless network, and tuning these parameters to the best of our ability can do loads for a crappy environment. 

Education

The first step in setting up a halfway decent wireless environment is knowing what could cause a bad environment. Here are the main educational bullet points for creating a general access network that should work:

  • Channels. Each AP needs to be on a different channel. There are 25 channels to choose from in 5Ghz, and three in 2.4: 1, 6, and 11. This is because of interference. Since wireless is a shared medium -like a walkie talkie, we need to keep this separation in order to have proper communication.
  • Channel Widths. In 80% of the environments, 20Mhz is going to be the channel width you want to use. As stated in the previous bullet, interference is again the reasoning behind this. Channels can be bonded at 20, 40, 80, and 160Mhz. I mentioned that 5Ghz had 25 channels. At 40Mhz, that is reduced to 12; 80Mhz -6; and 160Mhz -2. 40Mhz can be used occasional in certain remote offices but most of the time, neighbors ruin that for us. 
    • NEVER use 80 or 160Mhz channels in business environments. There are rare occasions where you could get away with it, but in general, just don’t.
    • You will probably have to change all of these settings. AP marketing departments have apparently talked engineering and product managers to make this the default setting with every single vendor I’ve ever worked with. It’s stupid, but good to know about.
  • Power. For the past 20 years or so, wifi has been coddled like it is this little Tweety bird. Engineers that haven’t been educated in wireless think its so small and innocent. That it needs help to get through walls. It needs to be petted and held like a little kitten. THIS IS FALSE. Wi-Fi is a Tasmanian devil. If you don’t control it by reducing power and controlling it with walls and antennas, it will wreak havoc on your environment faster than a monkey with a pile of dog squeeze. 

WiFiTruth.jpg

  • Signal. Signal is of course the most popular if wifi lingo. This is the strength of wireless network according to the client devices. You can measure strength with all kinds of programs but the best measurement of strength is going to come from the end-user device. Every device is different (even if its the same model) and no matter what your professional testing computer says, if the client has crappy signal, it’s going to have crappy performance. Statistics are useless if the end-user can’t connect!

Tools

Now that we’ve got a little guide of what to look for, how do we look at it? The tool you’ll be looking for is called a Wi-Fi network discovery tool. Depending on the vendor, most of these programs will tell you the SSID, the channel, signal strength, and sometimes the channel width of all the SSIDs it can hear. You’ll be using these tools to figure out what RF configuration, and where your APs should be placed. Why are you using a discovery tool? Because most of the time they are free!

Ideally with this information and a couple of tools you would be able to do some basic tests and give the customer a decent wireless environment. This can be accomplished by using a laptop, tablet, phone, or anything they can use the following tools.

Access Points

Choosing an access point for a small office environment should be fairly easy…as long as you have a good budget for it. Will a Linksys from Walmart work? IT DEPENDS! Do you sit at home alone in your office and work on your laptop, phone, and tablet? Then, yes, the Linksys should be fine. Check a couple different home routers at your local store or Amazon and check reviews at different technology suppliers as well. NewEgg, Microcenter, Frys, and Amazon all have reviews. While it’s always good to look at reviews, you have to take them with a grain of salt as well. Some people just don’t know what they are doing. When their deployment strategy doesn’t work, they blame it on the device and move along to the next one. For a small business that is going to support multiple devices with multiple employees, I’d suggest upgrading your product samples to a SMB grade access point or router. Ubiquiti has a great selection of APs that perform very well for smaller environments. You could also check out some Aruba or Cisco APs that are designed to work without a controller.

Where does this thing go?!

Typically these should go as close to the location that wifi will be used as possible. Sometimes that isn’t possible, but there are a couple best practices that will help. 

  • The AP should always be placed in the recommended orientation. either hung on the ceiling or wall, or placed on a table.
  • Don’t place APs near or inside any metal boxes. Signal degradation will vary depending on the type of metal and box it is, so it’s best to just stay away from them. There is also refraction, reflection, diffraction…T.M.I.   It’s really best to stay away from all boxes, but metal is usually the worst.
  • Some access points come with antennas. These are typically what we call a rubber duck antenna. The signal propagates from the sides of this antenna like a donut. Therefore, if your coverage area is around the AP, the antenna should be straight up and down. All antennas should be in the same orientation.

If you have to put the AP in an area away from the where people are working, you’ll have to be sure that you are getting a signal close to -67dBm from the devices that are being used. Most standard phones, computers, and tablets are capable of telling you this information. Also, any of the discovery tools mentioned above will tell you this info as well.

That’s actually pretty much it. When you set your access point up, you’ll probably need to go into the advanced settings to access most of these features. Again, around 99.999% of all APs and routers come with unrecommended settings enabled by default. Google can be your friend. Use the wireless network discovery tool to see which channels are “audible” to your device at the location. Pick the channels with the lowest signal to put your AP on. If you see 2 channels next to each other that a clear, you could probably enable 40Mhz bonding. If you are in a downtown environment, you may just have to do some trial and error. Regardless, people still have wireless in the middle of the city. It’s not that it won’t work, it’s just that you may get some slower speeds and the occasional disconnect.

As always, comments and questions are always welcome! I’d love to hear your opinion on 80Mhz channels. I’ve heard quite a few engineers say NEVER use them no matter what, others say “it depends”! What do you say?

 

…till next time!

Hidden SSIDs

Almost live from WLANPros Phoenix 2019!

I’m taking a great class at the WLANPros bootcamp this weekend: Wireless Penetration Testing with Phil Morgan. We’ve seen tons of info already about hacking testing wifi. On day 1 we basically got to know a couple basic Linux command, sat through (6) separate slides about the legalities of what we are about to learn, plus an oath of intent/responsibilty, and then finally spent some time using Aircrack to do some things.

I’ve always been awed by security related activities but I’ve never really gotten into it. There’s much more to come but the one thing I enjoyed today was learning how to find the name of the hidden SSIDs that uneducated security officers love to use as security features in their networks…specifically healthcare. I’m currently on my 3rd hospital deployment where I’ve heard the dreaded “We are going to hide all the networks except guest because it’s better if people don’t see them!” 

Well, actually it’s not, and as I learned today, it’s quite easy to figure out with just a few simple commands and some patience. By hiding the SSID, you’re just peaking the interest of some shady characters and possibly dumb teenagers. Nobody else is really going to care…

And since I was paying attention during the 30 minute talk on responsibility, let’s go ahead and mention now that I’m not responsible for any trouble you get yourself into by using this blog as a guide. This is for educational purposes only!

Let’s get into it…

We are using our brand new Kali linux chromebooks which are preloaded with all kinds of proven security/penetration tools to help you get where you shouldn’t. One of these tools is the Aircrack-ng suite. 

Aircrack-ng suite has several different tools included in it that can do different things. Here is a very basic rundown:

  • Airmon-ng  – configures an interface in monitor mode
  • Airodump-ng – displays active wireless SSIDs, APs, and client information. 
  • Aircrack-ng – is for key cracking
  • Aireplay-ng – is for packet injection
  • Airbase-ng – does all kinds of things including acting as an AP, capturing handshakes and simulating different attacks on clients.
  • Airdecap-ng – decrypts packets

This is nowhere close to a complete list. You can find loads more info on the suite here: https://www.aircrack-ng.org

To find the hidden SSIDs I mentioned above, we are going to use Airmon-ng and Airodump-ng.

To start out, you’ll need to be sure you have some supported wlan adapters. The onboard adapter does work, but supplied with our Chromebooks were 2 panda wireless adapters that natively support promiscuous mode. I’ll be using one of those for this task.

To turn one of those into a monitor, first run LSUSB(lowercase) to make sure Kali has detected the device:

LSUSB.jpg

If you see the USB drives in this output (Ralink Technology in this pic) Lets run one more command to confirm they are now wireless interfaces:

IWCONFIG.jpg

Now that we know the devices have been detected, lets put one in monitor mode:

airmon-ng start wlan1

When you start the device in monitor mode, it changes the name of the device to wlan1mon:

IWCONFIG.jpg

With that change, we also have to change the next command a little. Since we’ve changed it to monitor mode, the only step left is to start looking at some data:

airodump wlan1mon

Once we run this, we’ll end up on a scanning screen that is going to show us various info about the networks and clients we hear. 

AIRODUMP.jpg

Here we see the networks that are broadcasting, and below, the clients that are probing. You’ll notice in the output of the networks that there are a couple that are listed as <length:  0>. These are hidden networks. Now that we see them, we can mark them to keep track of them while we wait. Depending on the amount of users connecting to this network, this could take seconds or hours. 

Press “Tab” to bring up a highlight. Now that it’s highlighted, we can use the M key to change the color of the text for the line.  Use your arrow keys to highlight every “Length” line and press M to cycle through the 6 colors available. Change each Length line to a different color. 

If you noticed, when you highlight certain lines, client lines highlight as well. These are clients that are connected to the SSID that is highlighted. To figure out what the names are, we only have to wait for a client to attempt an authentication to one of these networks. Automagically, the network name will appear:

DMPHIGHLIGHT.jpg

Success! The highlighted hhonors network was previously “length: 0”. I’m not sure why we are seeing this instance as hidden and the other network we’re not. But with wifi here isn’t exactly the best… unless of course someone was causing trouble. IT WAS NOT ME.  The other two networks eventually resolved as clients connected but I took this pic too early.

…til next time..

On to day 2!

WPA Passphrase with Special Characters

Wow. It has been a while, but I wanted to post this quick snippet about getting an Aruba controller to take special characters in the passphrase. The only info I could find while we were troubleshooting was that special characters are not supported and the controllers wouldn’t take them. Well, FEAR NOT! After troubleshooting and failing with TAC, I successfully made it happen…after TAC said “you can’t do it.”

Here is the scenario. I have a customer that has been using a different wireless vendor for a long time and their current key for production is a long passphrase with different special characters in place. Here is an example key:

oQ|ienU6ra+K-8/KQU1AU3Y1{Aly?QNU-,gFZYP”

While I was configuring their new controller, I ran into an issue when applying this key. I would get to the question mark and the controller would act like I was asking for CLI help. It would skip to the next line, and then paste the rest of the key in -without the “?”. When using the GUI, the controller would take the key; but if you went into the CLI with “encrypt disable” and viewed the key, the “?” was gone. I tried several other methods before the customer requested a TAC call. As you can imagine, typing this into wireless terminals is not fun. I’m not sure if this procedure will apply to other special characters, but here is what I did to get it to accept the question mark and quotes in the key:

  1. Copy the beginning portion of the key before the “?” and paste it into the controller (don’t hit enter).
  2. Add quotes to the beginning and end of the text you entered.
  3. Using arrows, move the cursor to right before the end quote.
  4. Paste the rest of the key in before the quote.
  5. Press enter and the controller will take the entire string as is.

*Side note: If you are using quotes in your key, you have to use apostrophes instead of quotes to enter it correctly. I followed this procedure with the quotes and it still did not work. Replacing the quotes with apostrophes resolved it.

Here is the actual command procedure:

Aruba#config t

Aruba(config)# wlan SSID-profile test-ssid_profile

Aruba(config)# wpa-passphrase oQ|ienU6ra+K-8/KQU1AU3Y1{Aly

Aruba(config)# wpa-passphrase "oQ|ienU6ra+K-8/KQU1AU3Y1{Aly" <-add quotes.

Aruba(config)# wpa-passphrase "oQ|ienU6ra+K-8/KQU1AU3Y1{Aly?QNU-,gFZYP"" <-paste the rest of the password.

Aruba(config)# wpa-passphrase 'oQ|ienU6ra+K-8/KQU1AU3Y1{Aly?QNU-,gFZYP"' <-replace quotes with apostrophes.

Thats it. You should be able to hit enter to confirm the command. The big take-away here is that you need the beginning and ending quote before you can type any special characters. To confirm, you can view the passphrase unencrypted by typing “encrypt disable” and then “show wlan SSID-profile test-ssid_profile”.

TAC says they have added this procedure to their documentation.

…till next time!

 

Designing by the channel

Channel planning! Almost as glorious as clicking in all those little walls on your million sq. ft. floorpan…. Which by the way is a scanned in PDF from 1994. The things they don’t tell you when you decide to do wireless…

Today I’m writing about my preferred method of planning channels. “How hard is this?” You may be thinking. Well, its not. But with my personality type (ISTP or a 1,5,4 as Devin calls it) I like to help people, tinker, and fix things. As my friend Chris Hopkins once described me: “Joey is the type of guy that could take a car apart and put it back together with a screwdriver.” I don’t know about that much, but I do find myself dismantling things and fixing them and most of the time making them better throughout my days. Also helped me figure out that I’m an extremely visual learner. To sum all this up, I’ve been planning channels for almost as long as I’ve done wireless (sad, I know). But in all this planning, I’ve tried several methods to figure out what the best and most time-efficient way of laying out a building’s channel plan. Here is what I’ve come up with…

All my planning is done using Ekahau. I know there are others, but Ekahau has become my favorite because of the ease of use, and the features that they keep coming out with that is making our jobs as wireless engineers easier. I mean, what other company has a VP that drives across a country he isn’t from just to talk to customers about new features and asks what they want? Props @JussiKiviniemi. Props.

First off, lets start with the available channels.

I only channel plan for 5Ghz. Why? Cause there are 25 channels available to use and that means less interference, better connections, and higher speeds for the little guys(clients). A part of this channel set is the dreaded, evil DFS! You’ve heard the stories… Mostly from those “Tech on the side” guys:

“DFS is evil! If you are within 4 million miles of an airport, you’ll NEVER be able to use DFS! And Radar?! Why do they even allow wifi on those channels? Nobody can use them! Its like wasting energy just typing the number into the standard!”

Hardly. I HIGHLY recommend testing for DFS events before deciding that you can’t use them. You’d be amazed at the times that you can. The hospital I worked at implemented a full 5Ghz channel plan across 7 buildings and 6 stories; less than 2 miles from an airport. After baking for a month, I discovered ONE DFS event. Always on the same channel 116. Always on the same AP. So what happened? Did the FCC come shut our hospital down, dooming all the grandmas that were laying so helplessly in all the beds? Did the entire wireless network collapse while surgeons were cracking rib cages open with ball peen hammers and chisels, listening to Dire Straits wirelessly (I’ve seen that.)? No, we just changed the channel to something else that doesn’t interfere. Don’t forget that most (all?) of the time, the AP doesn’t stop working when it gets a DFS trigger. It simply moves to a non-DFS channel for 30 minutes and then moves back. So uneventful!

In my experience with using DFS channels, so far I’ve only had one instance where it caused a problem. A doctor in a corner office said he didn’t have any signal on his Toshiba laptop. I went over to the area and sure enough, my AirCheck G1 said the same thing. What the heck?! There was an AP IN his office! Looking on the controller, I quickly realized that the AP was on channel 144. This channel, at the end of the DFS spectrum, is the newest channel allowed in the 5Ghz range. Because he was in a corner office, his secondary coverage was crap and he’d drop once he closed the door. There are quite a few clients and wireless cards that do not support 144 yet. After seeing that instance, I decided to remove channel 144 from our entire layout (which hadn’t been installed yet). This was a crappy process but it helped me hone the subject of this blog post and once it was completed, I didn’t have to worry about it again because I USE STATIC CHANNELS. (yes, you can remove 144 from RRM settings. but I couldn’t resist.)

So with all that, lets remove 144 and back it down to 24 channels. We want to make sure that all devices can reach Facebook, am I right?

Signal First.

So the first step I take in planning the RF coverage of a building (after testing walls, and replicating them for weeks) is placing 1 of my chosen model APs in a location that covers -67dbm (or my target signal strength) at the corner of the building. This is typically in a room across the hall from the corner office or conference room unless I’m designing for HD or VHD.

FIRST PLACEMENT.png

After that first AP is placed we can configure the settings for the rest of the placements. I put the channel on 116 and set the desired power level. Why? Well, 116 is pretty much in the center of the 5Ghz band, so later on, I can change that channel to the final channel and the coverage isn’t going to change too much. I also have it engrained in my head that APs on 116 haven’t been planned yet so its a good starting point. This will make sense later. If the power is lowered I then move the AP as needed to keep signal where it was in the corner.

Next, I layout all the primary coverage in the entire building. All floors, indoor and out. Placing all the APs with the settings from the first -Channel 116/tx-power xx. Ekahau duplicates the first AP automatically. Just don’t leave the screen…I’ve been bitten by that in the past. Its not fun to fix 50 “generic” APs after you’ve saved…

Secondary coverage

This isn’t something that is talked about by vendors very much. Instead they say something stupid like “20% cell overlap!” What the heck does that even mean? Who said that and then convinced others that it was a good idea? Someone that uses that “honeycomb” pattern..Not a CWDP.

Secondary coverage has two functions. First, its what makes roaming successful. Too hot, and devices will have a hard time making a decision to which AP they should roam. Too lacking, and the client will either disconnect from the primary AP before roaming or you’ll stick to the primary AP and your signal will turn to crap before the roam is successful. Either is bad for the client. The second purpose is for redundancy. With a good secondary coverage plan, and AP can go down and users won’t notice. I experienced this at the HD3 hospital that I redesigned:

Cablers (somehow) always manage to get a bunch of ceiling tile fiberglass inside the ethernet port. They plug it in and it works initially, but later it craps out and you get an alert that the AP went down. When you go unplug the AP and blow the entire ceiling tile out of the ethernet port and plug it back in -it works fine. This happened to the MAIN AP in the middle of the Emergency Department. The one that ALL the nurses and doctors sit under and work from. Average client count of 35. The AP went down, and nobody said a word. No calls, no support ticket. I just noticed it was down. I remediated the AP a couple weeks later during a slow day and all was good. That is what secondary coverage can do for you.

To plan secondary coverage on Ekahau, select the 5Ghz band for the view, and click options. Down at the bottom is a drop-down that says “Show the (strongest) signal at (all) channels“. Change the first drop-down from (strongest) to (2nd strongest). Then change the legend to your desired secondary level. I mostly use -70. Some devices recommend more. If you use the default view, you want the map to be speckled with mostly yellow and gray. Once you see darker green, your APs are probably too close and you need to move them apart a little bit to get rid of the green. Lighter green is certainly better than dark green. Also, remember grey is ok for this view. Large spots of of grey should probably be fixed. I don’t typically worry about the secondary coverage for the edge of the building because users won’t be roaming in those areas.

SECONDARY COVERAGE.png

Now all the APs are placed. Primary and Secondary coverage is looking good and I’m ready to start changing channels.

Before I start changing channels, I like to do a calculation to determine how many APs need to be on each channel in order to get blanket coverage with non-DFS and DFS channels. I like to design with a 60-65% coverage model for non-DFS and 35-40% for DFS channels. I do this calculation per floor instead of the entire building.

If I’m working on a large floor that has 60 APs, I find out what 60% of 60 is: 36. There are 9 non-DFS channels (36-48, 149-165). So 36 divided by 9 = 4. Each non-DFS channel will have 4 APs. The remaining 40%(24 APs) will have DFS channels.  24 divided by 15 is 1.6 APs per channel.

Recap:

  • 60 APs
    • 60% of 60 APs is 36 APs.
    • 40% of 60 APs is 24 APs.
  • 36 APs will use the 9 non-DFS channels.
    • 36 divided by 9 is 4 APs per channel.
  • 24 APs will use the 15 DFS channels.
    • 24 divided by 15 is 1.6 APs per channel.

Still following? Hopefully.

Now to the channels.

So then we begin:

In ekahau, set these settings:

  • Show “Channel Overlap” for “Selected APs” on 5Ghz only
  • Click Options, and select “Detailed” view
  • I turn contours off in the legend (personal preference)
  • Leave the legend at 0 and 2.

Now, starting with non-DFS, select 4 APs that do not cause CCI. CCI shows in yellow:

FIRST SELECTION CCI.png

Then click Actions, Edit selected APs, and change the channel to 36. Be sure when you are selecting the APs, that you only click the 116 icon. If you select the AP itself, it will select both channels and the edit screen won’t let you change the channels.

Now, repeat for the other 8 channels. Keep in mind to stay away from ACI. ACI is Adjacent Channel Interference. ACI is caused by putting 2 neighboring channels next to each other in an environment such as 36 and 40. ACI can cause most problems than CCI because its harder to detect without a protocol analyzer and it can produce errors in the transmissions from clients to AP and vis versa. As far as I know, the 2.4 range doesn’t experience ACI because there is a separation of 25 Mhz in between the 1, 6, and 11 channels. In 5Ghz, there is no separation. Channel 36 butts straight up against channel 40. This is where the problem is. *Sometimes its unavoidable. I’m still getting better at this.

At the end of this section you should have covered most of the floor with non-DFS channels, possibly with little gaps here and there. I find that its typically hard to get coverage in the middle of the area. Most of the outside APs will hear the APs in the middle so you can limit yourself if you aren’t paying attention.

Non-DFS

 

Next, Do the same thing with all the DFS channels that you require according to your percentage, again keeping in mind ACI. Your last couple of APs can stay on 116 if you decide to leave them and the channel hasn’t shown any DFS triggers.

DFS coverage.png

(ignore the 2.4 radios. I was mid-project)

Once you are finished, you double check your coverage and interference by viewing “My APs” instead of selected and looking at signal coverage and channel overlap.

FINISHED CCI.png

FINISHED SIGNAL.png

And thats it!

When doing a multiple floor building, I start at the top because most APs have a down-tilt antenna. If CCI is going to happen floor-floor, most of the time it will happen from the upper floor broadcasting down. Speaking of, I haven’t found a good way to check floor to floor CCI during the planning phase. What I do currently is take a screen shot of the floor above, and reference that as I’m channeling the current floor. Not perfect but its better than waiting 10 minutes for each floor to refresh.

Lastly, depending on the power level, you probably aren’t going to get rid of all the CCI. My advice would be to know the building and requirements when you are designing. That way you can make good decisions when you get into that situation. Sometimes you just need to accept it, and sometimes you just move a couple APs here and there.

Please comment below! I’d love to hear some feedback on this.

As always… ’till next time!

Aruba AOS6 Static Channeling

Aruba ARM! Its the greatest!

Recently I’ve been checking out a bunch of the Cracked “If so&so ads were honest” series. They are quite hysterical. Theme Parks, Grocery stores, Expensive purses….they all give a very interesting perspective on whats really going on and the thoughts that these industries/companies probably have behind closed doors.

Every time I have to mess with ARM, I think about these videos. I hear Mr. Horton saying:

“We know that setting channels statically is probably easier but we just don’t think you are intelligent enough to do it. So use ARM! Why mess with channels when you could be sitting on the beach with a Corona and reading Feci-Fi blogs on your new wireless network?!?”

Horton.png

Does seem kind of true though, doesn’t it? It can’t be that hard to add a command to the controller that says “put this radio on this channel and power and leave it there.” It’s easy with an IAP, why not with a controller?

At least in AOS8 it seems be available. Until then, here is what I did to get a full static channel configuration on my latest system.

Some RRM thoughts…

So are “ARM” type systems all stupid and useless? No, I believe that ARM has its place in the wireless world. In certain environments riddled with neighbors using RRM technology to adjust(or not adjust) all their channels. There has to be a way to tweak RRM to respond to their unknowledgeable high schooler “tech on the side” guy that threw up 40 Ruckus APs in a gas station and called it a network. Never mind the fact that they are all on 80Mhz channels, 10 foot apart, and using 36e and 149e. Hopefully AOS 8’s Airmatch will be better at determining these situations and react better.

Ruckus 80.png

However, I’ve learned throughout my life that its really best to have a good foundation. In housing, a bad foundation will cause your house to fall over. Currently, I’m getting quotes to repair my cinderblock wall in my basement. Its buckled an inch and a half inward and the previous homeowner’s paint just started to crack. Convenient. (This of course is after I put 15K into a full 2 bedroom apartment.) The right side of my house is skewed 2 inches -because of a bad foundation. In life, a bad foundation will lead you into years of trouble with yourself and others. Counseling, jail, lifelong unhappiness, who knows? But it will happen if your foundation isn’t solid.

TOWER

Creating a static plan for your building ensures that your wireless has a good foundation. Its solid and will not change (excluding DFS). Then by utilizing spectrum analysis and WIDS and WIPS, you can be notified of events that are trying to cause problems to your network and then you can go deal with those events accordingly.

Anyway…ONWARDS!

Aruba configuration is all based on profiles. VAP profiles, Radio Profiles, SSID profiles, etc. Its a great design because you can build all the profiles out in the beginning and then just point and click your way through new AP deployments as opposed to hand configuring every new AP and site that comes online.

Aruba Profiles:

Profiles.png

The problem with this regarding static channels is that the channel and power settings are inside the 802.11a radio profile. This means that if you change the channel inside that profile, its going to change it for every AP that is associated with that profile. On top of that, the power settings (Transmit EIRP) are inside the advanced tab of that profile. What does that mean? It means you’ll need a radio profile for every channel, and every necessary power level of that channel. *note that there is an 802.11g radio profile for 2.4. I’ll stick to “a” profiles for this post but it applies to both.

The best way to do this is of course in the CLI. To get that configuration, I created a new radio profile in the GUI and then checked the CLI for the configuration. You’ll end up with something like this:

rf dot11a-radio-profile “profile_name”
channel 36
tx-power 1
dot11h
arm-profile “arm-maintain”

For the naming convention, I decided on this:

Ch-Tx_036-01

This tells me (and future engineers) that the Channel(dash)power is 036-01. I padded with the 0 because Aruba orders everything numerically by the first digit. Regardless if it is 2 or 3 digits long. If you don’t pad with 0, you end up with this structure:

1
10
100
2
20
200
etc…

Very annoying to my obsessive compulsive side. It also makes the profile list a mess.
So now I have this:

rf dot11a-radio-profile “Ch-Tx_036-01”
channel 36
tx-power 1
arm-profile “arm-maintain”

To create all the other profiles, I popped that into excel and created a bunch of concatenate formulas to create a profile for every other combination that I needed. For the 26 5Ghz channels, I created a power setting for 1-10, 15, 20, 25, and 30. 14 Profiles per channel =  364 profiles!

And that’s not all!
Now that you have your 364 radio profiles, you then have to apply those profiles to each AP! So instead of having 364 lines of configuration that you should really need, now you have that plus however many APs:

ap-name “FFI-04-079”
dot11a-radio-profile “Ch-Tx_149-10”
dot11g-radio-profile “rp-monitor-g”
!
ap-name “FFI-04-080”
dot11a-radio-profile “Ch-Tx_132-10”
dot11g-radio-profile “Ch-Tx_06-02”
!
ap-name “FFI-04-081”
dot11a-radio-profile “Ch-Tx_060-10”
dot11g-radio-profile “rp-monitor-g”
!
ap-name “FFI-04-082”
dot11a-radio-profile “Ch-Tx_040-10”
dot11g-radio-profile “Ch-Tx_06-01”
!
ap-name “FFI-04-083”
dot11a-radio-profile “Ch-Tx_104-10”
dot11g-radio-profile “Ch-Tx_11-02”
!
ap-name “FFI-04-084”
dot11a-radio-profile “Ch-Tx_048-10”
dot11g-radio-profile “rp-monitor-g”
!

One careful note about quotes: Aruba OS uses quotes, but does not like quotes being pasted in. Before you paste copied configuration back into any Aruba controller using AOS6, find and replace ALL quotes with nothing:
Find replace quotes.png
If you don’t, you’ll end up with configuration that looks like this:

rf dot11a-radio-profile “Ch-Tx_036-01″
channel 36
tx-power 1
arm-profile “arm-maintain”

It will create new profiles in addition to the current ones and make your configuration very confusing. Also, NEVER use spaces. (This should be a given.)

I’ve read some of the Aruba Airheads responses to static channel requests and they always point to the “regulatory domain”. They say “remove all the channels you don’t want and then apply the domain to the AP”. In investigating this solution, I’ve found that while that will help with keeping the channels static, the power will still fluctuate depending on ARM. Maybe I’m wrong, but meh. There’s more than one way to skin a….potato.

So there it is! Can’t tell you how long I searched for something like this when I was a little Aruba certified associate. Unfortunately, knowledge like this isn’t getting me closer to ACMX. Back to studying!

’til next time!