Blog: wireless

We recently moved a customer from a datacenter at one of their locations to a large datacenter in the Dallas/Ft. Worth area. One of the devices we moved was a Meraki MX84 being used as a VPN concentrator. A VPN concentrator works by extending the network the VPN concentrator is on to the access points. Basically, wireless clients at all locations get an IP address on the same layer two network. This is important for a few reasons. First, the VPN concentrator needs to be in it's own VLAN/DMZ. Second, something on the layer two network the VPN concentrator is connect to needs to be handing out DHCP addresses. In our case, we used a Fortigate UTM to run the DHCP server for that subnet. Third, traffic needs to be allowed outbound to the Internet from all clients on the VPN concentrator layer two network so clients can connect to the Internet. The traffic is tunneled from the access points to the VPN concentrator, so the traffic does not intermix with the normal network traffic.

One of the issues we had was that the access points would not create the tunnel back to the VPN concentrator. After talking to Meraki support, we found that the issue was that the access points and the VPN concentrator would not connect to each other if their public IP address was the same. This does not work because Meraki uses the same technology to build the VPN from the MX to the access points as they use to build a VPN mesh between MX devices. Our devices were both using the default overloaded outbound NAT rule, so they were coming from the same public IP address. The solution is to make the MX come from a different public IP address, which can be accomplished via an inbound and outbound NAT statement. After we made this change, the access points connected to the VPN tunnel and wireless began to work.

One other thing to note is that the access points will not broadcast SSIDs if the VPN to the concentrator is not up when configured to tunnel traffic through a VPN concentrator. This can be helpful when troubleshooting wireless when there are not clients at the location of the access points.




Like many new laptops, the new Apple MacBooks are too thin to have an onboard Ethernet adapter. After setting up a local account and connecting it to the internal wireless network (using WPA2 Enterprise), I was able to join the Macbook to the Active Directory domain without issues. However I quickly discovered that I couldn’t login to a domain account because by default wireless connections are not connected before login – remember, no Ethernet.
The immediate “fix” was to purchase a USB3 gigabit Ethernet adapter, but after some research later I discovered it's possible to enable WiFi before login. Here are the basic steps:

  • Install the Apple Configurator utility from the App Store. This app is designed to create deployment profiles for iOS devices but can also be used to create 802.1x profiles for OS X systems.
  • Run the Configurator and create a new profile. Update the WiFi section with the required connection information.
  • Save this profile locally.
  • Open the profile with a text editor and add XML text as outlined at This article is for an older version of OS X and refers to the discontinued iPhone Configuration Utility (which was replaced by the Apple Configurator), but the manual edits still apply to OS X 10.10 and 10.11.
  • Double-Click the edited profile to import into System Preferences. You can see the loaded profile by going to the 802.1x section of the Network->Advanced settings in System Preferences.
  • Logoff or reboot and you should be good to go.


I was wanting to create an ad-hoc network on a Windows 8 system, but discovered the “Create an ad hoc network” feature available on prior Windows OS systems is not available on Windows 8.  However, I found in Window 8 you can use the Network Shell (netsh) utility to create a virtual wireless network (WLAN).

  1. First you need to verify your network interface supports virtualization.  Open a command prompt (with administrative privileges) and run “netsh wlan show drivers” – look to see if “Hosted network supported” is “Yes”
  2. Enter the following command to configure the wireless network “netsh wlan set hostednetwork mode=allow ssid=<name> key=<password>
  3. Now start the hosted network by running “netsh wlan start hostednetwork”


While installing a wireless network at a youth camp where I volunteer,  I was having issues getting the wireless distribution system to see the wireless access point in the building where the main router is located. If I place the WAP in the attic I could get a decent signal. So I moved the WAP to the end of the building, in the attic and mounted it inside the wood eave of the building. I was then getting a good signal to my other building. It wasn’t till after I had done this that I realized it never would of worked the first way I was trying. Most of the older buildings, such as the one the network originates from, have stucco exteriors. Part of the process of installing stucco (at least the old way) is to wrap the building in a wire mesh to help hold the stucco. It finally occurred to me that the wire mesh was creating a faraday cage around the building preventing the wireless signal from reaching outside.


Awhile back, we had a problem with two of our Cisco Aironet devices at a customer site that kept dropping their wireless connection to each other.  The old radios had been replaced by these newer aironet devices while still keeping the same antennas.

The error message, among many, in the logs stated: “Packet to client <clientname> reached max retries, removing the client”.

At first, we thought that they might be overshooting the other end by having their signal strength too high.  We tried lowering the signal strength but it didn’t really help the issue that much.  We tried scanning the airwaves for interference, but couldn’t decisively find anything troublesome with the channel frequencies.  We also checked the alignment of the antennas and saw that they appeared to be in the same position that they had been for quite some time.

I came across a wireless troubleshooting guide by Cisco that mentioned that the problem can be an indication of a bad RF. It suggested putting the command “packet retries 128 drop-packet” on both access points as a workaround for bad RF.  After this command was applied, we the wireless connection stopped disconnecting.


One of our customers has a point-to-point wireless connection, which started failing with an error that indicated problems with radio interference.  I ran the utility to check for busy radio channels, but it did not indicate any problems.  (Many channels came back as completely unused.)  I eventually reduced the transmit power of the root-bridge radio, which caused the connection to come back up. 

In retrospect, the issue was likely caused by a reflection that caused a second radio signal out of phase with the original signal.  This reduced or eliminated the signal at the antenna.


My iPhone connects in my office to wi-fi which also is able to connect through my VPN router.  For my laptop, I had set the DHCP settings on my wireless router to include the internal CoNetrix DNS server.  When I connected my phone which uses Exchange active-sync to connect, it would get an error about the certificate authority being untrusted and hit OK to continue. 

Later on I noticed that my phone kept getting synchronization errors and would get the pop up about the certificate authority being untrusted.  What I later noticed was that the server name would change from our internal to external back and forth.  [more]

I later realized that our DNS server had a host record that was the same as our external mail server address.  Each time the phone went on and off my wireless network, it would keep switching server names because the internal DNS would resolve to the actual internal server name. 

I removed the DNS server for the CoNetrix internal network from my wireless router and the phone has only connected to webmail externally.  It no longer tries internal access.


Symantec published a paper in conjunction with Indiana University describing how attackers could be using unsecured home wireless access points in pharming attacks. The vulnerability is related to easily guessed credentials on the wireless routers and default installations are definitely easily guessed.

The ploy described in this paper ( involves the use of javascript on a malicious website that changes the DNS settings on the wireless router - provided the router credentials can be guessed by the application.

So, there is more to it than being sure your wireless transmissions are encrypted.