How to deploy an office network like a Pro!

deploy-office-network-in-one-day-automate

I have deployed many offices over the past decade. Some were complicated, others relatively straight forward. The common constraint in most of my deployments has always been time.

Usually new offices are always opened due to pressing business needs. This means, the higher management want to see staff moved/new recruits placed in the new office ASAP. Often I have found myself deploying offices on single links.

Every time, I wanted to deploy an office, I had to replicate existing process with minimal time to upgrade the tech involved. I always wanted to improve the network deployment but I always found myself running against time.

Office deployments are usually painful because after doing them the first time, you will find yourself not learning anything new in each successful deployment. You will, however, find yourself wasting a lot of time doing the same thing all over again. This lost time could be better utilized to other things such as improving the production network etc.

This all changed when I joined a company that gave me some breathing room and allowed me to improve the processes in place. This was a multi-billion dollar enterprise that was growing fast. I was already designing their new MPLS network so I realised an automated office network delivery mechanism would sync in really well.

How I managed to achieve this?

Follow my guide below to replicate the same for your next deployment and reduce the required time for all your subsequent deployments.

Config automation via Ansible:

The first thing I did was to automate configuration management with the use of Ansible. If you haven’t used Ansible before, you haven’t lived!

I used to write lengthy scripts in Perl and Python that would simply spit out configuration and change variables where intended. Writing those long print statements and spending countless hours, little did I know that I could achieve the same with Ansible in a matter of minutes!

As they say, it’s never too late, I jumped the Ansible bandwagon and automated all configuration deployment for successive deployments in future.

This meant, the usual components of an office deployment were all templated. These components included the following:

  1. Firewall configuration
  2. Core switch configuration
  3. Access switch configuration
  4. Production firewall rule sets configuration

Usually any office deployment involves the deployment of a branch firewall, core switch, multiple access switches and the configuration of rule sets over the corporate/production network firewalls in the data centre.

I configured Jinja templates which are simple YAML files for Ansible to manipulate for all devices listed above. This meant for each successive office, I simply had to update the variable files and the configuration for all the devices would churn out in a matter of seconds!

Ansible can actually go ahead and configure these devices for you as well but for new offices, the kit is still in boxes hence, you have to manually configure the devices via console. For existing firewalls in corporate/production network, you can easily task ansible to go and configure with the new rulesets/address addition in existing address objects.

If you want to follow me in automating your next office deployment via Ansible too, why not! than here’s a guide I have written for you: Ansible: Use playbook to deploy your next office

Securing the network using 802.1x:

In simple terms, 802.1x makes your ports secure by making the user authenticate against the active directory before allocating a vlan. This means if you are not an authorised user, you won’t get a vlan assigned on the port you are connected to. Moreover, security is further enhanced through the use of policy groups on the Network Policy Server (NPS). This means vlans can be associated with groups on active directory. To further elaborate this, consider the following scenario:

You have a dev/sysadmin or a network engineer on port gi1/0/35 on the switch with vlan 50 configured manually. This vlan has privileges to access almost all the resources on the network including key PCI or PII resources. It’s all fine if the right person is connected on that port. However, in case of a desk move, a marketing user can find himself connected on port gi1/0/35 with PCI level privileges. This is a considerable security risk as the first line of defence which is lack of reachability has just been broken. Anyone can connect on port gi1/0/35 and use hacked credentials of a privileged user and access PCI data. This might sound remote but it has happened before and corporations shouldn’t take risks like these that can damage their reputation and adversely affect business on a large scale.

802.1x has been around for a while now but a lot of business have shyed away from it predominantly because of negligence in their security model and the fact that it’s just not been high enough in their priority list. This, on top of laziness on part of the network team is usually to blame as 802.1x deployments are usually tedious and require a lot of troubleshooting to get it right. Therefore, instead of pushing this crucial port security method, a lot of times network engineers find it easier to pre-configure vlans on ports!

What most businesses don’t take into account is the overhead of network resources utilised upon port changes etc in the form of excessive tickets in the ticket queue. With 802.1x, you take all that hassle away and never have to worry about port moves performed by the desktop engineering teams.

I have to admit, whilst 802.1x was easy to understand (you can read the RFC here), it was one of the most painful deployments I have carried out to date.

