Last week we released Agent-to-Agent tests, a new feature that enhances Path Visualization by providing both forward and reverse path visibility and granular network metrics like loss and latency in each direction. With this new feature, which requires the use of at least one Enterprise Agent, test targets are (surprise!) more likely to be within an enterprise network. Depending on the network architecture, these targets might not be able to receive network traffic initiated by other hosts, either from the public Internet (Cloud Agents) or from other parts of the enterprise (Enterprise Agents). In such cases, network policies and Network Address Translation (NAT) rules would normally be required to allow packets sent as part of the test. In today's post we are going to discuss NAT and how you can simplify deployment workflows through the new NAT Traversal feature for Enterprise Agents.
Introduction to NAT
In its most simplest form, NAT is a mechanism that remaps IP addresses from one address space into another. NAT is popularly known for conserving global address space allocations in the face of IPv4 exhaustion. By remapping private IP address into a single public IP address, NAT helps in conserving the limited pool of public IP addresses used on the Internet. Basic NAT only remaps the IP address in a packet, while variations of NAT also involve remapping source or destination ports. This is called Port Address Translation.
NAT is typically implemented at the branch edge firewall and its characteristics are defined by a set of configured rules. Let's take the most common example of NAT where multiple private IP addresses, internal to an enterprise, are remapped to a single public IP address. This is called many-to-one NAT. The NAT firewall is configured with rules such that it enables communication only when it is originated from the internal network. With rules facilitating only inside-out communication, outside-in communication will be rejected. For example, an enterprise user will be able to access a web server, but a web server will not be able to initiate a conversation with the enterprise user. This makes the environment resistant to any external security threats and has proven to be another significant advantage of NAT. In order to allow outside-in communication, the firewall needs to be configured with inbound rules. Outbound rules are inevitable and should be configured on every NAT firewall; however, inbound rules are restricted and carefully curated by the IT administrator.
Network Monitoring in NAT Environments
Active tests originating from within an enterprise to an external entity like a SaaS application only need outbound rules on the firewall. However, tests originating from an external environment to a test target within an enterprise, for example from a Cloud Agent to an Enterprise Agent, will require inbound rules on the firewall. Figure 1 illustrates what happens when the NAT firewall has rules to facilitate only inside-out communication.
Simplifying Deployment with NAT Traversal
In the new Agent to Agent feature, with tests running in both directions, inbound rules become mandatory. This can mean additional overhead in terms of configuration and management. In order to simplify the deployment model, we've added support for a capability called NAT traversal. With NAT traversal, Agent-to-Agent test traffic can work in conjunction with outbound NAT configurations without the need for additional inbound rules. So what is NAT traversal? And how does the magic happen?
NAT traversal is a networking mechanism that facilitates communication between endpoints across NAT devices. NAT traversal has been in existence for quite sometime and is commonly used in peer-to-peer applications and VoIP. NAT traversal in ThousandEyes is implemented through a proprietary method similar to the NAT traversal methods described in IETF standards such as RFC 5382. Agents behind NAT devices will register with the ThousandEyes NAT traversal server in the cloud; discover the Agent's NAT characteristics and then use the discovered information to establish a connection to perform the test. This avoids the need for any inbound policies on the NAT device.
Let's take an example to describe this in a bit more detail. Consider two Enterprise Agents, as shown in Figure 2, located behind two NAT devices. When NAT traversal is enabled on the agents, they will first register with the ThousandEyes NAT traversal server. The NAT traversal server maintains a database of the agents mapped to their public IP address and port numbers. For traversal to be successful, NAT needs to be asymmetric, otherwise the automatic mappings will not work. When Enterprise Agent B has to run a network test to Enterprise Agent A, it retrieves the reachability information of Agent A from the NAT traversal server to initiate the test.
Behind the scenes, the NAT traversal server signals to Agent A that is it the target of a test from Agent B. Agent A sends a message to Agent B creating an IP translation binding on the NAT device. As NAT is assumed to be asymmetric, it maintains the same mapping for incoming requests as well. So when Agent B initiates the test to Agent A, the mapping already exists and is allowed to pass through.
Enabling NAT traversal in the ThousandEyes platform is very simple. Enterprise Agents behind a NAT device can be tagged with the NAT traversal flag "Behind a NAT" in the Advanced Settings, as shown in Figure 3 below. Once tagged, the Enterprise Agent performs a compatibility check with the ThousandEyes NAT traversal server to validate the environment. This simple feature eases deployment workflows when it comes to installing agents within an enterprise environment.
NAT traversal is an interesting networking concept and has been in play for a few years. If you are interested in the intricate details of how NAT traversal is implemented and the various techniques involved, take a look at Introduction to NAT and NAT Traversal. If you would like to setup NAT traversal in your environment and need help in configuring or setting up tests, feel free to reach out to our Customer Success team.