WiFi in Hazardous Environments

Recently my team has been engaged in conducting wireless surveys in process environments and I thought this would be a good opportunity to post what I have learned in this area since the internet does not do a good job of breaking down the options. This is definitely not a full course on hazardous environments. The intent of the article is to provide some guidance when the need arises for installing a WiFi access point in a classified environment.

Many manufacturing areas or petroleum refineries have areas that are classified as hazardous. A hazardous area typically has gas, dust, or fibers that are highly combustible. Shown below is a table showing the environmental classifications as defined by NEC Article 500. The different classes are broken up into each type of combustible material as well as how likely the material is to be found in the environment.

The equipment that is operated in these areas must be rated according to these areas. Failure to do so increases the likelihood of an explosion that would really ruin your day (probably life). ☹

Typical ignition sources are sparks caused by motor windings or switches or it can come from a heat source like a lamp or a bearing. Other ignition sources can be a shorted or damaged electrical circuit. Everybody remembers the phone batteries and their overheating issues. These could definitely set off an explosion and should not be allowed in the area unless they are rated Intrinsically Safe or I.S. and the rating must match the environment they will be in. Wikipedia’s definition of Intrinsically Safe is “a protection technique for safe operation of electrical equipment in hazardous areas by limiting the energy, electrical and thermal, available for ignition.”

Often overlooked is the fact that WiFi surveys cannot be performed in these environments in the normal way. The access points and electronic survey equipment normally used is not rated for these environments and may cause an explosion. This does not mean we cannot do it however. Hot-Work permits can be created by the manager or supervisor and safeguards can be put in place to prevent a catastrophe. More importantly, gas monitors can be utilized by the surveyor (or the escort) to determine whether or not there is any risk. This is often overlooked but I highly recommend this for obvious reasons.

Having said that, too often WiFi surveys in hazardous areas are done in a haphazard way (see what I did there? 😊). Due to the limitations the surveyor will choose to skip an APOS and decide (guess) where the access points should go. These are typically the areas where the APOS really needs to be done. Even if you can only survey part of the environment, you can get an idea of the propagation characteristics and make better decisions based on that. Surveys in hazardous areas can be done safely so I recommend surveying as much as possible until you get a pretty good idea for AP placement.

There is not a whole lot of information on the internet about how to install access points in an enclosure and what the requirements are. Sure you can find plenty of access points that are certainly rated for gas environments however the Class 2 environments is a different story. Many people assume you can install an AP that is rated for a Class 1 area in a Class 2 area but this is not true. Please do not install a Class 1 AP inside a Class 2 environment as this is unsafe. It is kind of funny because I know I have directly asked manufacturer reps in meetings and sent emails regarding what they recommend for dust environments and all I get back is usually a statement saying they will look into it and that they know somebody that can help but in the end I don’t get anywhere. The quick response is to install the AP in an explosion-proof enclosure that costs many thousands of dollars. This article will hopefully shed light on Class 2 environments and how to possibly save some money.

The very first thing you should do is to verify the classified area absolutely needs WiFi coverage. After verifying I recommend the following:

Try to find an MCC (Motor Control Center) or an area that is adjacent to the hazardous area needing to be covered and evaluate whether or not an AP can be mounted in this area. If possible, then place a test AP in this area and conduct a quick measurement of the signal in the hazardous area. You may want to use a higher gain (directional) antenna to maximize coverage in the hazardous area. If sufficient coverage is provided by the AP, then you have your answer and avoided a more expensive option.
If the coverage is insufficient then another option is to mount the AP in the unclassified area and run antenna cables through the wall and mount the antenna (directional?) on the other side of the wall. The important thing here is too ensure you install an RF barrier to prevent any excess energy from being able to propagate down the antenna line and potentially cause an explosion. These barriers can be found at Solexy.net and they are made specifically for these applications. See below:

AP mounted in a Non-Hazardous Room separated by RF Barriers

The options above will save you money however if none of these options will work, we need to start considering mounting the AP in the area or within an enclosure that is rated for the environment. I will break this down into Class 1 (gas) environments and Class 2 (dust) environments. The environmental temperature also becomes a concern and needs to be included in the solution. If the environment is hot or cold, it is important to understand the operating temperature of the access point. Outdoor access points typically have a much wider operating temperature range (-40°F to > 150°F) than indoor or office access points.

Class 1 Div 1 – there is likely a sufficient amount of gas in the area to cause an explosion

