Move your VMware and KVM applications to the cloud without making any changes

Build & test network security architecture using enterprise replicas on AWS & Google Cloud

Author: Matt Conran
Matt Conran is a Network Architect based out of Ireland and a prolific blogger at Network Insight. In his spare time he writes on topics ranging from SDN, OpenFlow, NFV, OpenStack, Cloud, Automation and Programming.
Colocation with third-party network elements/servers in demilitarized zone (DMZ) is an issue for security architects and puts pressure on network security architecture. How do we connect third party equipment to inhouse security appliances in a flexible way? This is an issue for many large financial & health care institutions, and other enterprises that have to securely connect 3rd party equipment. The placement of servers may be limited to certain parts of the network and traditional ways to connect lead to inefficient use of physical resources. BGP+ VXLAN + VRF helps solve this issue by dynamically creating tunnels between endpoints offering a lot more flexibility to device placement. This allows traffic from newly installed equipment to be dynamically sent to a security device for scrubbing and analyses before forwarding on to its final destination. Ravello Network Smart Labs helps enterprises in building and testing this new network security architecture on cloud - which helps keep enterprise secure.


Pressures on network security architecture

TCP/IP was developed in an age when there was little or no security threats. The focus of the connectivity model was simply to connect endpoints. It has no way of knowing if packets are tampered with. It was later extended with other frameworks, such as Internet Protocol Security (IPsec) to enhance security functionality but initially it started insecurely. The Internet has changed since then and so too the endpoints it serves and connects together. This leaves us with no option but to pay more attention on how we secure connections, not solely on endpoint connectivity. Attackers now have the ability to easily bypass traditional security mechanism. There are so many threats out there that we need to protect against - DNS spoofing, man-in-the-middle, ARP poisoning, smurf attacks, buffer overflow, heap overflow and many cyber threats. This is even more of a concern as many consumable services are available on the public Internet. Due to its user base and wide reach, the Internet is becoming the sole foundation for numerous company services. Business rely on the public Internet to host services.


Changing applications & access drive new needs

It is no secret that we are on the back foot when it comes to security. In today's world protecting data is increasingly difficult due to the wide range of security threats and attacks. The cyber threat landscape has increased due to the change in applications and connectivity models. Nowadays, we have more than just a roaming PC connecting over the Internet to headquarters. We have a variety of endpoint types and connection mediums to public / private clouds. All of which need to connect securely. The application is no longer deployed on a single service housed in a location with single ingress / egress traffic points. It is broken up into multiple services, dispersed on a variety of physical nodes and locations. All components require cross communication and dynamically scale based on traffic load. There has been such a rush to market with new technologies. Some may feel as long as you can connect then the job is done. Cloud data centers need to take on a new flexible cost effective design in order to meet the needs of the changing landscape. The design must be scalable while not to jeopardise protection from both outside and inside threats. Routing with VXLAN is a flexible way to tunnel to security appliances.


Traditional DMZ design

Traditional demilitarized zone (DMZ) design have a very modular approach. Modularity in network designs enables isolation allowing boundaries to be designed in networking. This is one of the reasons (por count was the main one) why we started with core, access and distribution and other Internet and DMZ edges. The DMZ and Internet edge were at the top of the network, all ingress and egress traffic flows through these devices. The majority of IPS/IDS would also be at this layer, analysing and looking for unusual traffic patterns. Depending on designs, it may have been the case that some internal traffic had to pass through them too. There wasn't any overlays sticking together applications or remote paths. Everything was very static. The DC designs we recommended 5 to 10 years ago are very different to what we have today.


Business needs changing the DMZ designs

