Network Engineering - Ashburn Consulting LLC


Next Generation Firewall Overview with Glimpse of Application Identification

“I am not an advocate for frequent changes in laws and constitutions, but laws and institutions must go hand in hand with the progress of the human mind. As that becomes more developed, more enlightened, as new discoveries are made, new truths discovered and manners and opinions change, with the change of circumstances, institutions must advance also to keep pace with the times. We might as well require a man to wear still the coat which fitted him when a boy as a civilized society to remain ever under the regimen of their barbarous ancestors.”

-Excerpted from a letter from Thomas Jefferson , July 12, 1816

Interestingly, Thomas Jefferson’s quote could not be more appropriate when assessing todays state in IT Network Security. When people hear IT Network Security one of the first devices that come to mind is a firewall. Early firewalls started out as not much more than an extended access list. As security requirements grew Stateful packet inspect was introduced by Check Point Software to address several security issues with most notably being certain types of man in the middle attacks (MITM). As stateful inspection began to take off many network engineers found difficulties in implementation among some issues asymmetric routing became an issue that required engineers to control network paths with a fine tooth comb to confirm forward and reverse traffic were taking the same route back and forth or it would be dropped due to stateful inspection. Part of the reason for this introduction was to reduce the capability for a man in the middle attack to be intercepting traffic and sending it back without the end user being aware their network traffic had been compromised.

Fast forward back to the present and Next Generation Firewalls (NGFW) and layer 7 inspection are introducing a new evolution in IT security whose functionality is critical to todays’ IT security landscape. With many vendors introducing their own take on layer 7 inspection the importance of this new upgrade in capabilities is more apparent than ever akin to when stateful packet inspect was originally introduced. Most firewalls previously are port based in the sense that port 80 and 443 may be open outbound to allow web and ssl traffic.

With that knowledge a malicious user could exploit this port based firewall by running any application over these ports even though they were originally designed with the intent for web browsing and ssl traffic. A malicious user could run any application they desired over open ports without any restriction including unwanted chat and bit torrent clients up to and including applications like nmap without the restriction of being blocked by a firewall without another security applicance on the network capable of application inspection.

NGFW’s enable network security engineers to not only restrict ports but also applications and ports, they do this by inspecting IP packets for what data is inside the packet header beyond the traditional source/destination and port. This visibility into traffic is critical to enabling an engineer the capability to not only restrict port but also only allow web-browsing over port 80 or only ssl traffic over 443, and disabling any traffic that does not have web-browsing requests or ssl in the IP headers and blocking a malicious users ability to run other applications like torrents or nmap over that port or even save bandwidth by stopping applications like youtube google-hangouts, facetime, minecraft and other applications that may be unwanted on the network.  In figure 1, in addition to source/destination you see a user viewing youtube over port 443 which is traditionally open, the functionality of this firewall will enable a Network Security Engineer to only allow ssl and web-browsing while blocking youtube. It is important to note that encrypted ssl traffic can be decrypted however that will be touch on in a separate article.


This new capacity requires specific configurations to implement correctly. During migrations many engineers lacking knowledge of why some traffic may stop working due to new application layer rules may cause openings in security to increase usability by removing some of the application layer configurations. This trade off is not using this new technology and functionality correctly and is effectively putting a child’s coat on an adult, it does not fit according to how the IT security landscape has evolved. Implementing this technology is critical to providing secure and trusted network traffic transactions and assist in disabling a malicious users ability to abuse legacy firewall functionality.

ICMP Security

This is a draft guide to handling ICMP securely.

Guide Analysis to Handling ICMP protocol


This guide is an attempt to help answer common questions related to the handling of ICMP protocol in a secure and effective manner. Comments and feedback is always welcomed. This article is meant to cover the major area in which there may be questions on how to handle ICMP and what specifically should we allow in each particular condition which will also allow for effective risk mitigation. If you need specifics on ICMP codes with in each ICMP type please refer to the reference URLs below.

Major ICMP Protocol Types:

– 0: Echo Reply

– 3: Destination Unreachable

– 4: Source Quench

– 5: Redirect (change a route)

– 8: Echo Request

– 9: Router Advertisement

– 10: Router Solicitation

– 11: Time Exceeded for a Datagram