The only option in these highly explosive environments is to mount the AP in an explosion-proof enclosure.  These enclosure will literally contain an explosion and not allow sufficient heat to be transferred into the classified area.  This is an expensive solution but thankfully the rarest (in my opinion).  Here is a link to a popular company that provides these types of enclosures.

AP mounted in an Explosion-Proof Enclosure by Analynk

Class 1 Div 2 – there can be a sufficient amount of gas in the area to cause an explosion but it is abnormally present

Option 1) Cisco has recently come out with their new IW6300.  The AP itself (when properly installed) can live directly in the environment.  Here is the link to the spec sheet.  This AP will set you back several thousand or more but also keep in mind the price to install it (conduit, etc.). The RF barriers I mentioned earlier are built in which means you can install any passive antenna you desire (within regulations).  It is a clean option however in the end it may be just as cost effective to install an explosion-proof enclosure.

Option 2) Install an AP in an explosion-proof enclosure – same as Class 1 Div 1

Class 2 Div 1 – there is likely a sufficient quantity of dust in the air and any heat source can trigger an explosion or dust buildup that can also cause a heat buildup can trigger an explosion if equipment is mounted in the area without adequate protection

Option 1) Mount the AP in a Nema 9 enclosure (ignition proof) with external antennas that is separated with RF barriers.  Again, there may be some cost savings here but in the end it is good to get a quote for an explosion-proof box as well as this option.  See the picture below:

Option 2) Install an AP in a pre-built Class 2, Div 1 rated enclosure made by Extronics.  They should have an enclosure and AP combo just for you.

Class 2 Div 2 – there can be a sufficient amount of dust in the area to cause an explosion but it is abnormally present

Option 1) Finally this is one class we can save money on!  All that is required in these areas is to have the AP mounted in a Nema 4X box that is dust proof.  A polycarbonate box can be purchased for ~ $150.  Here are two variations of this box:

Polycarbonate NEMA 4X Enclosure Tessco 500864

Polycarbonate NEMA 4X Enclosure Tessco 521193

I hope this article has provided some guidance and helps fill in some holes or at least steers you in the right direction to be able to find more answers. I have also placed some links that have helped me understand the standards and definitely provide much more information. Feel free to ask any questions or post your comments. There is so much to learn in this area and I welcome anybody who has more guidance to offer. Thanks.

https://en.wikipedia.org/wiki/Electrical_equipment_in_hazardous_areas

Click to access article-interpreting-requirements-of-articles-500-516-of-nec-appleton-en-518452.pdf

Cisco WLC Web Auth Certificate

It was time to renew the Web Auth certificate on our WLC again and it never fails, there is usually something that causes this process to go awry. Having said that, each time I need to troubleshoot certificates my understanding grows and my arsenal of troubleshooting skills gets a little larger making me more effective at tackling the problem. I would like to show you a couple tools I used this year to figure out exactly what was going on.

This year I was contacted to assist in figuring out why a certificate was failing to upload into the WLC. I was sent two different .pem files and the private key file. What exactly are pem files? A PEM file is the output of a Binary64 encoded DER certificate based on the ASN.1 data structure. It stands for Privacy Enhanced Mail and is an old failed format created for the transmission of secure emails but the container format lives on and used for other purposes like certificates. It is one of several formats an X.509 certificate can be in. It is basically a Base64-encoded text file. Certificates in the PEM format can hold the entire chain of certificates in one file. The WLC requires certificates to be in the pem format. Since I received the files already in pem format I thought it would be an easy task by simply combining the three files into one. This can simply be done by opening Notepad and copying and pasting the contents of each file into one and naming it something like “wildcard_cert.pem”. Here is the order in which they are to be in:

**Certificate Chain Order in a PEM File**

This is all fine and dandy and should work just fine however when I tried to upload the PEM file into the WLC, I received the error: “Failed to install certificate”. The logs did not provide any deeper insight as well.

What to do? This is where the debug commands come in handy.

I went to the CLI of the WLC and issued the following two commands:

“debug transfer all enable“

“debug pm pki enable“

The first command was issued to troubleshoot any file transfers and the second command issued provides insight into the certificate problem. I then tried to upload the PEM certificate once again and the following output appeared:

The debug line stating “unable to get issuer certificate” was the hint I needed in order for me to second guess the entirety of the certificate chain. I should have checked this at the beginning but I just overlooked it. The entire chain has to be present! I quickly looked at an old certificate and realized I was missing the root certificate. I then went to Digicert.com and downloaded their public root certificate and pasted the contents into the pem file and boom!…the certificate could be successfully uploaded!

