Whether we work together IRL at an office or online in a WebEx window, conversations among software engineers naturally turn to “what’s new in your tech” and “I have this problem—any ideas”. Recently, both topics coincided with a conversation I had with a remote co-worker who had a particularly tricky networking issue. One that I happened to be currently working on. I’ll let you in on the conversation in hopes that it can help you too if you are a developer using VMs on your laptop for development or using tools that require a specific OS—such as an onsite service technician running diagnostic software in a VM.
“In my development team, we are using laptops like mobile servers. I am running multiple VMs in my laptop for some development work, testing an app, and running some special applications. However, my current setup has limitations as I must use NAT so that the setup enables me to work on the go and I can avoid leasing the VMs from a cloud. The sad part is, now I’ve learned that I must get rid of the setup due to security concerns. My IT department detected that I am using the VMs in my device and ask me to remove them even after providing the details of why VMs are part of my work. IT said running VMs is a security risk as IT and Security group cannot manage or place policies on these VMs within the network. So, I’m not sure what I should do.”
“That is an interesting problem. Wireless networking does not allow devices with VMs to have their own identity, like MAC, without dedicated radios. It’s a difficult problem for IT and Security teams to secure a network as they have no control over detection and prevention of VMs even if a VM is approved by IT to run on a server or wired host without NAT. Today some network equipment vendors support a NAT detection feature that helps IT to detect NAT-enabled devices and to take manual steps to prevent security lapses. According to one IT manager I talked to, this is most concerning problem that they have in their network.”
“Indeed! In fact, I have been working on this scenario recently. Within Software-Defined Access we developed a patent pending solution that addresses this requirement. Cisco SD-Access with Fabric Enabled Wireless, or FEW, solution detects if there is any NAT device in the network and alerts NetOps. One of the actions they normally take is to block the device from entering the corporate network segment or anchor it to a quarantine segment until you, the owner, take appropriate action. This is still not an adequate solution since access to real applications and productivity tools is still not feasible.
A new feature is available in FEW called Virtual Bridge Mode, which would remove this limitation and enable you to use your VM tools effectively without worrying about security. For NetOps, it is easy to manage with segmentation. Let me explain how it works.
A wireless host enables bridge networking to its guests, such as VMs. A host uses its MAC for all external network communications from guests. The SDA fabric detects these hosts through DHCP, authenticates, and assigns IPv4 or IPv6 address to each guest based on Fabric Policy. No other changes in wireless network configuration are needed in the Fabric. Network admins can anchor these guests to a segment (SGT) and apply policies. An example of such policy is that these guest VMs can only reach to the application hosted on this segment.”
“In an SD-Access Fabric, every device—be it wired, wireless or guests hosts—once authenticated is treated the same. The authenticated VM acting as NAT device is detected by the NAT detection service and the appropriate policy will be applied on the VM and the device hosting the VM.”
“Excellent! Let me reach out to my IT team if they can implement this solution so we can get on with our work.”
And sometimes, that’s the way technical innovations are implemented: one conversation at a time. Your turn.