– 12: Parameter Problem on a Datagram

– 13: Timestamp Request

– 14: Timestamp Reply

– 17: Address Mask Request

– 18: Address Mask Reply

Areas of Affect:


Outbound: Echo Reply (0), Echo Request (8) (For Troubleshooting)

Deny Type: All except (TTL Exceed (11) & (Type 3, Code 4) From Limited External Testing Devices.

Interior (Corporate Network)

Internal Deny:  Should be handled on a case by case basis, however when permissible squelch Redirect (5), Router Advertisement (9), Router Solicitation (10), Timestamp Request (13), Timestamp Reply (14). Address Mask Request (17), and Address Mask Reply (18). The usefulness of the ICMP message types are deprecated by DHCP and NTP.

Internal Allow: Echo Reply (0), Destination Unreachable (3 Code 4), Echo Request (8), Time Exceeded (11)

Remote Access & Site to Site VPN

VPN Allow: Echo Reply (0), Destination Unreachable (3, Code 4), and Echo Request (8).

VPN Deny: Everything Else

Intranet to Intranet / Partner to Partner

Intranet to Intranet Allow:  Echo Reply (0), Destination Unreachable (3 Code 4), Echo Request (8), Time Exceeded (11)

Intranet to Intranet Deny: Everything Else




University of Syracuse ICMP Lecture Notes

Layer 2 Tracing for (6500, 7609, 4500) Cisco Switches

In a 6509, 7609 or any Chassis based Cisco switch, to determine where the switch forwards a Source and Destination pair to an actual port in a Port-channel/Etherchannel do the following commands:

Note: Doesn’t apply to Nexus switches.

First enter console for switch:

port-channel hash
Switch# remote login switch
Trying Switch ...
Entering CONSOLE for Switch

Then enter the following command:

port-channel hash
Switch-SP# test etherchannel load-balance interface port-channel 1 ip
Computed RBH: 0x6
Would select Gi2/1 of Po1

Based on the hash computation, the switch forwards traffic of the Src Dst pair to port Gi2/1.

This is a good tool to use if for some reason a particular port is dropping packets between the src and dst pairs.

MPLS L3 VPN White Paper

Enterprise Network Design White Paper
For Metropolitan and Campus Networks –
Robert Shields
Sr. Network Engineer, CCIE # 12096 
January 2012 
Enterprise Network Challenges of Today and Beyond 
Enterprise network and security managers continue to see their responsibilities increase within their respective IT organizations as applications and services continue to migrate to IP as a fundamental means of communication. These applications and services include telephony, video, wireless and mobility clients, storage area networks, etc., with the list going on and on. The reality today is that most enterprise networks are now converged IP services networks with many different and diverse customer requirements. With the network requirements changing to resemble more of a service provider model, so too should the network architecture model. 
Enterprise networks traditionally supported server-based data applications, many of which were deemed critical applications, which could be secured with a tiered firewall architecture in the data center. Today, all types of new devices and appliances are being plug into the Enterprise IP network at numerous locations and they all have their own security requirements. Compound this by the new technical challenges of the day, including server virtualization, cloud computing, business continuity, and IPv6, and there is no lack of pressure on the network and security IT groups in providing a secure, scalable, and robust network environment that can continue to meet the challenges of today and the future. 

MPLS L3VPNs – Providing a Flexible Network Architecture Solution 
This white paper focuses on how MPLS L3VPN technology can provide many benefits to Enterprise networks by enabling a flexible network architecture that can accommodate a diverse set of customer requirements across a Metropolitan Area or Campus network. These benefits stem from the ability to logically segment or virtualize the network into multiple isolated routing domains called VPNs. The following is a list of the benefits that MPLS L3VPN can provide.

  • Reduced Cost – L3VPNs allow multiple networks to be converged into a single network while still maintaining their privacy from one another. These results in less infrastructure devices, less power consumption, less vendor support contracts, and fewer personnel required to maintain multiple networks.
  • Network Virtualization – Major router manufacturers support literally thousands of virtual networks to be configured across the shared Enterprise network, thus supporting traffic isolation for specific applications, services, user groups, agencies or divisions, or any other type of isolated IP transport requirement.
  • Routable DMZs/Centralized Firewalls – By connecting the L3VPN network to a centralized firewall architecture at a physically secure data center, this essentially enables a VPN to become a boundless internal DMZs that can be extended anywhere across the Enterprise network. These DMZs will still have the ability to communicate back to a main corporate network through an approved security policy, thereby allowing access to common network services such as DNS, DHCP, SNMP, etc., while still severely restricting the vulnerability that this DMZ can pose to the internal network. Other data access or communication requirements between different DMZs/VPNs could also be granted and added to the security policy on a case by case basis. The L3VPN architecture also eliminates the need to deploy firewalls at remote sites where physical security of these devices cannot be as easily assured, since alternatively a new VPN could be created and mapped back to the centralized firewall systems.
  • VLAN to VPN/VRF Mappings – The ability to map VLANs into VPNs will be explained further throughout this document, but for now the beneficial point to make is that not all network devices need to be MPLS or VPN/VRF aware. Only the core or backbone routers will need to be evaluated to run this technology and not all the edge sites. Some edge routers may need to support VRF-Lite, which is a scaled-down version on the technology that does not require MPLS. This keeps the initial investment down and also allows a seamless and phased migration approach when transitioning to the new network architecture.
  • Additional Services Supported by an MPLS Backbone – In addition to L3VPNs, there are other services that the backbone network will be able to support as a result of having MPLS enabled. L2VPN technologies such as pseudo-wire and VPLS can also be deployed rather easily once an MPLS core is achieved.

These benefits will be illustrated and substantiated further in the MPLS L3VPN architecture example that is described later in this document. A brief and high-level overview of the MPLS L3VPN technology is described next to ensure conceptual understanding of how traffic is isolated across the shared backbone infrastructure. 

Overview of MPLS L3VPN Technology 
There are a several main concepts that network and security managers should understand with L3VPNs.

  1. Routers maintain separate routing tables for each VPN that they are connected to, called Virtual Routing and Forwarding tables (VRFs), thus VPN and VRF are used synonymously with one another when describing these isolated routing domains.
  1. Any IP packets that enter the MPLS L3VPN backbone network must enter on either a physical or logical interface that is defined to be within a specific VRF. Once a packet enters on an ingress VRF interface, it can only exit out an egress interface that is in the same VRF. This ensures that traffic is isolated between different VRFs. Examples of logical interfaces are sub-interfaces or VLANs on an 802.1Q tagged port.
  1. The ingress router for an IP packet entering the MPLS L3VPN backbone is called the Provider Edge (PE) router. As part of the intricacies of the technology, MPLS label switch paths (LSPs) are built in a full-mesh topology between all the PE routers in the backbone network. Therefore, when an IP packet enters through a VRF defined interface on the backbone network, one IP routing table lookup occurs at that PE router (within that specific VRF table), and the result is the packet gets forwarded to the appropriate LSP and is then label-switched through the MPLS network until it exits the associated egress port for its destination. These efficient techniques of a single IP lookup and label-switching packets through the network result in the technology being very secure and scalable.
  1. Routers that connect to an L3VPN network are referred to as Customer Edge (CE) routers. Although these routers are referred to as “customer” routers, they can certainly be managed by the same Enterprise network group that manages the MPLS or PE routers. CEs that need to connect to two different VPN subnets on the MPLS core will need to run VRF-Lite. VRF-Lite enables a router to function as a stand-alone virtualized router – following the same principals of L3VPNs; multiple VRFs can be configured with physical and/or logical interfaces defined within the VRFs (no MPLS). A CE can also be a L2 switch with just a trunk port to the PE.

All of these concepts are illustrated in the Figure 1. CE1 has two LANs that need to communicate using the L3VPN core using two different VPNs. VPN A is colored in blue, and VPN B is in red. Therefore, CE1 must connect to the MPLS network using either sub-interfaces or a trunked (IEEE 802.1Q – tagged) link so that the PE can define these logical connection into the appropriate VPN/VRF. Notice that PE1 is configured and has knowledge of both VRF tables, while PE2 & PE3 are only configured with the single VRF for which they have a CE connected to. When CE1 sends packets destined to both CE2 and CE3, it is PE1 that does an IP lookup for these packets using the appropriate VRF table, and then forwards the packets onto the correct LSP that will carry it straight out the egress port towards its destination.

Figure 1. – MPLS L3VPN Concepts 
Other technologies that can also be deployed along with L3VPNs include the following:

  • Quality of Service (QoS) – For traffic classification, RFC 4594 “Configuration Guidelines for DiffServ Service Classes” is used as the basis for the recommendations for traffic classification in MPLS L3VPN environment. The 4, 8 and 12-class models can be used for traffic classification.
  • Traffic Engineering (TE) and LSP Protection – TE with LSP protection schemes can be configured to support under 50 ms failover times should a link in the network core fail. TE can also be used to move traffic from over-utilized use links to underutilized links, thus taking advantage of all resources available.
  • Encryption – MPLS does not imply encryption, however several different encryption methods exist if this is required over a L3VPN, including GRE over IPSec, Cisco’s Dynamic Multipoint VPN (DMVPN), and Cisco’s Group Encrypted Transport VPN (GET VPN).
  • Multicast in a VRF – Multicast traffic can be transported across the MPLS backbone on a per VRF basis. Next-generation multicast has recently been deployed by vendors which also contains support for point-to-multipoint LSPs which employ true label switching transport similar to the unicast implementation (previous implementations actually used GRE and the global routing table).
  • IPv6 Transport – While the enterprises slowly move their infrastructure to support IPv6, they can use their existing IPv4 MPLS infrastructure to support IPv6. MPLS L3VPN use IPv6 VPN provider edge (6VPE) approach to transport IPv6 over MPLS network. 6VPE as specified in RFC 4659, “BGP-MPLS IP VPN Extension for IPv6,” it enables the IPv6 sites to communicate with each other using MPLS LSP over MPLS IPv4 core network.

The 6VPE implementation provides scalability with no IPv6 addressing restriction. This mode enables the enterprises to deploy the IPv6 MPLS VPN service over their existing IPv4 backbone by just upgrading the PE router to the dual-stack-capable software. 
This overview was only intended to cover the major concepts of MPLS L3VPNs, for more detailed technical and protocol information, please refer to RFC 4364 “BGP/MPLS IP Virtual Private Networks”.
Legacy Enterprise Network Architectures 
Many Enterprise network today look very similar to the topology depicted in Figure 2 below. Two or more physically distinct networks were built to meet different network and security criteria such as providing services on a Corporate network (a private internal network – only for internal staff use) as well as potentially a Public network (a network open for guests access – primarily for Internet). Also on the corporate side, there are likely some access control lists (ACLs) or Policy Based Routing (PBR) that has been implemented to facilitate requests from certain groups or applications owners that required addition security or access restrictions. These workarounds can lead to increased downtime due to configuration error and extended troubleshooting timeframes. Common network services such as DNS, DHCP, and SNMP will need to be deployed and managed for each separate physical network as well. These techniques are cumbersome to manage and are simply not sophisticated technologies that were intended to support an Enterprise network architecture design. 
Finally, there could also be several firewalls deployed at remote parts of the network to accommodate partner type connections or to securely protect a remote application user group or small server farm. MPLS L3VPN technology can allow the Enterprise network to alleviate all of these unpleasant practices as will be demonstrated in the following section. 
Figure 2. – Legacy Network Architecture 
MPLS L3VPN Enabled Enterprise Network Architectures 
Figure 3 below shows a high-level drawing of a typical Metropolitan Area Network (MAN) or Campus network design using L3VPN technology. Depending on the overall topology of the network, the MPLS L3VPN enabled backbone can include core, distribution, and even some edge site routers. This depends on which sites need the flexible capabilities of MPLS. As Figure 3 illustrates, a typical Enterprise network will have a contiguous MPLS enabled backbone encompassing core routers at the data center and distribution routers, connecting the remote sites. This enables network virtualization within the heart of the network, resulting in the ability to provide flexible solutions for any number of unique network or security related requirements that are needed in the network today or in the future. 

Figure 3. – Example MPLS L3VPN Architecture for MAN or Campus Network 

In this example, we can see several segmented VPNs that are serving different purposes within the Enterprise design. First, there is a “Corporate VRF” (blue) that is isolating the internal staff and data centers from other entities on the network. The corporate network existed prior to the L3VPN implementation, so there are likely several sites with multiple routers that were already running an internal routing protocol such as OSPF. Therefore the “Corporate VRF” can be setup to redistribute routes with OSPF at these locations. Notice that the remote sites each have routers running VRF-Lite with 802.1Q trunked uplinks connecting to the distribution or PE routers, thereby allowing a logical path for the remote Corporate LAN segments to be mapped into the “Corporate VRF” at the distribution routers. The corporate network is also connected to centralized firewalls (dubbed, the “VRF Meet-me Point”), that allows the other VRFs to access common network services (DNS, DHCP, SNMP, etc.) that reside there. 
The second VRF to discuss is the “Public VRF” (red). This VRF shows from our previous legacy network example that a separate physical network is not needed when an additional isolated network is required. Here, a “Public VRF” is created for users who need be allowed guess-type access to the Internet. One topic that is yet to be discussed is that within a VRF itself, several different topologies are supported including full-mesh, partial-mesh, and hub-and-spoke. In this case, the “Public VRF” can be configured as a hub-and-spoke so that the only destination a user on the “Public VRF” can reach is the Internet. The two public sites within this example, Sites 1 and 2, are not able to communicate with one another as designed. A practical example for this might be a State or Local Government network providing Internet access to its constituents at library sites. A hub-and-spoke design will allow just the Internet access, without enabling library to library public access communication. 
The last VRFs to examine in the example are the “Secure-App VRF” (purple) and the “DMZ/Partner VRF” (green). The “Secure-App VRF” is representative of any type of application that has increased security requirements and therefore should be contained in an isolated network. As can be seen from Figure 3, Site 1 & 3 both have a Secure-App VLAN that will be able to communication with one another directly. Any other network services or access required from the Corporate network will need to added to the security policy enabled on the VRF Meet-Me Point firewall(s). The “DMZ/Partner VRF” is representative of a remote site where either an external partner connection or remote internal servers are located requiring additional protection. Enterprise network seem infamous for having “one-off” requests such as these. Either or these requests in a legacy Enterprise network might lead to an additional firewall being purchased and placed at the remote site, where physical security of the firewall is not ensured. With VRF technology available, these servers or partner connections can be connected to the “DMZ/Partner VRF” and transported back to the centralized VRF Meet-Me Point firewalls and again only allowed access to what is necessary on either sides of the connections. 
Just a few more technical notes to reiterate the flexibility of this new Enterprise model:

  • VRFs support overlapping IP address space between VRF – This means that two different VRFs can use the same IPv4 address space such as the prefix. Thus, the Enterprise network will have the capability to transport IP traffic for other agencies or sub-division that have their own IT departments and equipment, or for a strategic partner where backhaul their traffic makes sense, or potentially even offering revenue generating service, etc.
  • Dynamic Routing Protocols between PE and CE – At the edge of the network, many different routing protocols are supported between the PE and CE routers. Depending on the router manufacturer, OSPF, EIGRP, or eBGP can be used if dynamic routing is required. For stub-site, static route injection into a VRF is available as well.
  • Enriched Enterprise Network Features – Since MPLS L3VPN technology has been used in production network for over a decade now, adopted early by Service Providers and recently into more and more Enterprise networks, many additional features have been added to support unique Enterprise network requirements. These features include support for Super-backbones and backdoor links. A Super-backbone is really a simulated OSPF backbone across a VRF; similar features are supported for EIGRP as well with Cisco. Backdoor links are remote site that may have a redundant WAN link that does not connect to the MPLS network and instead goes direct to another site via an IGP such as OSPF. Links such as these can be configured a primary, secondary, or load-sharing link for the site. These are just a few of several features specific to Enterprise network integration.

MPLS L3VPNs is a very mature and scalable technology as it has had its roots in the service provider realm since the turn of the millennium. Enterprise network today share an expanding customer base similar to service providers as IP transport becomes more and more prevalent as the fundamental communication protocol within all IT fields. Ashburn Consulting believes strongly in MPLS L3VPN technology in the enterprise network space as it allows for a flexible, secure, robust and scalable network architecture that is well positioned for the foreseeable future due to its unique ability to virtualize the network. Ashburn Consulting has successfully designed and deployed this technology for both large and small customers and would be pleased to discuss our experience and possible solutions for your Enterprise network as well.