Another way to get to the core of the problem is to utilize OpenSSL and verify the certificate itself. If there is ever a question whether or not the entire chain is in the certificate, issue the following commands:

**Notice the Missing Root Certificate!**

You can clearly see in the picture above the root cert is missing altogether. You can tell when you are at the end or the bottom of the certificate chain (root) when the subject of each certificate matches the issuer.

Here is a picture of the entire chain:

**Entire Chain – Subject = Issuer is the Root**

Let me know what certificate problems you have faced with the WLC and thanks for reading!

Virtual IP & Guest Redirects

I would like to shed some light on how exactly the guest redirect works when a guest user connects and is redirected to the WLC’s captive portal. This is one of those items that I always overlooked (because it was working) but was forced to learn when it was found the virtual IP address was causing problems. You can read about that here if you would like.

The following is the text from Cisco’s WLC Configuration Guide:

With Layer 3 security, the client will issue a DNS query for a web server; the controller spoofs the DNS
response, providing its own Virtual IP address. The client then opens a web connection (HTTP port 80 or
HTTPS port 443) to that address. The controller redirects(to itself [Local Web Authentication] or to an external
server [Central Web Authentication]), and then that dialog is used to authorize the client to connect to the
network.

Many times it is easier for me to understand something if it is laid out in a step-by-step, serial fashion. In order to help out the reader, I thought it would be best to capture some packets and illustrate the process of how a guest user is redirected to the captive portal.

**Packet Capture of Guest User Being Redirected to the Guest Captive Portal**

Upon connecting, the device uses DHCP to get an IP address. In the instance shown below, the device is requesting an IP address immediately instead of going through the full DORA process. Note the virtual IP is used as the source and in this case is being used as the DHCP relay (the WLC is the DHCP server).

The client’s OS is Windows 10 and Microsoft has a built-in method for testing whether or not the computer is connected to the internet when it detects a potential hotspot. It will send a packet to msftconnecttest.com. The guest wlan is configured such that 8.8.8.8 is utilized for DNS. Note the computer sends a DNS request for msftconnecttest.com and a response is given.

Now that the computer knows how to communicate to msftconnecttest.com, it next attempts to communicate with the server by sending an HTTP request to “4-c-0003-.c-msedge.net”. It is not shown below, but the response in packet 5 gave both the IP address as well as the URL. The packet capture tool used the URL in packet 6 instead of the IP address in the Destination column. The WLC spoofs the server in packet 8 and redirects the client to “guest.company.com”…very sneaky eh?

Packet 6 – **HTTP Request to msftconnecttest.com**

**Packet 8 – WLC Pretending to be msftconnecttest.com Redirecting to guest.company.com**

The client does a DNS lookup to be able to get to guest.company.com. This step is very important as an external DNS server needs to to have a DNS record pointing it to the virtual IP address. This caused some confusion because it didn’t make any sense that a DNS record was going to point to a virtual IP address that was not routable! Nonetheless, this is how the WLC and the client communicate…please note there is never any traffic on the distribution system addressed to this IP address. This traffic is only between the wireless clients and the WLC.

**DNS Lookup of guest.company.com – Response is Virtual IP Address of WLC**

Finally the guest device sends traffic to the WLC captive portal – guest.company.com (192.0.2.1) utilizing secure HTTP where the WLC can then authenticate the device and allow it access to the internet.

**Guest Client Communicating with Portal – guest.company.com at 192.0.2.1**

One final note on the HTTPS captive portal certificate. In order to avoid the certificate warning, the Web Auth Certificate needs to have the FQDN of the virtual IP address (exactly as the DNS record) listed as the CN. To make things a little easier, wildcard certificates are also accepted. In my case, “*.company.com” is used as the CN.

This article does not cover all the uses of the virtual IP address but hopefully it provides a little more understanding. Thanks for reading!

Virtual IP Woes!

I wanted to write about a problem I had recently with the virtual IP address of a Cisco WLC. The IP address had been in use for years with no issues. It was addressed in the 12.x.x.x subnet and was actually a real IP address for one of our external websites. I had read in the past the virtual IP address of a wireless controller should never be a real IP address as it may cause issues but it had been configured this way for years and it was left uncorrected. I was a little confused by how the virtual IP worked and thought why fix something that isn’t broke! 😉 This misconfiguration reared its head in a way I would have never guessed.

