The EU General Data Protection Regulation (GDPR) legislation has begun impacting businesses and organizations in various ways, and we’ve covered a number of these in this series of stories here on our TechGenix site. While much of our coverage has focused on the possible impact of GDPR upon North American companies, even our across-the-water neighbors on the European continent are seeing the effects of this legislation in various ways.
One of the more interesting examples I’ve come across recently is that of my colleague Martin Urwaleck, who resides in Vienna, Austria, and manages IT for a public company there. Martin has been working in IT for almost two decades and was previously head of desktop and shop operations for a company in Hamburg, Germany. When Martin arrived at his new position he was faced with a number of tasks, one of which was to ensure their computer network was in compliance with GDPR requirements and the other ensuring their network performs properly. The problem he faced in the first regard was an interesting one: The company’s network consisted of two separate networks located at different locations connected via a site-to-site connection, but the IP addresses of both networks have been allocated from the same Class B pool of addresses. As we’ll see in a moment, this presented a problem as far as GDPR compliance was concerned. Martin was tasked with finding a solution, and this turned out to be implementing an older but tried-and-true networking technology called VLAN, which stands for virtual LAN or virtual local area network and using this technology to segment the company’s network.
I recently had an exchange of emails with Martin to find out more about the challenges he faced during his network migration project and how he used VLANs to craft a suitable solution which he is currently in the process of implementing. I’m sharing his story here so readers who are facing similar challenges can glean some guidance. Because companies merge and acquire each other all the time, so you never know when you might be faced as an IT professional with a challenge of this nature. Please note that because English isn’t Martin’s first language, I’ve had to edit his responses somewhat to clarify.
MITCH: Hi Martin, I understand you’re working on a network migration project of some sort that tries to segment a single Class B network. What’s the motivation for undertaking this challenge?
MARTIN: The reason is twofold. First, running 50 servers and 150 clients in one network means a lot of basic noise due to the nature of TCP/IP because all Layer 2 broadcasts are propagated to the entire network. Also, from a security perspective, it’s grossly negligent running all clients and servers in the same security zone. New trends in networking are heading in the direction of “trust nobody” and even in the public corporation where I work, which is a very conservative corporation, the first cloud applications are appearing where we don’t know exactly what they are doing on the client. It’s an increase in security risk we need to handle!
MITCH: So your company has two sites (let’s call them A and B) but addressing on both networks is assigned from the same Class B network?
MARTIN: Exactly, which is a big issue since the traffic between the sites is running over dark fiber that is unencrypted over public areas. And GDPR requires encryption on all traffic leaving your own properties.
MITCH: So what sort of strategy or process are you planning to use for performing this migration?
MARTIN: Our approach is pretty simple. We establish on both of our sites a high availability pair of firewalls that run inside our existing Class B network. By high availability, I mean that there are two firewalls at both sites dual-homed to the redundant core switches of each site (which means 4 NICs per firewall) in an active-passive configuration. The redundant firewall kicks in whenever the heartbeat between them is missing.
Then we add a bunch of VLANs on both sides and move existing clients from their current network into these new VLANs. At that point in time, we don’t add any restrictions in the firewall between these new VLANs, we just clean up the house and put everything in the right destination VLAN.
As soon as that step is finished, we switch the site-to-site communication, which is currently transparent, to an IPsec connection to secure that line.
The hardest part will be next: starting the firewall configuration to close down allowed communication to only what’s absolutely necessary. I expect the last part to be the longest, maybe taking months.
MITCH: Why use firewalls instead of just routers on the ends of your site-to-site link?
MARTIN: Well, the basic idea is that I will have two sites connected via an IPsec tunnel and I want to segment my network on both sides. The added value of using a firewall compared to a router is that I can easily manage inter-segment traffic, for example by allowing all PCs to use all printers in all segments, but no PC-to-PC connection. Or blocking direct client traffic to a database since the users are using applications running on the server. In other words, the idea is to limit certain traffic to a network segment. So, if ransomware hits, for example, only one segment is affected as segment-to-segment traffic is blocked.
MITCH: So once all the hosts have been moved to VLANs you then connect the sites via an IPsec connection?
MARTIN: No, the IPsec link is already established even before starting segmenting. For example, we recently established our first segment with a new office and now we are learning what we have to consider for the next segments. I hope to have reached 50 percent done by the end of the year.
MITCH: Are there any other difficulties you expect to encounter along the way?
MARTIN: I expect a lot of interesting discoveries because our documentation varies in quality depending on who maintained it. There’s a lot of stuff like A/C controllers, security devices, locking systems, and so on that are not maintained by IT; we just provided an IP address and add an external firewall rule. But I don’t expect anything that could stop our project. It might just add delays and additional efforts.
MITCH: What advice would you offer to network admins facing a similar kind of network migration challenge?
MARTIN: Honestly, I hope that no one reading this has that kind of network design anymore, it’s so 1980’s! My advice would be to get in touch with someone who has experience in network design and let them build up the new design. As soon as you have the target design, it’s easy to plan the migration. In fact, if I didn’t need to increase our security as part of my project, I could probably do everything using only my current hardware, so often there is no need to invest in new hardware for something like this. So, the financial impact is just hiring a good network designer.
MITCH: Thanks, Martin, for taking the time to answer all my questions! And good luck with finishing off the migration!
MARTIN: You’re welcome and thank you.
Featured image: Pixabay