We are seeing these designs come to play with colocation requirements, especially in financial network designs. Financial institutions operate their own networks. It's too sensitive to outsource and most have large MPLS based backbones. Usually dual MPLS networks with separate vendor appliances for each network. They may provide a lot of their own network infrastructure but they usually cannot provide everything to support the wide variety of applications and services. This is where they have to colocate third party equipment into their private data centre. Now that we have third party infrastructure how do we physically and logically connect it securely? Traditionally, third party equipment could be placed in a separate third party rack and physically connect to an intermediate switch or router. This type of design does not save on physical resource as you could end up with just a single appliance per rack. Also, once the third appliances are installed it must be logically integrated. A more flexible method could be to combine VXLAN/VRF and BGP to create layer 2 tunnels between the third party node to a firewall for scrubbing. In the supporting blueprint, the ToR switch encapsulates the traffic and sends it to a VTEP that sends to the Palo Alto firewall. The main benefits is that the third party equipment can be physically located anywhere in the network. It doesn't need to go to a dedicated rack. This save on physically resource and money. VXLAN, VRF and BGP can now be combined to provide a very flexible DMZ and security services POD infrastructure. Macrosegmentation is a new feature that can be used in DMZ and security PODs. It allows the integration of security services into cloud data centers. Its prime focus is on security integration by instantiating a logical topology to enforce security services. This gives you complete flexibility for underlay network design and no changes to the underlay are needed. There is no need to change operational models or ownerships rules, the firewalls still carries out the firewall rules. Recent, VM-NIC and some other distributed firewall services are placed closer to the workloads. However, these designs completely change the security paradigm which may be challenging for some big financial security audits, potentially unnerving security architects.


Flexible Network Security Architecture

Leaf and Spine designs are becoming the de facto design for cloud data centres enabling new security architectures. They fall into either a Layer 2 or Layer 3. Layer 3 designs are commonly deployed with Border Gateway Protocol (BGP). BGP is more stable and less chatty than an interior gateway protocol (IGP), like Open Shortest Path First (OSPF). It’s also easier to troubleshoot when things go wrong. Leaf and spine provide ECMP needed to support active redundant paths and agile data centres. Once the underlay has a solid design, it's easier to build a flexible overlay with all the security features and functionality you need. The benefits of an IP underlay far outway a Layer 2 underlay. IP underlays enable full separation of broadcast domains between racks. They are very scalable and the spine is no longer limited. One of its main benefits is that we are relying on a testing protocols of IP that has been around for an age. A solid network design would be a Layer 3 leaf and spine with some kind of overlay on top of it. The combined underlay and overlay design offers layer 2 mobility without sacrificing the scalability of the spine layer. VXLAN was originally viewed in the network virtualization world. Applications could no longer be supported with single segment designs, commonly broken up into a number of tiers. We needed multiple segments for individual load balancing, front and back end firewalling tiers. For large data centers VLANs could never meet this. For multi tenant cloud deployments, VXLAN enables 16 million independent domains.


VXLAN routing in VRF

VXLAN, VRF and BGP are combined together to provide a very flexible security domain when connecting up devices over an IP core. The VRFs only need to reside on the leaf switches. INGRESS would include VRF>VLAN>VNI and EGRESS would be VNI>VLAN>VRF. Essentially we have a VRF>VLAN>VNI>network>VNI>VLAN>VRF setup. VXLAN routing in VRF over an overlay enables very flexible designs and device placement. It is a useful feature for financials when deploying colocated space for third party equipment.



A more efficient network security architecture is to group all security and network services into separate PODs. Security and network services have different workloads that normal VM’s. They require more I/O, server hardware must be selected accordingly. An ideal place for security services is to have them bundled within POD in a Layer 3 leaf and spine design. It makes more sense to have all security appliances in one place. However, then comes to question of how do we route or switch traffic to these services appliances? The ability to connect appliances with BGP + VXLAN tunnels offers flexible network security architectures. If you already have BGP in place extensions can be used to create an overlay linking up appliances. Ravello Smart Labs to create replicas of enterprise DCs to model/build and test this sort of environment. Follow this link to the VXLAN + BGP + VRF blueprint created on Ravello Labs. Add it to your Ravello account and customize it for additional security configurations.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.