Before I can jump in and give you the problem and solution, I need to provide some background. In addition to managing the WiFi network, I have the responsibility of managing our fleet of radios across the U.S. There are thousands of radios that need to be managed and maintained. Keeping inventory of these radios and ensuring these devices are in compliance can be a real challenge! Fortunately with the Motorola Solutions Mototrbo line of radios, managing these is greatly simplified using a radio management server and WiFi. The radios automatically connect to their SSID and the radios can be read from or written to as long as they are connected to the wireless network…all from a single pane of glass.

Each of the Mototrbo radios have a unique radio ID along with a CAI (Common Air Interface) Network and a CAI Group Network value. While they operate in digital mode, the radios communicate with other radios by one of two ways: a group call (talkgroup) or a private call (one-to-one). When the radios make a private call, the radio combines the radio ID with the CAI value, which is defaulted to 12. When combined, this creates an IP address. For example, radio ID 1 combined with its default CAI of 12 will be 12.0.0.1. You can actually ping radios from your computer! Please note this is not the WiFi address of the radio; it is the radio’s CAI or the main radio interface used to communicate with other radios over VHF, UHF, or 800/900 MHz. The radio has a WiFi interface, a USB interface, and its main radio interface (which is the CAI). Traffic coming into the radio via its WiFi or USB interface that is destined for a 12.x.x.x network will be routed out the CAI. Group calls are routed the same way but the difference is that Group calls default to a 225.x.x.x IP address.

Ok, now that you have that background info I can tell you the rest of the story. One day I received a call stating the Mototrbo radios were not operating correctly. They were very intermittent. Upon investigation it was noted the repeaters seemed to be receiving and retransmitting intermittently and sometimes it was quite often. The random transmissions would come and go with a high enough duty cycle preventing all valid two-way handheld transmissions. It was a big problem. The radio dealer was called out and they investigated and reported back they thought the problem arised when the radios were connected to the WiFi. Honestly I thought it was a bug in the radios but by carefully observing the radios when they connected it was found that when the radios received traffic from the virtual IP address of the WLC (think DHCP on the WLC), the radios simply tried responding to the DHCP server but instead routed the response out its CAI! The result was a bunch of digital traffic being burst out and being repeated on the repeaters taking up airtime.

**Radio Routing Traffic Destined to 12.x.x.x Out the CAI**

Once it was understood what was happening, the fix to all of this was to change the virtual IP address on the WLC. We changed it to 192.0.1.2 and the problem went away. I will post another article on the virtual IP and how it is used with the captive portal. This topic always confused me a bit so I hope I can help somebody out there that is still fuzzy on this topic. Thanks for reading!

Slow WiFi

One day I received an email stating one of our warehouses had very slow WiFi. As a matter of fact, the WiFi was never any good. After following up with the customer, I decided to go to Prime Infrastructure and view any historical data from the AP3702s that were installed in the warehouse. Right away I could tell there were some issues as the channel utilization was very high in the 2.4 GHz band. Shown below is an example of what I was seeing.

I know from experience that channel utilization in the 2.4 band is normally higher than in the 5 GHz space. Normal channel utilization will usually be anywhere from 10 to 35% as this spectrum tends to be noisier just due to the presence of other competing devices, especially in the office areas however this was a warehouse and they tend to have a quieter environment. Utilization as high as 65 – 70% usually means WiFi devices are either not talking or data throughput is very slow and requires some correction to get this number back down.

I decided to put one of the access points in SE-Connect mode. In this mode a separate application called Cisco Spectrum Expert can be run on your PC. This application connects to the access point and the spectrum data from the CleanAir-enabled access point can be streamed in real-time from the access point to your PC. It is like having a spectrum analyzer at the site and works pretty well.

Once the AP was in SE-Connect mode (a reboot is necessary), I copied the IP address and the Network Spectrum Interface key. This information was easily found by going to the WLC GUI and selecting the access point in the All APs>Details page. This information is needed for the Spectrum Expert application and is what is utilized to make the connection to the AP. The radio (a or b) will need to be selected upon connecting as well. Once connected you can choose to display different FFT or spectrogram plots. I chose to look at a combination of FFT Duty Cycle, Real-Time FFT, and a couple other plots to understand the percentage of time the RF medium was being utilized over time. Shown below is what I seen that day.

The numbers I seen from this access point were pretty shocking in that it was reporting 100% duty cycle for long periods of time. You can see from the plot on the lower right that the duty cycle was at or near 100% for over 10 minutes! You can also see from the plots on the left this interference is utilizing the entire 2.4 GHz band and is not your typical microwave oven incident. After calling the customer back and asking them about any other wireless devices they had in the warehouse (they did not know of any) I decided an onsite visit was in demand.

