A few days ago I shared an article that described redirecting DNS requests with ASA. A good use case for this might be if an organization is using Cisco Umbrella but there is no way to get every host is pointed toward the correct DNS server(s) in a timely manner. In that case, a configuration of destination NAT in the ASA can force those misconfigured clients to use one of the OpenDNS addresses.
This article is very similar, but we will share a method for doing this with Firepower Threat Defence. The concept is the same but all configuration is done in Firepower Management Console. Before starting on the NAT configuration, it is important to configure the following network objects (Objects, Object Management, Network).
- obj_any – 0.0.0.0/0
- Umbrella1 – 188.8.131.52
- Umbrella2 – 184.108.40.206
It is also important to confirm the existence of two port objects (Objects, Object Management, Network).
- DNS_over_TCP – TCP Port 53
- DNS_over_UDP – UDP Port 53
Most of the configuration will be done on the NAT policy for the device we are managing (Device, NAT, select edit for the appropriate NAT policy). Continue reading
Posted in How-To
A typical Firepower deployment consists of a management component and a managed device. The management component is known as Firepower Management Center (FMC). The managed device is the NGIPS or NGFW itself and would be leveraging the Firepower or the Firepower Threat Defense (FTD) operating system. Both layers of the topology include provisions for redundant deployments. Firepower Management Center is available in a two-node HA configuration. Firepower Threat Defense, the NGFW managed device, can be either HA or clustered.
One question that often comes up is, “What happens when FMC goes offline?” The general response is traffic continues to flow but the managed device cannot be managed. While this is not a good position to be in, it does provide an opportunity to assess the impact of waiting for a maintenance window (or a replacement).
- Firepower continues to pass traffic when FMC is offline
- Events captured on the Firepower device will be passed to the FMC when it is available
- Event Storage on the managed device is finite, events may be lost during an extended outage
- Malware Cloud Lookups/Block functionality depends on FMC, plan HA and File Policy accordingly
- Firepower managed device cannot be managed until FMC is available
Posted in Design
Very early in our careers, we learn about physical and logical network segmentation. Generally speaking, that understanding comes in the form represented by the diagrams below.
Depending on the work environment of an individual, it may take some time before they are exposed to the methods that provide segmentation to routed parts of the network. Looking at the diagram above, let’s think about what is being accomplished in each example. The physical segmentation provides full isolation between the two hosts. This article examines the construct used to extend segmentation into a routed network. We will not get into the configuration details but will share some links to additional content that can provide practical guidance on the configuration. Continue reading
Posted in Design
In conversations I often hear people using the word “mutable”. Typically it would be something similar to the following.
The IP TTL is a mutable field and decreases as it traverses a router.
If we look up the word “mutable” we find that it is something that is likely to change.
So the IP TTL is a great example of a mutable field. That value is expected to decrease at each hop throughout the network.
By contrast, IP Source Address, Destination Address, and Protocol would be immutable because it is not normal for those to change. They should stay constant from source to destination.
I know someone might consider something like NAT or PAT to change some of these attributes. While that is true, I still would not consider those mutable fields.
As I mentioned in a previous post, I have been studying the materials for the Cisco CCDE. One thing that has come up only a time or two is that of MTU. MTU, or maximum transmission unit, is the maximum size a chunk of data can be for a given interface. In this article, we are speaking specifically of IP MTU and this is an important distinction that I will clarify later. Network design should incorporate a clear understanding of MTU challenges and operators need to understand what to look for when it is not properly built and configured.
A simplistic example of a problematic design is when there is a link with a smaller MTU somewhere between two endpoints capable of creating larger packets (see the image below). While this environment may work fine, understanding the interaction required between the hosts and the network devices is very important to network design.
A few years ago I wrote an article that outlined some of the behavior that can be witnessed when there are MTU discovery issues. Let’s quickly recount what path MTU discovery (PMTU-D) is, how it works, how it fails and some logic around appropriate design. Continue reading
I have spent some time studying the CCDE materials. One broken design example that has come up involves route reflector clients that don’t align with the physical topology. This article examines that example and some solutions to the problem.
To illustrate this example we have built the topology below. I used loopback addresses 220.127.116.11 through 18.104.22.168 (based on csr1000v-x). The router on the top is a eBGP neighbor with csr1000v-1 and csr1000v-2. The four routers forming a square in the center have an initial configuration of OSFP and BGP (iBGP as shown). Both Route Reflectors are peered with both clients.
Route Reflector Initial Configuration
Posted in Design