As networks begin leveraging intelligent DNS products, there is often a need to do some magic at the Internet edge to redirect to the target provider. Some products actually have this capability embedded. Even though the ASA doesn’t specifically have a defined configuration to do this, we can achieve the same outcome with a few simple NAT rules.
An initial thought would be to build a NAT policy as follows
//define the objects
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network Umbrella1
object network Umbrella2
object service UDP-53
service udp destination eq domain
//define the nat rules
nat (any,outside) source dynamic any interface destination static obj_any Umbrella1 service UDP-53 UDP-53
nat (any,outside) source dynamic any interface destination static obj_any Umbrella2 service UDP-53 UDP-53
This will sort of work. However, there are two words of caution I would share with this approach. First, DNS sometimes leverages TCP. Second, the last NAT rule will never be used. In this case, even requests to 184.108.40.206 would match the first rule and be re-written to the destination 220.127.116.11. Continue reading
Posted in How-To
I recently listened to Packet Pushers show 395 recently. It is a great discussion on optical networking. One thing I wanted to make everyone aware of was a series of comments on the varying quality of optics and some justification around the premium prices often found on vendor branded optics. While the entire episode is worth a listen, the discussion around vendor optics begins at about 35:20 into the recording.
I work for a vendor and it is doubtful that people would view my opinion as unbiased. I encourage everyone to take a listen below and form their own opinions.
If you are a tech guy or girl, the Packet Pushers Podcast is a perfect addition to the podcatcher. Continue reading
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 – 18.104.22.168
- Umbrella2 – 22.214.171.124
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.