The purpose of this post is NOT to scare you away but to encourage you to deploy 802.1x in your office network too.

I have gone through the hard work so you don’t have to. Most of the painful moments came whilst testing and trying to get the protocol to work properly in a lab environment.

I would highly recommend you go through the guides below and implement this in your office today.

MAB: Mac Authentication Bypass on 802.1x
NPS settings for Mac Authentication Bypass (MAB) using 802.1x
Microsoft Network Policy Server (NPS) configuration for 802.1x authentication using PEAP
802.1x (dot1x) configuration guide for cisco switches (Including IP Phones)

The guides are pretty self explanatory but in a nutshell, you have two kinds of devices in offices over a wired network. Ones that support EAP and others that don’t.

EAP is the protocol that is used to authenticate a device. A port configured using 802.1x simply discards all packets apart from EAP packets. It then authenticates the device by contacting the NPS and then dynamically allocates the correct vlan on the port. Devices that fall under this category are all your laptops that are osx, windows or linux based. Other devices might support 802.1x too and it’s best to check by following up with the vendor’s documentation.

Devices that don’t support 802.1x can use MAB, i.e. Mac Authentication Bypass. What MAB does is pickup the registered mac address on the port and try and authenticate with the NPS using that mac address instead of a userid/password with radius. Generally, best practice is to prioritize MAB on your port so that the switch tries to authenticate using MAB first before reverting to EAP. This way all devices with registered mac address on the NPS easily get a vlan assigned to them.

One important thing is you might have to turn 802.1x ON on end devices so that they can take part in the EAP process. Normally, as soon as you plugin and end device that is osx, windows or linux based, the NIC simply sends a broadcast dhcp request to the network and waits for a DHCP offer from the DHCP server. This would mean when the switch port is configured with 802.1x, it would listen for EAP packets only and discard ALL other traffic. This means, the end device has to take part in the 802.1x process. In my experiece, Linux and Osx detect 802.1x packets themselves and inform the user to end userid and password to authenticate with a prompt. If they don’t it’s a simple option in the network settings. Windows however, is a different ball game!

With Windows, you will have to change Wired AutoConfig to automatic and ensure the service is always in START state.

This can be achieved by searching for services from the start bar and selecting Wired AutoConfig in the window that opens up as shown below:

 

Once the wired AutoConfig tab opens up, simply start the service and set it to automatic to ensure it always runs upon boot.

 

This would now ensure the windows machine now takes part in 802.1x process. That said, most organizations are 90% windows and 10% other devices. Therefore, it would be better to make this change in your whole estate via the use of a GPO policy. If you are not incharge of managing the windows estate, than usually this falls under the windows team in your business who can help you with this.

There is a lot more to it than just a few paragraphs but if you refer to the guides and examples referred above, you should be able to test and deploy a working solution with ease.

Last but not least, Wifi deployment is pretty straight forward. You just have to create a similar policy to wired in the NPS and make your APs request 802.1x authentication for each SSID you want to perform 802.1x authentication on. This is pretty straight forward and in my experience is the easiest part of the whole cycle to implement but you have to follow the documentation provided by the vendor of your wireless Access Points to achieve that. The NPS policies on the other hand, stay the same as defined in the above guide.

The end result:

After implementing it all, I was simply blown away when it all came together on day one of the office going live. Almost all users reported seamless connectivity. All devices such as printers, cctv camera etc simply had a dynamic vlan assigned. I being the network engineer would get high privileges on each port I connected on! This was a much smoother deployment than any office I have deployed so far with Ansible being the icing on the cake.

Upon the next office deployment, I will simply churn out the configuration files within minutes and with all 802.1x NPS policies already configured and in place, I now have the ability to configure and deploy an office in ONE DAY!

Imagine the time this has freed up for me and the rest of the team to perform other tasks!

Happy Networking 🙂

Got questions? Leave a comment! Let’s chat.

Rafay Rasool is a Network Specialist with over 8 years of experience designing, configuring and implementing core network solutions based predominantly but not limited to Juniper Routers, Switches and Firewalls along with other vendors such as Cisco, Huawei, Siemens, Aerohive, Ringmaster, Pulse etc for Internet Service Provider and Enterprise Networks.

Rafay is an avid supporter of network automation and likes to code and automate networking solutions.