Virtual Firewalls

The source for this blog post is taken from Ivan Pepelnjak’s recent webinar on Virtual Firewalls.

IP networks deliver a range of services to consumers and business. As a result, they heavily rely on network availability for business continuity and productivity. As the reliance on IP networks grows so does the threat and exposure to network-based attacks. New technologies and mechanisms address new requirements but they also come with the associated risk of new threats. It’s a constant cat and mouse game. It’s your job as network admins to make sure the IP network and related services remain available at all times.

Firstly, a thorough understanding of the different types of traffic that enters and leaves the network is critical. Network devices process some packets differently to others, resulting in different security implications. Transit IP packets, receive-adjacency IP packets, exception and non-IP packets are all handled differently. You also need to keep track of the plethora of security attacks such as resource exhaustion attacks (direct attacks, transit attacks, reflection attacks), spoofing attacks, transport protocol attacks (UDP & TCP) and routing protocol / control plane attacks. There are a variety of attacks against Layer 2 including MAC spoofing attacks, STP attacks and CAM table overflow attacks. Overlay virtual networking introduces two control planes, both require protection.

The introduction of the cloud and workload mobility is changing the network landscape and security paradigm. Workload fluidity and the movement of network state is putting pressure on traditional physical security devices. It’s difficult to move physical appliance around the network. Physical devices cannot follow workloads, which drives the world of virtual firewalls with NIC based Firewalls, Microsegmentation and Firewall VM based appliances.  


Session State

Simple packet filters match on Layer 2 to 4 headers – MAC, IP, TCP and UDP port numbers. If they don’t match on the TCP SYN flags it’s impossible to identify established sessions. Tracking the state of the TCP SYN tells you if this is the first packet of a session or a subsequent packet of an existing session. Matching on TCP flags allows you to differentiate between a TCP SYN and SYN ACK and ACK. Matching established TCP sessions would match on packets with the ACK/RST/FIN bit set. All packets without an SYN flag will not start a new session and all packets with ACK/RST/FIN can appear anywhere in the establish session. Checking these 3 flags indicates if the session is established or not. In any properly implemented TCP stack, the packet filtering engine will not open a new session unless it receives a TCP packet just with the SYN flag. In the past, we used a trick. If a packet arrives with a destination port over 1024, it must be a packet from an established session as no services were running on high number ports.

The term firewall originally referred to a wall intended to confine a potential fire. A firewalling device in terms of networking refers to a barrier between a trusted and untrusted network. It can be classed into a number of generations. First-generation firewalls are simple packet filters, second generation refers to stateful devices and third generation refers to application based firewalls. Just because a firewall is stateful doesn’t mean it can examine the application layer and determine what users are doing.

Firewalls initially started with packet filters at each end and an application proxy in the middle. The application proxy would do the application level inspection and the packets filters would carry out basic scrubbing. All sessions terminate on the application proxy where new sessions are initiated. Second generation devices came into play and we started to track the state of sessions. Now, we have a single device that can do the same job as the packet filter combined with the application proxy. But it didn’t inspect at an application level. The devices were stateful and could track the state of the session but they could not go deeper into the application. For example, examine the HTTP content and inspect what users are doing. Generation 2 was a step back in terms of security. We then moved into generation 3 or what marketing people like to call next-generation firewalls. They offer Layer 7 inspection with packet filtering. Niche devices started to emerge called Application-Level Firewalls, usually only concerned with HTTP traffic, also known as Web Application Firewalls (WAF). They have similar functionality to reverse web proxy, terminating the HTTP session.


Virtual Firewalls

Almost all physical firewalls offer virtual contexts. Virtual contexts divide the firewall and solve many multi-tenancy issues. They provide separate management plans but all the contexts share the same code. They also run over the same interfaces competing for the same bandwidth so if one tenant gets DoS attacked the others might be affected. A major drawback to virtual contexts is that they are tied to the physical device so you lose all the benefits of virtualization, unlike VM based firewalls.

A firewall in a VM can run on any transport provided by the hypervisor. The VM simply thinks it has an ethernet interface. This enables you to put a VM based firewall on top of any virtualization technology. Physicals firewall must be integrated with the network virtualization solution and many vendors have limited support for overlay networking solutions. Just because the physical interface supports VXLAN it doesn’t mean it can support the control plane that the overlay network solution is running. For example, the network overlay solution might be using IP multicast or OVSDB or EVPN over VXLAN. Deploying Virtual firewalling offers underlay transport independence. They are flexible, easy to deploy and manage.

Traditionally, we used VLANs and IP subnets as security zones. This introduced problems with stretched VLANs so then they came along with VXLAN and NVGRE. But we are still using IP as the isolation mechanism. Generally, firewalls are implemented between subnets so all the traffic goes through the firewall, which can result in traffic trombones and network chokepoints. The new world is all about VM and NIC based firewalls. NIC based firewalls are mostly packet filters or at the very most reflective ACL’s. Vmware NSX distributed firewall does slightly more with some application level functionality for SIP and FTP traffic.  




NIC based firewalls force you to redesign your security policy. Now, all the firewall rules are directly in front of the virtual NIC, offering optimal any to any traffic between VMs as traffic does not need to go through a central firewall device. The session state is kept local, only specific to that VM. This makes them very scalable. It allows you to get rid of IP subnets as security zones and provides isolation between VM’s in the same subnet. By design, this protects individual VMs so even if an attacker breaks into one VM, all others are protected. VMware calls this micro-segmentation in NSX.

You can never fully replace physical firewalls with virtual firewalls. Performance and security audits come to mind. However, they can be used to augment each other. NIC based for east to west traffic and physical firewalls at the perimeter to filter north to south traffic.






About Matt Conran

Matt Conran has created 168 entries.

Leave a Reply