Upon arrival I fired up my PC and ran AirMagnet’s Spectrum XT. This is a great application. It utilizes a USB dongle that houses a spectrum analyzer on a chip. It is easy to use and you can record any data you receive to easily play back later or for documentation purposes. Right away I was faced with the similar high duty-cycle and interference I seen from the access point and started confidently walking the warehouse. I remember thinking I will have this interference tracked down in no time! I was quickly humbled because the interference would mysteriously come and go leaving me somewhat baffled as to where it was coming from. I remember going back in forth in the warehouse and going towards what I thought was the source and then once I thought I was on top of it (the signal levels would get as high as in the -40s!), it would be decreased or even gone. After doing this for some time I felt defeated and decided to capture some packets to get another perspective.

I then opened up Savvius Omnipeek and captured some packets in the 2.4 GHz band. Right away I spotted multiple access points from another neighbor that was still utilizing old 802.11b rates. This explained some of the utilization but not all. The duty cycle was too high for too long and there were not that many clients in the area. I decided I needed to go back to the spectrum analyzer and figure out the source of the problem.

Once again I started walking around the warehouse until I came to a spot that was in the high -30s! I knew I was close. I spun around in all directions only to notice I was near a forklift. All of a sudden it hit me…there must be something on the forklift causing this interference. I immediately started to examine the forklift to determine what wireless equipment they were using. I spotted a forklift mounted computer and noted the barcode scanner but knew this was not the source. I continued to inspect the equipment and noticed a mysterious box that had a little antenna connected to it. I disconnected the power to determine if the noise went away and it did. Finally I found the culprit! Here is what I found:

I then performed some Google detective work and found the manufacture of the device. There are two devices installed on the forklift: an video receiver and a transmitter. A camera is mounted on the forks and the output is sent to a video transmitter that is also mounted on the forks. The transmitter is linked to a receiver that is mounted down by the operator. This video is then sent to a monitor that is used by the operator to tell exactly where his forks are at all times.

I exchanged some emails and it was determined neither the cameras nor the neighbors 802.11b access points were going to change. The forklift clients were only 2.4 GHz capable and were due for an upgrade. The best thing to do at this time was to replace the clients with dual-band units that could utilize the 5 GHz. After the clients were replaced, I shut down the 2.4 GHz radios and the barcode scanners immediately started using the 5 GHz radios. The operators stated they never really had good WiFi communications before this so they were pretty excited!

Here is the data sheet for the video transmitter/receiver:

Transmitter
Working Voltage	DC 10-32V
Video System	AUTO
Working Frequency	2400-2483.5MHz
Working Distance	120M
Video Decode	MPEG4
Transmitter Sensitivity	:-89dBm
RF Bit Rate	4Mbps
Spread Spectrum	FHSS
Time Delay	120mS
Waterproof Rate	IP66
Working Temperature	:-20~+70C RH90%
Storage Temperature	:-30~+80C RH90%
Receiver
Working Voltage	DC 10-32V
Video System	AUTO
Working Frequency	2400-2483.5MHz
Working Distance	120M
Video Decode	MPEG4
Receiver Sensitivity	:-17dBm
Bit Rate	4Mbps
Spread Spectrum	FHSS
Time Delay	120mS
Waterproof Rate	IP66
Working Temperature	:-20~+70C RH90%
Storage Temperature	:-30~+80C RH90%

If these types of units are going to be used, I would recommend something that is not going to be used in either WiFi band (or at least be WiFi friendly) and verify they do indeed do what they are advertised to do.

After looking back at this, I thought I should have caught this sooner. It just didn’t dawn on me the source of the noise would be installed on the forklifts. This was not standard equipment and there are better solutions that should have been used. Please let me know if you have ever ran into this issue.

IT/OT Convergence and WiFi

Today I thought I would share some ideas around IT/OT Convergence and WiFi. IT/OT Convergence involves the idea of sharing common network resources in an effort to decrease the management burden and costs normally associated with operating two separate networks while maintaining the same level of security (or keeping it as high as possible). IT and OT networks have been historically isolated and segmented from each other to ensure the compromise or failure of one has no impact on the other. Having separation typically means duplicate infrastructure in each segment and also requires two different groups of people to maintain them.

WiFi and mobile computing has really opened up all sorts of possibilities in the industrial area. One use case in high demand is the mobile worker that can wirelessly monitor and control processes directly over his mobile laptop or tablet. No longer does a fixed workstation have to be manned at all times. The wireless remote operator frees up this individual and allows this person to go mobile and perform checks and maintenance throughout the plant or factory floor while still having the ability to control and monitor everything going on in his process network. One man can now do the job of what used to require two.

This brings me to my next point – Security. Obviously the implementation of WiFi on the plant floor is a requirement for the wireless mobile worker. WiFi utilizes an unbounded medium and introduces many possible vulnerabilities and increases the attack vector many times that of the traditional fixed wired workstation in a control room. If the WiFi network is setup without much thought, not only will the OT network be less secure and prone to attack but the management burden can be increased.

If the OT network is segmented from the IT network (as is usually the case) and somebody wants to implement WiFi, the first thought is to perform a survey to figure out where the access points should go and throw in a WLC. Alternatively you could install access points without a centralized WLC and utilize something like Cisco’s Mobility Express. The problem with having a WLC at each local OT network is there needs to be somebody who can manage each one, thus increasing the management burden. Management of a wireless network is often overlooked and not thought of until a vulnerability comes out (KRACK) and all of a sudden comes the realization that you have to upgrade twenty-five different WLCs. This does not scale well unless you have a team of wireless engineers but when is this the case? You can use Mobility Express but this solution still has limited options. For instance, you still need to maintain the individual sites configuration and there are no anchoring capabilities. Following the NIST’s standards of keeping traffic segmented properly, if it is desired to propagate an IT SSID in the same OT environment, a second AP that is connected to an IT network will be required. The ideal is to install a WLC in a shared process network. With a shared WLC, the management burden is reduced (one WLC upgrade!) and IT SSIDs can be anchored to an IT WLC. For the case of IT Wlans using 802.1X, the AAA can even be proxied or relayed to an IT radius server keeping both the management and data traffic segmented. All of that is good but if you do not have that shared OT network, you may be in for a bit of a struggle as the fight is real when it comes to the IT/OT network segmentation debate!

I stated the previous as a backdrop to illustrate an alternative solution that truly does utilize the IT/OT convergence principles and overcomes some of the burden. The answer is to utilize a combination of the local FW that segments the networks, Cisco AnyConnect, and the local OT domain controller. Admittingly this solution takes a bit of work however if you need to provide a secure solution and one that will work whether or not the WAN is down, then I propose the following as one solution.

As already stated, a requirement of this solution is to ensure the Wlan is available at all times, whether or not the AP can reach the centralized shared WLC or not. For this reason, the only wireless security policy that will work is WPA2 or WPA3 (PSK). FlexConnect is also required to ensure if the WAN does go down and the WLC becomes unreachable, the Process clients will still function normally.

The firewall is configured to have a dedicated trunked wireless interface consisting of an AP management Vlan and a Client Vlan. Firewall rules are implemented such that all traffic is blocked except CAPWAP traffic going to the IT WLC (UDP Port 5246 & 5247) on the AP management interface. A deny any any is applied on the Client interface blocking all traffic.

Remote Access is configured for the client to be able to VPN into the Process network via Cisco AnyConnect. The client IP address is translated via NAT and ACLs are put in place to only allow the client specific destinations. This can be done utilizing Dynamic Access Policies. Both the ACL and the appropriate AD group can be added here to properly permit or deny access based on the AD group membership. Finally, an AAA server group is added with LDAP utilized to query the local Process domain controllers.

On the IT WLC, a Process SSID is configured as locally-switched with a PSK. Client data is offloaded at the AP in a locally-switched Wlan. The access points are configured for FlexConnect and the appropriate Wlan is mapped to the corresponding Vlans. If IT SSIDs are to be propagated on the AP, these will need to be configured as centralized Wlans so that the client traffic will be tunneled up to the IT WLC.

The next step to this process is to configure the client device (Windows). Cisco AnyConnect is installed on the device and then configured to automatically connect to the Process SSID. Once associated, AnyConnect is used to VPN into the local Process domain utilizing their user credentials. This ensures that even if somebody knows the PSK, they will still need Cisco AnyConnect installed and be able to connect using somebody’s domain credentials. If security still seems to be too low, certificates can be utilized as a secondary form of authentication (Multi-Factor Authentication). If the device is lost or stolen, the user account or the device certificate can be revoked to prevent the device from connecting to the Process network. Here are the steps to connecting to the VPN:

Let me know what you think!