Chapter 9. Network Address Translation
Network Address Translation (NAT) is a fascinating and storied technology in computer networks. Perhaps more than any other network technology, NAT has found itself in the corner of many different use cases. Originally developed to extend the life of the IPv4 protocol after the exhaustion of the 4 billion public IP addresses (because an IPv4 address has 32 bits, and thus there are 232 available addresses). From its original purpose it gained wide popularity as a security technology to hide IP addresses and prevent inbound network connections, and now has seen many other uses. Today, it is being used extensively by service providers for carrier-grade NAT, by network administrators worldwide for IPv4 to IPv6 translation, and even on virtual machine hosts. Who would have seen a single physical computer needing to leverage NAT 15 years ago? Although it certainly isn’t the sexiest technology discussed in this book, it is necessary in most contemporary networks and can provide other benefits to provide a transparent network experience to users on their networks.
In this chapter, we focus on the core NAT technologies offered by the SRX. We start with a discussion of how NAT is processed on the SRX, with a thorough look at how it is implemented and configured from an administrative perspective. We delve into each of the different core NAT technologies supported on the SRX, including source, static, and destination NAT. We also examine IPv6 with NAT, including IPv4 to IPv6 NAT translations so that you can adapt to the exhaustion of available IPv4 addresses and a smooth translation to IPv6.
The Need for NAT
For those of you who are not extensively familiar with NAT, it is primarily used for a few functions. First, it was originally developed to extend the life of IPv4 by creating private address ranges that could be hidden behind the public address ranges on the Internet. In that way, fewer public IP addresses are needed for each individual and organization connecting to the Internet. The private addresses are not unique, and are not valid on the Internet, so they must be translated to public IP addresses before they can be routed on the Internet. It’s similar to having a telephone private branch exchange (PBX) with internal extensions versus public phone numbers. Inside the network you can just dial the extensions and connect directly with other members of the internal network, but someone from the outside cannot dial those extensions directly without the PBX handling them based on a publically routable phone number. Likewise, you need to have the PBX handle the routing of your phone call to outbound destinations or else you won’t be able to communicate with entities outside of your network.
Besides using NAT for extending the IP address ranges of IPv4, some network engineers took it a step further and intentionally leveraged NAT to hide the true IP addresses of their internal infrastructure so that it was much more difficult for attackers to connect directly to the addresses.
NAT can also be used for other utility functions like redirecting traffic from one IP port to another (even if not using public–private address ranges), and with IPv6 you can use it to translate between IPv4 and IPv6.
Finally, NAT can be used in some large-carrier ISP environments to further extend customer access when IP addresses are in short supply or when they are migrating from one range to another.
NAT as a Security Component?
Some network security engineers feel that NAT is truly a security component. In our opinion, that is a bit of a fallacy. It is true that NAT provides another layer of configuration that an attacker would have to hop through, but it’s nothing that a properly configured security policy couldn’t also do. The problem with using NAT as a security vector is that attackers have largely shifted their tactics with contemporary attacks. For instance, NAT doesn’t help you with services that need to be available on the Internet; it merely translates the traffic from the public to the private addresses (both malicious attacks and legitimate traffic). Although it does hide the internal source address of the public host, if attackers can compromise that host, they will be able to glean information about the internal network architecture anyway. And, of course, NAT isn’t going to help much with data exfiltration attacks like SQL injection or other data leakage.
With regard to protecting internal clients with NAT, attackers have found an enormous attack surface on the client machines of the network. New applications that try to provide a better user experience along with common applications installed on most user machines (Flash, Adobe PDF, Java, ActiveX, MS Office, etc.) have become a very reliable exploitation base. The attackers use various mechanisms to lure clients to malicious sites where they can exploit them. These methods include phishing and spear fishing, hijacking legitimate sites, leveraging forums, and drive-by downloads. Thus the client comes to the server and NAT cannot offer protection.
So what’s the moral of this section? Use NAT as a networking tool for multiplexing IP addresses onto your network without requiring a public IP address per host, use it to translate between private–public ranges, and use it to translate between protocols (e.g., IPv4 to IPv6). Although it will give you some implicit security benefits, these are not anything that you’re not able to get with other mechanisms. Don’t cut yourself short thinking that NAT will solve your security challenges. You will need to go much deeper with other services like UTM and IPS (along with other network and host-based protections) to provide in-depth security.
Junos NAT Fundamentals
In the early design phase of developing the SRX platform, it was clear that although ScreenOS had been wildly successful as a platform, its NAT capabilities left something to be desired. There was very little that you couldn’t do with ScreenOS NAT, but that didn’t mean that you might not have to jump through some hoops. ScreenOS primarily relied on two forms of NAT: interface-based NAT (Mapped IP 1:1, Destination IP 1:Many, and Virtual IP Many:1) and NAT directly referenced in the security policy rule itself. There were plenty of differences between these two models, with overlaps in functionality, many caveats to each approach, and the loss of some flexibility because the NAT was either tied to an interface or to a specific security policy rule. Although this often worked fine for simple use cases, it became much more difficult when it came to advanced NAT, where you would need granular rules. Additionally, there were many scenarios that required you to configure NAT on loopback interfaces, create pseudo-routes, and group NAT objects together to achieve the desired functionality. In addition, it could be more difficult to troubleshoot due to the fact that NAT could be placed in so many locations (does the dreaded trust interface NAT come to mind?).
The good news is that with the shortcomings of ScreenOS in mind, we set out to design a far superior model in Junos that leverages the best of simplicity, granularity, and flexibility in a new policy-based NAT approach. The Junos model varies from ScreenOS (see Table 9-1) in that it takes a policy-like approach to NAT, where NAT has its own rulebases with match and action criteria similar to firewall policies. NAT itself is abstracted from the security policies and other components like interfaces, although it can take in the properties of these rulesets to function. In Junos 11.2r2 and newer releases, we can also leverage address objects themselves in the NAT policies for a simpler user experience.
Feature | ScreenOS | SRX |
One to one NAT | Mapped IP (MIP) at interface level | Static NAT via NAT Policy |
Source NAT (many to one) | Dynamic IP (DIP) at interface level Interface NAT (NAT vs. route mode per interface) Dynamic IP via Security Policy | Source NAT via NAT Policy |
Destination NAT (many to one) | Virtual IP (VIP) at interface level Virtual IP in the Security Policy | Destination NAT via NAT Policy |
Proxy-ARP | Implicitly enabled when using MIP/DIP/VIP Configurable entries per interface/IP address | Configurable per interface/IP address |
Note
Throughout this chapter when describing the different forms of NAT with examples, we might refer to internal/external and private/public mapping. It’s important to understand that these are purely topical; you can use any of these technologies in different scenarios (e.g., translating one public IP address to another, or using source NAT to translate one private IP address to another). In the broader discussions (outside of the specific examples) we’re just referring to the most familiar uses of these technologies for the sake of discussion.
Junos NAT Types
Before we get too far into the discussion of how NAT works and how to configure and operate it, let’s talk about what the three different types of Junos NAT are, and when you would use them.
Static NAT is a 1:1 bidirectional NAT that maps one IP address to another. For instance, in the trust zone the IP address might be 1.1.1.1, but when it goes out the untrust zone, it will be mapped to 2.2.2.2. Because this NAT is bidirectional, if the traffic comes in the reverse direction, it will be mapped from 2.2.2.2 to 1.1.1.1, security policy permitting. This means that you don’t need to manually create a reverse NAT entry for this mapping (as you’ll see later). The main use case for this type of NAT is when you have a host on which you want to perform NAT and you want both inbound access to this host and outbound access to come from the same IP address. Often it is used in DMZ scenarios where you have enough IP addresses present that you don’t want to overload the public IP addresses, or if you want to simply hide the internal addressing scheme without overloading or multiplexing of the IP addresses for simplicity.
Source NAT is a many:1 NAT that can map many IP addresses to one or more addresses, but not in a 1:1 fashion like static NAT. This NAT is dynamically allocated in real time based on the available IP addresses and ports in the pool. Unlike static NAT, there is no reverse entry so to speak (well, there is one exception with full cone NAT, but that is outside the scope of this book). For instance, you might want to hide all hosts in the trust zone in the subnet 192.168.1.0/24 behind a public IP address 2.2.2.3 when they connect out to the Internet. Hosts on the Internet cannot make a new connection back to the hosts because it is not a bidirectional form of NAT like static NAT. The typical use case for source NAT is to hide clients within a network behind one or more IP addresses when they browse out to the Internet. Because public IP addresses (particularly with IPv4) are at a premium, especially these days now that all ranges have been allocated since 2012, source NAT is a technology used in almost all networks. Everything from home broadband routers to mobile ISPs leverage source NAT to multiplex multiple hosts behind shared IP addresses. Some administrators also feel that NAT is a security mechanism. Although there is some truth to this, it is more of a side effect than the true purpose of NAT, and attackers have found numerous ways around NAT as a security mechanism. Source NAT can also be used to connect to trading partners when you use internal IP addresses to hide overlap, or to simplify routing and security on both sides.
Destination NAT is a 1: many form of NAT that allows you to map a single IP address to multiple IP addresses. For instance, inbound connections to IP address 2.2.2.4 in the untrust zone could be mapped to internal machines at 1.1.1.2, 1.1.1.3, 1.1.1.4, and 1.1.1.5. The mechanism to determine which internal host to map them to would be based on the port number in the destination IP address of the connection. For instance, if a packet arrives on 2.2.2.4 with destination port 25 (2.2.2.4:25), it will go to 1.1.1.2, 2.2.2.4:80 to 1.1.1.3, 2.2.2.4:443 to 1.1.1.4, and 2.2.2.4:10000 to 1.1.1.5. The main use case for this is when you are limited in the public IP addresses that you have but you need to make multiple services available on the Internet. If you don’t have enough public IP addresses to map 1:1 using static NAT, then you would need to use destination NAT. Destination NAT maps a table based on the destination IP address and destination port. This will translate the IP address to the internal address, and optionally you can also translate the destination port as well. Occasionally it is also used when there is IP address overlap (e.g., with a trading partner over a private IP network) where you might need to translate both the source and the destination IP addresses but you do not have enough IP addresses for 1:1 NAT.
We’ll explore more examples throughout this chapter, so a basic understanding of what each of the three types does is a great place to be at this point.
Note
IPv6 was introduced to the SRX starting in Junos 10.2. NAT first became available in the Junos 11.2 releases for NAT 66, and then in 12.1 for NAT translation between IPv4 and IPv6. We’ll assume you’re running Junos 12.1 or newer code in this chapter for maximum feature support.
NAT Precedence in the Junos Event Chain
As we have referenced many times before in this book, the Junos packet flow is critical to understand when it comes to NAT implementation in the SRX, particularly for the policy lookup when the first packet arrives. When the initial packet arrives, the SRX will actually perform static NAT and destination NAT before it does the routing lookup or policy lookup, as we can see in Figure 9-1. This is because we are a zone-based firewall and we need to determine the security zone context. We know what the from-zone is based on the fact that we know what interface (and thus zone) the traffic arrived on, but to determine the egress interface (and thus the to-zone), we need to do a route lookup. If NAT is performed on the destination address of the packet (e.g., from the Internet inbound to an internal machine with a private address), we will need to perform NAT on the destination first to get the internal address, so that we can perform the route lookup. Technically you can do destination-based NAT to translate the destination IP address for any location; it doesn’t have to be an internal resource, but that’s definitely the most common use case.
At this point, you might be wondering what the difference is between static and destination NAT. Hold on to that thought, but for now just mentally note that they occur before the route lookup and that static NAT has precedence over destination NAT.
So now we’ve performed a transform on the destination address of the packet if there is a static or destination NAT rule configured that says to do so. What next? As mentioned, we perform a route lookup to determine the egress interface, and thus the egress zone. Now we can actually look for the matching security policy to determine how to process this traffic further.
Looking at Figure 9-1, we see that after the policy lookup we then perform the reverse static NAT and then source NAT (more to come on what both of these mean shortly). Why don’t we put the reverse static NAT and source NAT before the security policy, you might ask? The answer is simple: performance. We need to do the destination NAT so we can determine the egress interface and thus the egress zone for the security policy, but we don’t need to determine the source NAT at that stage. Instead we can defer that decision until after the policy lookup so that we don’t waste cycles doing another lookup if we’re just going to drop the traffic anyway. We’ll see more about the interesting implications that this has on the traffic later in this chapter.
Now that the NAT transforms and policy lookups are complete, we perform any Layer 7 services and install the session into the firewall table. When the next packet arrives for this session, we match the session, so we don’t have to do all of these lookups again. Instead, we fast path the traffic. We see that screens (packet based) and TCP (sanity checks like sequence/state) are performed, followed by NAT, where NAT refers to the transforms, so we don’t need to do another policy lookup after the initial policy lookup.
Note
At the time of writing this book, Junos NAT is only supported in Layer 3 mode, not in transparent mode.
NAT type precedence
The important takeaway from Figure 9-1 when it comes to NAT is that you can only have one type of NAT for both source and destination. Static NAT is bidirectional so it applies to both the source and destination IP or ports, whereas source or destination NAT is unidirectional, for its respective type of NAT. Static NAT always takes precedence over destination or source NAT if an entry is present. If there is no entry found for static NAT, then the destination NAT rulebase will be examined. The same is true for static NAT on the Source fields; if there is an entry, it will take precedence over source NAT. The NAT that is performed on the Source and Destination fields are mutually exclusive. It can be summarized as follows:
Static NAT transform on destination address if matching static NAT rule is present.
If no static NAT entry is matched for the destination address, then check for a match in the destination NAT ruleset and perform the transform if an entry is found.
Static NAT transform on source address if matching static NAT rule is present.
If no static NAT entry is matched for the source address, then check for a match in the source NAT ruleset and perform the transform if an entry is found.
The following would be valid examples:
Static NAT
Source NAT only
Destination NAT only
Source and destination NAT
In the scenario when you have static + source NAT or static + destination NAT, the static entry would always take precedence over the source or destination NAT if there is an overlapping entry. This is because if there is a static NAT for the destination or source, we will bypass the respective lookup for the destination or source NAT. The system will still let you configure this example; it will just be shadowed. We’re going to go much deeper into NAT examples throughout this chapter, so don’t worry if you don’t entirely follow the differences here, just make sure that you understand that there is precedence and which NAT takes precedence.
Junos NAT Components
Now that we have a fundamental understanding of the packet flow on the SRX when it comes to Junos NAT, we can have a more in-depth discussion of how you as the administrator can actually accomplish NAT on the SRX. To do so, we cover the different NAT components including rulesets, rules, match criteria, pools, interfaces, and proxy-arp from a high level, then dig into how this pertains to each type of NAT: static, source, and destination.
Rulesets
The first component of NAT that we discuss is rulesets. Rulesets are to NAT as security contexts are to security policies (e.g., trust to untrust). NAT rulesets define a context that contains NAT rules with match and action criteria. The main difference with rulesets in NAT versus contexts in security policies, is that in security policies the contexts have a source zone and destination zone, one each per context, and it can only be a zone (e.g., trust to untrust). With NAT, you have a bit more granular control. You can not only define a zone ruleset based on zones, but also based on interfaces or routing instance. The NAT ruleset acts as the context for which the firewall should select which table of rules should be evaluated. In a way, it is a match criterion for the traffic, but its purpose is twofold. First, it creates a nice administrative separation for the administrator to group rules that should be evaluated together, and second, it helps performance by splitting up the rules into logical groups so that rather than evaluating every potential NAT rule for that given type, we can evaluate only the ones that match the traffic direction.
In fact, unlike security contexts where you can only have one from- and to-zone per context, with NAT rules you can have multiple interfaces, zones, or routing instances per context—although you cannot mix two types, so you could for instance, have both interfaces xe-1/0/0 and xe-1/0/1, or zones trust and untrust, but not interface xe-1/0/0 and zone trust in a single ruleset. This might sound a bit confusing at first, but we’ll provide some examples shortly to solidify your understanding.
Static NAT rulesets
Static NAT rulesets are evaluated before the routing lookup, so therefore you can only match on the from (source) interface, zone, or routing instance for the context. For instance, when the packet arrives and it is a member of a new session in Figure 9-1, we know what interface it arrived on, and because that interface is tied to both a zone and a routing instance, we thus know what the source context will be for that packet. We then do a lookup in these rulesets to find a matching rule.
Note that because static NAT is 1:1, meaning it is bidirectional (in fact the only NAT that is truly bidirectional), the SRX will automatically create a reverse mapping for translations in the opposite direction. Of course, you still need to have a security policy that permits the traffic, it’s just that the reverse transform is automatic.
Destination NAT rulesets
Destination NAT rulesets, like static rulesets, are evaluated before the routing lookup, so they only leverage the from (source) interface, zone, or routing instance for the context. The main difference here is that this rule is only from inbound sessions to translate the destination address. Traffic initiated in the opposite direction will not be matched to this rule. Notice how we say that this is for traffic that is initiated; this is because we always handle the transforms for both directions of a flow, but the SRX does not automatically create a reverse mapping for NAT in the opposite direction like it does with static NAT.
Source NAT rulesets
Source NAT rulesets are evaluated after the routing/policy lookup, so the SRX knows not only the source interface, zone, or routing instance, but also the destination interface, zone, or routing instance. Thus both items are taken into account when determining which source NAT ruleset to use to find the specific match rule.
NAT ruleset precedence
Earlier we mentioned that you can have multiple NAT rulesets within each NAT type (static, source, and destination) and also you can have different criteria for the context, either interface, zone, or routing instance. Although you can have multiple criteria such as two different zones or interfaces (logical OR) you can only have one context type per ruleset. That said, you can have contexts made of one or more interfaces, zones, or routing instances for each NAT type. So how does the SRX determine which ruleset to select? The precedence is in this order:
Match context by interface
Match context by zone
Match context by routing instance
NAT ruleset precedence example
Let’s take a look at matching precedence. We omit the actual rules themselves and just use static NAT for simplicity for this precedence example. We’ll dive into the rules and each of the NAT types shortly.
Let’s say that we are looking for rules within the following four contexts. Assuming that interfaces xe-1/0/0 and xe-1/0/1 are in the trust zone and the trust routing instance, we’d first try to find a rule in ruleset 1 because it’s interface based and the most specific ruleset, then we would search 2 for a match, then 3, and then ruleset 4, until we found a match. If no match was found, no NAT would be performed. If we had another interface xe-1/0/2 that was in the untrust routing instance, then we’d only check ruleset 5 and skip the others. As mentioned, the order looks for a matching rule (which we get into shortly) and then performs the action. Like the security policy, the rules are terminal; if we find a match, we don’t search any further. If no match is found, NAT will not be performed for that type.
[edit security nat static]
root@srx3600n0# show
rule-set 1 {
from interface xe-1/0/0.0;
}
rule-set 2 {
from interface [ xe-1/0/0.0 xe-1/0/1.0 ];
}
rule-set 3 {
from zone trust;
}
rule-set 4 {
from routing-instance trust;
}
rule-set 5 {
From routing-instance untrust;
}
[edit]
root@srx3600n0# show security zones
security-zone trust {
interfaces {
xe-1/0/0.0;
xe-1/0/1.0;
}
}
security-zone untrust {
interfaces {
xe-1/0/2.0;
}
}
[edit]
root@srx3600n0# show routing-instances
trust {
instance-type virtual-router;
interface xe-1/0/0.0;
interface xe-1/0/1.0;
}
untrust {
instance-type virtual-router;
interface xe-1/0/2.0;
}NAT Interfaces, Pools, and Mapping Objects
When you configure a NAT rule to define the transform that should happen when the match criteria is met, you must specify how the session should be modified. To do this, we rely on three different types of objects to simplify configuration and also allow easy reuse of common configuration elements. Here we are not referring to the match criteria (which can be IP prefixes or address objects), but rather the transform objects.
Static NAT transforms
When you are using static NAT, there are three types of mapping objects that you can use to define the transform.
- IP prefix
This is a standard
<ip-address/subnet-mask>combination. It is supported for both IPv4 and IPv6.- Prefix-name
This is also known as an address object from the address book. This allows you to use a predefined object like you would in the security policy rather than having to specify the prefix again. This can be used for both IPv4 and IPv6.
- Inet
This is used when you want to convert IPv4 to IPv6 (and vice versa) and is based on stripping the first 96 bits off the IPv6 address (128 bits) to leave the last 32 (the number of bits for an IPv4 address.) For instance, if you had an IPv6 /96 prefix of 2001::/96 and an IP network of 192.168.1.0/24, then it would map to 2001::192.168.1.0 → 192.168.1.0 with masks up to 32 bits of the IPv4 address. Note that the translation is automatic; you just need to make sure that you have properly defined the IPv4 and IPv6 networks. We’ll examine this further with an example.
Source NAT transforms
Interfaces
When using source NAT, you can specify that the source addresses of the sessions matching the NAT rule should be translated to appear as the interface IP address of the egress interface itself. This is only applicable for source NAT, and not for static or destination NAT. Typically, this option is used when you are limited in the number of public IP addresses that you have available so you cannot use a pool of multiple IP addresses, or if you want to hide all of the matching traffic behind a specific IP rather than break out into a pool. As mentioned, in this case, the IP address will be the same as the egress interface.
Interfaces can be used both as the primary form of NAT as well as a backup option when NAT pools are exhausted. Interfaces force you to leverage NAT overloading where multiple internal IP addresses are mapped to a single public IP address. This has to be done with overloading because we are multiplexing more than one internal IP address to a single external IP address, so we can’t map 1:1.
Pools
There are two types of source NAT pools: standard pools and overflow pools. The main difference is that the standard pools will be used primarily until they are exhausted, and overflow pools are used after that point to prevent connectivity issues. With source NAT, you can use different types of mapping, including dynamically allocated 1:1 source NAT where each internal host gets a public IP address (different than static because you don’t hardcode the mappings, they are allocated at runtime) as well as overloaded scenarios where hosts get mapped to public IP addresses that are shared by leveraging port overloading.
Note
Earlier versions of Junos only allowed you to define source NAT pools with more than one IP address, but this restriction has been lifted in the modern code so you can now define source pools with just one IP address or more.
NAT Rules
After the NAT ruleset context is matched for a given type, then the rules within the ruleset are evaluated for a match. Just like security policy rules, the NAT rules are evaluated from top to bottom in the ruleset for a match. If a match is found, it is a terminal match, meaning that we will not evaluate any other NAT rules, but perform the action dictated in that rule. If no matches are found in the ruleset, other less specific NAT rulesets will be evaluated for each type, as we discussed in the last section regarding NAT ruleset precedence. If no other NAT rulesets or rules match, then no NAT will occur on this traffic.
NAT and Security Policies
Earlier we discussed the fact that NAT can affect the match criteria of the security policy, and now that we have had a discussion of the NAT components and how they work, we can dig into the actual implications. We recall that static NAT for the destination IP address and destination NAT (both for the destination IP address and optionally the application port) happen before the security policy lookup, with the static NAT on the source address and source NAT happening after the policy lookup.
What does this mean in terms of the match criteria that you should use in your security policies when using NAT? The following rules summarize the strategy:
When transforming the destination IP address, the translated IP address should be used in the security policy as the match criteria, not the original address that is in the packet when it arrives on the device. This is because the IP address will be translated before the SRX does the policy lookup.
When transforming the source IP address using either static NAT or source NAT, because this transform happens after the policy lookup, you should use the original or untranslated IP address in your security policy.
Note
When using Juniper IPS, your rulesets should always use the translated IP addresses in the match criteria of the policy. This is because the IPS maintains its own security policy, but this lookup happens at the end of the processing chain after both destination and source NAT occur, so the IPS will always see the translated IP addresses.
We demonstrate the concepts that we have discussed here in the next section with a security policy for each example with the NAT transformation for completeness.
Proxy-ARP and Proxy-NDP
We need to cover one final concept before we dive into the actual configuration of NAT: Proxy-ARP and Proxy-NDP (Neighbor Discovery Protocol, the equivalent for IPv6). Proxy-ARP and Proxy-NDP are required for IPv4 and IPv6, respectively, when you are performing NAT and using a public range that is local to the subnet of the egress interface rather than a routed subnet. For instance, in Figure 9-2, the subnet 198.18.6.0/24 and 2001::198:18:6:0/120 are shared between the MX480 Internet router and the SRX3600 firewall. If the SRX is going to leverage addresses from these ranges as public IP addresses in their NAT pool, they must leverage Proxy-ARP and Proxy-NDP for this to function properly.
In this case, where the SRX is using IP addresses in the shard range, it must respond to ARP/NDP requests on behalf of the IP addresses for which it is proxying. Without the proxy ARP/NDP the neighboring router will not know what MAC address maps to the respective IP address. That is unless the ARP entry is statically coded on the router, but that is not a good idea, as entries can change, as can the router, so it’s best to use Proxy-ARP/NDP on the firewall itself.
Proxy-ARP/NDP simply informs the interface to which it is applied to respond to incoming ARP/NDP requests for IP addresses with its own interface MAC address so that the peer device will forward traffic destined to the NAT addresses to the firewall, which will handle the traffic and translation from there.
Configuring Proxy-ARP/NDP
Taking Figure 9-2, let’s configure Proxy-ARP/NDP on the ge-0/0/0 interface of the SRX to respond to any inbound requests for the NAT ranges with its own MAC address for both IPv4 and IPv6. In terms of the configuration, you can either define individual addresses to perform Proxy-ARP/NDP, or in this example, because we have contiguous ranges, we can use the “low address to high address” format. You can have multiple IPs or ranges per interface; the main requirement is that the ARP/NDP range must be within the subnet range of the interface, and it must not include the interface IP address itself. You do not have to specify the MAC address of the interface, as the SRX will automatically handle that.
[edit]
root@srx3600n0# set security nat proxy-arp interface ge-0/0/0 address 198.18.6.2 to 198.18.6.253
[edit]
root@srx3600n0# set security nat proxy-ndp interface ge-0/0/0 address 2001::198:18:6:2 to 2001::198:18:6:253
[edit]
root@srx3600n0# show security nat proxy-arp
interface ge-0/0/0.0 {
address {
198.18.6.2/32 to 198.18.6.253/32;
}
}
[edit]
root@srx3600n0# show security nat proxy-ndp
interface ge-0/0/0.0 {
address {
2001::198:18:6:2/128 to 2001::198:18:6:253;
}
}Note
If you’re moving from ScreenOS, you might be wondering why you never had to define a Proxy-ARP/NDP statement there but you do in Junos. The reason was that in Junos you would configure the MIP/VIP/DIP on the interface itself, and the ScreenOS device would automatically resolve the IP/MAC mapping and perform Proxy-ARP on your behalf. Although this was handled in ScreenOS, there were plenty of shortcomings in using NAT tied to interfaces. So when we moved to Junos and went with the policy-based approach, we got a far superior model, though you do have to manually add the proxy-arp/ndp statements.
When you don’t need Proxy-ARP/NDP
Proxy-ARP/NDP, got it right? Whenever you use a subnet range for any type of NAT that doesn’t include the interface itself, you need to define proxy-arp/NAT. What about when you don’t need to use it? There are two main scenarios:
You are using interface-based NAT (so the SRX will respond to the ARP request automatically because it owns the IP address already).
When you are using a subnet for NAT that is not tied to the shared network between the firewall and the upstream router.
Figure 9-3 exemplifies precisely when you don’t need to use NAT. If we are doing source NAT or destination NAT on interface 198.18.6.2 / 2001::198:18:6:2, then the SRX will handle the proxy ARP automatically with no special configuration needed. With the NAT range 198.18.7.0/24/2001::198:18:7:0/120 that is handled by the SRX3600, it is not in the local subnet that is shared between the MX 480 and the SRX 3600 (198.18.6.0/30 / 2001::198:18:6:0/126), so the MX will not ARP for the traffic. However, although you don’t need any Proxy-ARP/NDP configuration because it is not in the same subnet, you do need to make sure that the MX has a route for 198.18.7.0/24 and 2001::198:18:7:0/120 pointing to the SRX’s ge-0/0/0 interface (198.18.6.2 and 2001::198:18:6:2) or else the traffic will never arrive on the SRX. This is an important point because often you might not control the upstream device, so you need to make sure your service provider adds this route or you won’t see the traffic!
Junos NAT in Practice
Now that we have discussed the fundamentals and the components of NAT, we put it all together and work through examples of applying NAT in actual configurations so that we can solidify your understanding of these concepts in practical hands-on applications that you are likely to come across yourself in your operation of the SRX platform. We start with static NAT and examine the different deployment options for these features, and we follow that up with source and, finally, destination NAT. By the end of this section, you should have a good understanding of how these technologies are applied. We discuss both IPv4 and IPv6 NAT for each NAT type. Figure 9-4 serves as a model for the NAT configuration in this section.
Static NAT
We start our first set of examples taking a look at static NAT because it has the simplest functionality, being 1:1 in nature. We examine both IPv4 and IPv6 in the two examples in this section. We can see that the FTP server and the application servers will be using 1:1 NAT based on the nature of the public and private mappings.
Static NAT one-to-one mapping
For the first example, we configure NAT for our FTP server, which is the simple 1:1 static NAT. We configure both IPv4 and IPv6 for this example. We configure both the NAT and the security policy statement from untrust to DMZ to permit FTP traffic to this server.
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 172.16.1.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet6 address fec0::AC10:0101/120
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set security zones security-zone dmz interfaces ge-0/0/2
[edit]
root@srx3600n0# set security nat proxy-arp interface ge-0/0/0 address 198.18.5.6
[edit]
root@srx3600n0# set security nat proxy-ndp interface ge-0/0/0 address 2001::6
[edit]
root@srx3600n0# set security address-book global address FTP-Server-v4-172.16.1.6/32 172.16.1.6/32
[edit]
root@srx3600n0# set security address-book global address FTP-Server-v6-fec0::AC10:0106/120 fec0::AC10:0106/120
[edit]
root@srx3600n0# set security nat static rule-set Static-NAT rule FTP-v4 match destination-address 198.18.5.6
[edit]
root@srx3600n0# set security nat static rule-set Static-NAT rule FTP-v4 then static-nat prefix-name FTP-Server-v4-172.16.1.6/32
[edit]
root@srx3600n0# set security nat static rule-set Static-NAT rule FTP-v6 match destination-address 2001::6
[edit]
root@srx3600n0# set security nat static rule-set Static-NAT rule FTP-v6 then static-nat prefix-name FTP-Server-v6-fec0::AC10:0106/120
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy FTP-Inbound match source-address any destination-address [FTP-Server-v4-172.16.1.6/32 FTP-Server-v6-fec0::AC10:0106/120] application junos-ftp
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy FTP-Inbound then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy FTP-Inbound then log session-close
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
family inet6 {
address fec0::AC10:0101/120;
}
}
}
[edit]
root@srx3600n0# show security zones
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
security-zone dmz {
interfaces {
ge-0/0/2.0;
}
}
[edit]
root@srx3600n0# show security nat
static {
rule-set Static-NAT {
from zone untrust;
rule FTP-v4 {
match {
destination-address 198.18.5.6/32;
}
then {
static-nat {
prefix-name {
FTP-Server-v4-172.16.1.6/32;
}
}
}
}
rule FTP-v6 {
match {
destination-address 2001::6/128;
}
then {
static-nat {
prefix-name {
FTP-Server-v6-fec0::AC10:0106/120;
}
}
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
198.18.5.6/32;
}
}
}
proxy-ndp {
interface ge-0/0/0.0 {
address {
2001::6/128;
}
}
}
[edit]
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security policies from-zone untrust to-zone dmz
policy FTP-Inbound {
match {
source-address any;
destination-address [ FTP-Server-v4-172.16.1.6/32 FTP-Server-v6- fec0::AC10:0106/120 ];
application junos-ftp;
}
then {
permit;
log {
session-close;
}
}
}Let’s dissect this example a bit for some clarity.
First, we just went through the fundamental tasks of defining the
interface and zone configurations. Note that because we are using IPv6
we also have to make sure that it is configured under set security forwarding-options inet6. Note
that this requires a reboot to take place, so typically you’ll want to
do this ahead of time for the proper configuration parsing. Next, we
defined some address objects for this configuration because we’ll need
to use them in the security policy. What should be noted here is that
we used the internal addresses rather than the external. Back to our
earlier theory, because we translate the destination IP address first,
we need to use the internal address in our security policy or else the
traffic won’t be properly matched.
Because we are using public IP addresses that are in the shared subnet between our firewall and the upstream device on the ge-0/0/0 interface, we need to make sure that we configure both a Proxy-ARP and a Proxy-NDP entry on the SRX so that it will properly respond to those requests.
Next we define a static NAT ruleset from zone untrust. This will handle the translation bidirectionally (from untrust to dmz and dmz to untrust). In the rules themselves we opted to use the IP prefix as the match object and the address book object as the transform. We could have done it the other way around or used address objects or prefixes for both, just to demonstrate some flexibility. The match criteria for this example would have been the public IPv4/IPv6 addresses, and the action criteria would be translated addresses used in the DMZ.
Finally, we define the security rule that allows FTP to be accessed from the untrust network in the DMZ. As mentioned before, because the security policy lookup is done after the destination address transform, we use the internal address objects in the policy.
Static NAT many-to-many mapping
Another static NAT scenario that can occur is when you have a wide number of addresses that you want to translate between. Assuming that the IP addresses are contiguous on both sides (e.g. 192.168.1.1 → 10.0.0.1 ... 192.168.1.254 → 10.0.0.254) then you can leverage a major shortcut for NAT processing, a per-prefix translation. In this example, we perform NAT for our application servers. There will be three options: one where we do a simple NAT transform for both IPv4 and IPv6 ranges (NAT44, NAT66), the second option for IPv6 (NAT64) using a static mapping, and the third option using NAT Port Translation (NATPT) to automatically translate the IPv6 address to an IPv4 address by stripping off the leading /96 bits of the IPv6 address.
Note
For the next three examples, we are doing network-to-network translations to show a wide variety of examples, but they can also be used for host-to-host translations as well.
Option 1: NAT44/NAT66
Configure NAT44 and NAT66 mapping to translate application servers for both ranges to their respective range of the same protocol. Allow HTTP inbound to these servers, and allow the servers to connect outbound on HTTPS.
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 172.16.1.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet6 address fec0::AC10:0101/120
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set security zones security-zone dmz interfaces ge-0/0/2
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v4-Public-198.18.8.128/25 198.18.8.128/25
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v6-Public-2002::AC10:0180/121 2002::AC10:0180/121
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v4-Public-198.18.8.128/25 198.18.8.128/25
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v6-Public-2002::AC10:0180/21 2002::AC10:0180/121
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v4-Private-172.16.1.128/25 172.16.1.128/25
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v6-Private-fec0::AC10:0180/121 fec0::AC10:0180/121
[edit]
root@srx3600n0# set security nat static rule-set Application-Servers from interface ge-0/0/0
[edit]
root@srx3600n0# set security nat static rule-set Application-Servers rule AppServer-v4 match destination-address-name Application-Servers-v4-Public-198.18.8.128/25
[edit]
root@srx3600n0# set security nat static rule-set Application-Servers rule AppServer-v4 then static-nat prefix-name Application-Servers-v4-Private-172.16.1.128/25
[edit]
root@srx3600n0# set security nat static rule-set Application-Servers rule AppServer-v6 match destination-address-name Application-Servers-v6-Public-2002::AC10:0180/121
[edit]
root@srx3600n0# set security nat static rule-set Application-Servers rule AppServer-v6 then static-nat prefix-name Application-Servers-v6-Private-fec0::AC10:0180/121
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP match source-address any destination-address [Application-Servers-v4-Private-172.16.1.128/25 Application-Servers-v6-Private-fec0::AC10:0180/121 ] application junos-http
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then log session-close
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS match source-address [Application-Servers-v4-Private-172.16.1.128/25 Application-Servers-v6-Private-fec0::AC10:0180/121 ] destination-address any application junos-https
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then permit
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then log session-close
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
family inet6 {
address fec0::AC10:0101/120;
}
}
}
[edit]
root@srx3600n0# show security zones
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
security-zone dmz {
interfaces {
ge-0/0/2.0;
}
}
[edit]
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security address-book
global {
address Application-Servers-v4-Public-198.18.8.128/25 198.18.8.128/25;
address Application-Servers-v6-Public-2002::AC10:0180/121 2002::AC10:0180/121;
address Application-Servers-v4-Private-172.16.1.128/25 172.16.1.128/25;
address Application-Servers-v6-Private-fec0::AC10:0180/121 fec0::ac10:0180/121;
}
[edit]
root@srx3600n0# show security nat
static {
rule-set Application-Servers {
from interface ge-0/0/0.0;
rule AppServer-v4 {
match {
destination-address-name Application-Servers-v4-Public-198.18.8.128/25;
}
then {
static-nat {
prefix-name {
Application-Servers-v4-Private-172.16.1.128/25;
}
}
}
}
rule AppServer-v6 {
match {
destination-address-name Application-Servers-v6-Public-2002::AC10:0180/121;
}
then {
static-nat {
prefix-name {
Application-Servers-v6-Private-fec0::AC10:0180/121;
}
}
}
}
}
}
[edit]
root@srx3600n0# show security policies from-zone untrust to-zone dmz
policy Inbound-HTTP {
match {
source-address any;
destination-address [ Application-Servers-v4-Private-172.16.1.128/25 Application-Servers-v6-Private-fec0::AC10:0180/121 ];
application junos-http;
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security policies from-zone dmz to-zone untrust
policy Outbound-HTTPS {
match {
source-address [ Application-Servers-v4-Private-172.16.1.128/25 Application-Servers-v6-Private-fec0::AC10:0180/121 ];
destination-address any;
application junos-https;
}
then {
permit;
log {
session-close;
}
}
}Let’s break down this example a little bit. First, because the public ranges 2002::AC10:0180/121 and 198.18.8.128/25 are not in the same range as the ge-0/0/0 interface, we did not have to use proxy-arp/ndp. What isn’t shown is that whatever the upstream router is, it would need to route both subnets to the SRX via 198.18.5.1 and 2001::1 for IPv4/IPv6, respectively.
Next, just to show some contrast in our NAT rulebase, we used the interface context (ge-0/0/0) rather than a zone or routing instance. We discussed the merits of using one or another earlier in the chapter. In this case, either would have worked, but if you had multiple interfaces in the untrust zone, you might want to use specific NAT for specific interfaces, and that is how it could be done. Next, we used an address book entry for both the IPv4 and IPv6 entries, just to show that this could be done rather than using the prefix for one or another as we did in the last example. As you noticed, we transitioned the entire subnets from one to another, rather than doing a 1:1 translation for each address separately.
Finally, in this example we show the applications not only being accessed from untrust to dmz, but in the reverse direction as well. This is where understanding of Figure 9-1 is important. Because the destination NAT transform happens first on the Inbound-HTTP rule, we use the internal addresses in the destination field for that rule. Conversely, because the source NAT transform happens after the policy lookup in the Outbound-HTTPS rule, we also use the internal private addresses there as well rather than matching the public.
Option 2: NAT46 Static mapping
In this example, we are going to perform NAT46 for our application servers where we translate the inbound NAT from the public IPv4 to IPv6 on the internal network and vice versa, using the same example of allowing HTTP inbound and HTTPS outbound. This option is useful when you want to refer to your servers publically with IPv4, but perhaps you want to use IPv6 internally. Assume that the interface, zone, and IPv6 flow configuration has already been completed, as shown in the previous example.
Note
We could also do the opposite in this example referring to IPv6 publically and IPv4 privately. The main difference is your match and action criteria in the NAT policy (you would use the IPv6 object as the match, IPv4 as the action). You would also have to use the internal private range in your security policy, so it would be the IPv4 object as the destination in the Inbound-HTTP policy and the IPv4 object as the source in the Outbound-HTTPS policy—once again due to the order of operations with the policy lookup.
[edit]
root@srx3600n0# set security nat static rule-set NAT46 from zone untrust
[edit]
root@srx3600n0# set security nat static rule-set NAT46 rule Application-Server match destination-address 198.18.8.128/25
root@srx3600n0# set security nat static rule-set NAT46 rule Application-Server then static-nat prefix fec0::ac10:0180/121
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v6-Private-fec0::ac10:0180/121 fec0::ac10:0180/121
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP match source-address any destination-address Application-Servers-v6-Private-fec0::ac10:0180/121 application junos-http
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then log session-close
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS match source-address Application-Servers-v6-Private-fec0::ac10:0180/121 destination-address any application junos-https
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then permit
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then log session-close
[edit]
root@srx3600n0# show security nat
static {
rule-set NAT46 {
from zone untrust;
rule Application-Server {
match {
destination-address 198.18.8.128/25;
}
then {
static-nat {
prefix {
fec0::ac10:0180/121;
}
}
}
}
}
}
[edit]
root@srx3600n0# show security policies from-zone dmz to-zone untrust
policy Outbound-HTTPS {
match {
source-address Application-Servers-v6-Private-fec0::ac10:0180/121;
destination-address any;
application junos-https;
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security policies from-zone untrust to-zone dmz
policy Inbound-HTTP {
match {
source-address any;
destination-address [Application-Servers-v6-Private-fec0::ac10:0180/121 ];
application junos-http;
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security address-book
global {
address Application-Servers-v6-Private-fec0::ac10:0180/121 fec0::ac10:0180/121;
}Reviewing this configuration, the main thing that stands out is that we translated a destination IP subnet from 198.18.8.128/25 to a completely different protocol and destination fec0::ac10:0180/121 and this was not for a 1:1 translation but for a whole subnet (although the config would have been the same for a 1:1, just different subnet boundaries). We can see that the Junos Security NAT policy allows us to easily interchange which protocol is used without any specific identifiers. In this example, we just used the direct prefix rather than the address objects, but we could have done it either way. Again no proxy-arp config is needed because 198.18.8.128 is outside of the 198.18.5.0/24 subnet on the ge-0/0/0 interface. You would need to make sure that there was a route present on the upstream router to route this traffic to the SRX, though.
Option 3: NAT 64 automatic translation
In this example, we have external hosts communicate with our application servers via the IPv6 range 2002::AC10:0180/121, but the servers will only use their internal IPv4 addresses. We do it in a way that allows us to implicitly translate the IPv6 NAT to IPv4 without having to specify a custom mapping. Create a security policy that permits HTTP traffic inbound while allowing the servers to communicate out via HTTPS. We assume the interface, zone, IPv6 Flow config is already complete per previous examples.
[edit]
root@srx3600n0# set security nat static rule-set NAT64 from zone untrust
[edit]
root@srx3600n0# set security nat static rule-set NAT64 rule AppServer match destination-address 2002::AC10:0180/121
root@srx3600n0# set security nat static rule-set NAT64 rule AppServer then static-nat inet
[edit]
root@srx3600n0# set security address-book global address Application-Servers-v4-Private-172.16.1.128/25 172.16.1.128/25
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP match source-address any destination-address Application-Servers-v4-Private-172.16.1.128/25 application junos-http
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Inbound-HTTP then log session-close
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS match source-address Application-Servers-v4-Private-172.16.1.128/25 destination-address any application junos-https
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then permit
[edit]
root@srx3600n0# set security policies from-zone dmz to-zone untrust policy Outbound-HTTPS then log session-close
[edit]
root@srx3600n0# show security nat
static {
rule-set NAT64 {
from zone untrust;
rule AppServer {
match {
destination-address 2002::AC10:0180/121;
}
then {
static-nat {
inet;
}
}
}
}
}
[edit]
root@srx3600n0# show security address-book
global {
address Application-Servers-v4-Private-172.16.1.128/25 172.16.1.128/25;
}
[edit]
root@srx3600n0# show security policies from-zone untrust to-zone dmz
policy Inbound-HTTP {
match {
source-address any;
destination-address Application-Servers-v4-Private-172.16.1.128/25;
application junos-http;
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security policies from-zone dmz to-zone untrust
policy Outbound-HTTPS {
match {
source-address Application-Servers-v4-Private-172.16.1.128/25;
destination-address any;
application junos-https;
}
then {
permit;
log {
session-close;
}
}
}The interesting thing about this example is that we are not
explicitly defining what we should translate the 2002::AC10:0180/121
network to, but rather just defining inet. As we discussed earlier, this means
to automatically translate the IPv6 address to IPv4. To do this we
strip off the first 96 most significant bits from the 128-bit IPv6
address. In this case, it would be 2002:0000:0000:0000:0000:0000,
leaving behind C612:0880, which is hex for the IP address
172.16.1.128/25! If your network architecture properly can map the
public to private ranges based on the last 32 bits of the public
IPv6 address, then you can use this NAT as a shortcut. With IPv6
this is pretty easy because most organizations are getting such
large subnets assigned to them. If not, then you can always use the
standard static NAT mapping to accomplish this.
Note
As of 12.1X45, Juniper has added the ability to match not only on Destination Address and Destination Port, but also Source Address and Source Port for the match criteria. This just provides some additional granularity that might be required in environments where you want to differentiate the application of static NAT based on the Source Address, Source Port, or both, in addition to the Destination Address and optionally Destination Port
Source NAT
Although static NAT allows you to define bidirectional NAT translations, it is not ideal in all scenarios. First, you might not have the IP address ranges (particularly on the public side) to support every internal host. Second, you might not want to have a static mapping, but instead want something dynamic, whether with giving hosts a dynamic 1:1 mapping or overloading multiple private hosts to the same public address. Of course, you also might want to simplify routing with trading partners and thus hide behind an interface address. For all of these reasons, you might need to leverage source NAT. In this section, we look at a few examples of leveraging source NAT:
Source NAT with interfaces (overloading)
Source NAT with pools and interfaces (both overloading and no overloading example)
For each example we assume Figure 9-4, and we demonstrate it with both IPv4 and IPv6 to demonstrate how these can interact.
Source NAT with interfaces
In this example, we translate the hosts in the engineering department to get the public IP address of ge-0/0/0 on the firewall for both IPv4 and IPv6 when they go from trust to untrust. We allow any service outbound for this example, but we do not allow reverse connections.
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set interfaces ge-0/0/1 unit 0 family inet address 192.168.0.1/23
[edit]
root@srx3600n0# set interfaces ge-0/0/1 unit 0 family inet6 address fec0::1/118
[edit]
root@srx3600n0# set security zones security-zone trust interfaces ge-0/0/1
[edit]
root@srx3600n0# set security address-book global address Engineering-192.168.0.0/24 192.168.0.0/24
[edit]
root@srx3600n0# set security address-book global address Engineering-v6-fec0::1:0/120 fec0::1:0/120
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust from zone trust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust to zone untrust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering-v4 match source-address-name Engineering-192.168.0.0/24
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering-v4 then source-nat interface
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering-v6 match source-address fec0::1:0/120
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering-v6 then source-nat interface
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound match source-address [Engineering-192.168.0.0/24 Engineering-v6-fec0::1:0/120 ] destination-address any application any
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound then permit
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound then log session-close
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security nat
source {
rule-set Trust-Untrust {
from zone trust;
to zone untrust;
rule Engineering-v4 {
match {
source-address-name Engineering-192.168.0.0/24;
}
then {
source-nat {
interface;
}
}
}
rule Engineering-v6 {
match {
source-address-name Engineering-v6-fec0::1:0/120;
}
then {
source-nat {
interface;
}
}
}
}
}
[edit]
root@srx3600n0# show security policies from-zone trust to-zone untrust
policy Engineering-Outbound {
match {
source-address [ Engineering-192.168.0.0/24 Engineering-v6-fec0::1:0/120 ];
destination-address any;
application any;
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security address-book
global {
address Engineering-192.168.0.0/24 192.168.0.0/24;
address Engineering-v6-fec0::1:0/120 fec0::1:0/120;
}
[edit]
root@srx3600n0# show security zones
security-zone trust {
interfaces {
ge-0/0/1.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.0.1/23;
}
family inet6 {
address fec0::1/118;
}
}
}Breaking down this example a bit, we configured two different NAT translations for our static NAT: one for IPv4 and one for IPv6. Because we’re using interface-based NAT, the SRX will maintain the same protocol (e.g., NAT44/NAT66). If you want to convert between the two, you must use pools to do this properly. For the source NAT itself, we used the context from-zone trust to-zone untrust, although we could have done from interface ge-0/0/1 to interface ge-0/0/0 or even a combination of interfaces and zones if desired. In the match criteria itself, we only specified the source addresses here, although you can also specify the destination, port, and protocol information as well if you so desired to have a more specific match. For simple outbound rules, just specifying the source address is usually fine, although sometimes you might want to control the translation based on where the traffic is going (e.g., present a different source IP based on the destination or port). Because we are translating to the IP address of the interface, we don’t need to worry about using Proxy-ARP/NDP in this example.
Source NAT with pools and interfaces
In the last example, we simply translated all outbound connections to the interface address itself. This is useful for small networks where you will not hit the maximum number of connections per IP address or if you don’t need to allocate a single IP address per host. In this example, we do the following using Figure 9-4 as a model:
Translate engineering users from 192.168.0.0/24 to 198.8.5.21 for IPv4 and IPv6.
Translate accounting IPv4 from 192.168.1.0/24 to the 198.18.5.10-20 range, and use the engineering public IP as an overflow if the public accounting range is exhausted.
Translate the accounting IPv6 from fec0::2:0/120 to 2001::2:0/120, and if the pool runs out of IP addresses, configure it to overflow to the egress interface.
Allow HTTP and SMTP from trust to untrust for accounting, and HTTP and FTP for engineering from trust to untrust.
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set interfaces ge-0/0/1 unit 0 family inet address 192.168.0.1/23
[edit]
root@srx3600n0# set interfaces ge-0/0/1 unit 0 family inet6 address fec0::1/118
[edit]
root@srx3600n0# set security zones security-zone trust interfaces ge-0/0/1
[edit]
root@srx3600n0# set security address-book global address Engineering-Private-v4-192.168.0.0/24 192.168.0.0/24
[edit]
root@srx3600n0# set security address-book global address Engineering--Private-v6-fec0::1:0/120 fec0::1:0/120
[edit]
root@srx3600n0# set security address-book global address Accounting-Private-v6-fec0::2:0/120 fec0::2:0/120
[edit]
root@srx3600n0# set security address-book global address Accounting-Private-v4-192.168.1.0/24 192.168.1.0/24
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security nat proxy-arp interface ge-0/0/0 address 198.18.5.10 to 198.18.5.21
[edit]
root@srx3600n0# set security nat proxy-ndp interface ge-0/0/0 address 2001::2:0/120
[edit]
root@srx3600n0# set security nat source pool Engineering-v4 address 198.18.5.21
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust from zone trust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust to zone untrust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering match source-address-name Engineering-Private-v4-192.168.0.0/24
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering match source-address-name Engineering-Private-v6-fec0::1:0/120
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Engineering then source-nat pool Engineering-v4
[edit]
root@srx3600n0# set security nat source pool Accounting-v4 address 198.18.5.10 to 198.18.5.20
[edit]
root@srx3600n0# set security nat source pool Accounting-v4 port no-translation
[edit]
root@srx3600n0# set security nat source pool Accounting-v4 overflow-pool Engineering-v4
[edit]
root@srx3600n0# set security nat source pool Accounting-v6 address 2001::2:0/120
[edit]
root@srx3600n0# set security nat source pool Accounting-v6 port no-translation
[edit]
root@srx3600n0# set security nat source pool Accounting-v6 overflow-pool interface
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Accounting-v4 match source-address-name Accounting-Private-v4-192.168.1.0/24
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Accounting-v4 then source-nat pool Accounting-v4
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Accounting-v6 match source-address-name Accounting-Private-v6-fec0::2:0/120
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule Accounting-v6 then source-nat pool Accounting-v6
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound match source-address [Engineering-Private-v4-192.168.0.0/24 Engineering-Private-v6-fec0::1:0/120 ] destination-address any application [junos-http junos-ftp]
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound then permit
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Engineering-Outbound then log session-close
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Accounting-Outbound match source-address [Accounting-v4-192.168.1.0/24 Accounting-Private-v6-fec0::2:0/120] destination-address any application [junos-http junos-smtp]
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Accounting-Outbound then permit
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Accounting-Outbound then log session-close
[edit]
root@srx3600n0# show security address-book
global {
address Engineering-Private-v4-192.168.0.0/24 192.168.0.0/24;
address Engineering-Private-v6-fec0::1:0/120 fec0::1:0/120;
address Accounting-Private-v6-fec0::2:0/120 fec0::2:0/120;
address Accounting-Private-v4-192.168.1.0/24 192.168.1.0/24;
}
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security nat
source {
pool Engineering-v4 {
address {
198.18.5.21/32;
}
}
pool Accounting-v4 {
address {
198.18.5.10/32 to 198.18.5.20/32;
}
port no-translation;
overflow-pool Engineering-v4;
}
pool Accounting-v6 {
address {
2001::2:0/120;
}
port no-translation;
overflow-pool interface;
}
rule-set Trust-Untrust {
from zone trust;
to zone untrust;
rule Engineering {
match {
source-address-name [ Engineering-Private-v4-192.168.0.0/24 Engineering-Private-v6-fec0::1:0/120 ];
}
then {
source-nat {
pool {
Engineering-v4;
}
}
}
}
rule Accounting-v4 {
match {
source-address-name Accounting-Private-v4-192.168.1.0/24;
}
then {
source-nat {
pool {
Accounting-v4;
}
}
}
}
rule Accounting-v6 {
match {
source-address-name Accounting-Private-v6-fec0::2:0/120;
}
then {
source-nat {
pool {
Accounting-v6;
}
}
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
198.18.5.10/32 to 198.18.5.21/32;
}
}
}
proxy-ndp {
interface ge-0/0/0.0 {
address {
2001::2:0/120;
}
}
}
[edit]
root@srx3600n0# show security policies from-zone trust to-zone untrust
policy Engineering-Outbound {
match {
source-address [ Engineering-Private-v4-192.168.0.0/24 Engineering-Private-v6-fec0::1:0/120 ];
destination-address any;
application [ junos-http junos-ftp ];
}
then {
permit;
log {
session-close;
}
}
}
policy Accounting-Outbound {
match {
source-address [ Accounting-Private-v4-192.168.1.0/24 Accounting-Private-v6-fec0::2:0/120 ];
destination-address any;
application [ junos-http junos-smtp ];
}
then {
permit;
log {
session-close;
}
}
}
[edit]
root@srx3600n0# show security zones
security-zone trust {
interfaces {
ge-0/0/1.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.0.1/23;
}
family inet6 {
address fec0::1/118;
}
}
}There’s a lot more going on in this example than first meets the eye. We need to set up the NAT infrastructure. Because we are translating to pools within the egress subnet, we need to leverage proxy-arp/ndp. Next, we have to set up our pools for both accounting and engineering, IPv4 and IPv6 including the overflows. There isn’t any major difference between IPv4 and IPv6 in terms of the configuration here. We define our pool IP addresses, but also no port translation and overflow configs. No port translation instructs the SRX to allocate IP addresses to internal hosts for as long as those hosts have sessions open, without overloading the public IP addresses. In the event that there are no more IP addresses available in the pool, then we can fall back to an overflow pool or interface as we did in this example. This allows you to prevent a network outage scenario if you run out of IP addresses in the pool. Again, each IP is tied to a source for as long as that source has persistent sessions open (by default.) Note that all pools will leverage overloading by default; you have to manually disable it as we did with the accounting-v4 and accounting-v6 pools.
Our source NAT policy follows the configuration of the instructions. We have an engineering rule that matches both IPv4 and IPv6 engineering and translates them to the IPv4 engineering-v4 pool using overloading. The accounting rules are slightly different. We assign a separate IPv4 and IPv6 NAT translation depending on the original addresses (IPv4 and IPv6, respectively). Finally, we have our security policy configuration, which allows the respective traffic outbound based on the origin (accounting versus engineering).
Other SRX source NAT configuration options
You might have noticed a few other options if you were poking around the source NAT configuration throughout these examples. There are more options when it comes to source NAT, but these are often more advanced options that are used in service provider or very large enterprise environments in specific cases. We discuss them here so that you are aware of them should you have a need to leverage these advanced behaviors.
Address persistence: You can enable address persistence from a high level in the source NAT configuration. This instructs the SRX to hold source IP mappings between the internal and external mappings rather than relinquish them after all existing sessions close. This might be a useful option under certain circumstances where this information does not change; otherwise, persistent NAT might be a better option.
Address-shifting: This is a legacy option that came out of the ScreenOS days. It allows you to define a source range mapped to a destination range based on an address shift, for instance, map 10.1.1.1/25 to 1.1.1.128/25 where the mapping is not 1:1 from an octet perspective.
Persistent NAT: This is a very powerful form of NAT that is common for service providers. The main issue with source NAT for service providers is that it is difficult to allow hosts to be dynamically assigned but also function with some applications, including those that need to allow reverse inbound connections back in. Persistent NAT allows you to dynamically assign a public source IP, assign a timeout (rather than strictly being persistent or terminating after no more connections are active), and define three different types of inbound access policies: allow any connections in from any hosts after the source connects outbound, allow any inbound connections from a host that the internal host has connected to, or let the host that an internal source has connected to make a reverse connection on the same port. You can define persistent NAT per NAT pool so this can be applied in a very granular fashion. In modern networks, persistent NAT is usually a better choice than using the address persistence option.
Port randomization: By default, source port randomization is enabled for security purposes to make it more difficult for attackers to guess source ports for potential spoofing attacks like DNS poisoning. Some legacy applications might have an issue with this, so you can disable it. Note that this is only for pool-based NAT and not for interface-based NAT.
Pool default source port range: Normally this is between 1024 and 63487, but you can restrict this to a smaller range if there is a need for it. This is not a common option, but some use cases (e.g., VoIP) might require it.
Note
When using High Availability and Source NAT with Port overloading, by default each IP address can use 32k ports out of the 65k (1024 are reserved). This is because the SRX is in active/active HA mode by default, and 32k ports are reserved for each node. If you want to be able to use all 64k ports, then you must configure the SRX using a hidden command to set it to active/passive mode:
{primary:node1}[edit]
root@SRX100HM# run show chassis cluster information
node0:
--------------------------------------------------------------------------
Redundancy mode:
Configured mode: active-active
Operational mode: active-active
Redundancy group: 0, Threshold: 255, Monitoring failures: none
Events:
Apr 5 15:46:56.258 : hold->secondary, reason: Hold timer expired
Redundancy group: 1, Threshold: 255, Monitoring failures: none
Events:
Apr 5 15:46:56.277 : hold->secondary, reason: Hold timer expired
{primary:node1}[edit]
root@SRX100HM# set chassis cluster redundancy-mode active-backup
{primary:node1}[edit]
root@SRX100HM# show chassis cluster
control-link-recovery;
redundancy-mode active-backup;
reth-count 2;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 99;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 99;
interface-monitor {
fe-0/0/1 weight 255;
fe-0/0/2 weight 255;
fe-1/0/1 weight 255;
fe-1/0/2 weight 255;
}
}Destination NAT
Destination NAT fulfills two primary use cases. First, it is essential when you want to make services available on the Internet when you do not have the necessary IP address space, and it also allows you to translate the IP or port from one range to another. Sometimes this is helpful when an application is configured a certain way and you don’t want to or can’t modify it, but instead want to make the transform in the NAT policy. Let’s look at an example that will allow us to fulfill both scenarios.
Configuration destination NAT
Let’s configure an example using Figure 9-4 that performs the following options:
Leverage the public IP address 198.18.5.5/2001::5 for both the SMTP and HTTP servers in the DMZ, but allow inbound connections on port 25 to go to the SMTP server and inbound connections on port 80 to go to the HTTP server for IPv4 and IPv6, respectively.
Translate any inbound connections to port 8080 to port 443 on the HTTP server to the IPv4 address for both IPv4 and IPv6 because the server is only listening on port 443 for IPv4 and not IPv6.
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 172.16.1.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet6 address fec0::ac10:0101/120
[edit]
root@srx3600n0# set security zones security-zone dmz interfaces ge-0/0/2
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security nat destination pool SMTP-Server-v4 address 172.16.1.5
[edit]
root@srx3600n0# set security nat destination pool SMTP-Server-v6 address fec0::ac10:0105
[edit]
root@srx3600n0# set security nat destination pool Web-Server-v4 address 172.16.1.10
[edit]
root@srx3600n0# set security nat destination pool Web-Server-v6 address fec0::ac10:010a
[edit]
root@srx3600n0# set security nat destination pool Web-Server-8080 address 172.16.1.10 port 443
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT from zone untrust
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V4 match destination-address 198.18.5.5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V4 match destination-port 25
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V4 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V4 then destination-nat pool SMTP-Server-v4
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V6 match destination-address 2001::5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V6 match destination-port 25
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V6 match protocol tcp
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule SMTP-Server-V6 then destination-nat pool SMTP-Server-v6
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match destination-address 198.18.5.5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match destination-port 80
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 then destination-nat pool Web-Server-v4
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match destination-address 2001::5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match destination-port 80
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 then destination-nat pool Web-Server-v6
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v6 match destination-address 2001::5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v6 match destination-port 8080
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v6 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v6 then destination-nat pool Web-Server-8080
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v4 match destination-address 198.18.5.5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v4 match destination-port 8080
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v4 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-8080-v4 then destination-nat pool Web-Server-8080
[edit]
root@srx3600n0# set security nat proxy-arp interface ge-0/0/0 address 198.18.5.5
[edit]
root@srx3600n0# set security nat proxy-ndp interface ge-0/0/0 address 2001::5
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy SMTP-Server match source-address any destination-address [SMTP-Server-Private-v4-172.16.1.5/32 SMTP-Server-Private-v6-fec0::ac10:0105/128] application junos-smtp
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy SMTP-Server then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy SMTP-Server then log session-close
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server match source-address any destination-address [Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ] application junos-http
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server then log session-close
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server match source-address any destination-address Web-Server-Private-v4-172.16.1.10/32 application junos-https
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server-8080 then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server-8080 then log session-close
[edit]
root@srx3600n0# show security policies
from-zone untrust to-zone dmz {
policy SMTP-Server {
match {
source-address any;
destination-address [ SMTP-Server-Private-v4-172.16.1.5/32 SMTP-Server-Private-v6-fec0::ac10:0105/128 ];
application junos-smtp;
}
then {
permit;
log {
session-close;
}
}
}
policy Web-Server {
match {
source-address any;
destination-address [ Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ];
application junos-http;
}
then {
permit;
log {
session-close;
}
}
}
policy Web-Server-8080 {
match {
source-address any;
destination-address Web-Server-Private-v4-172.16.1.10/32;
application junos-https;
}
then {
permit;
log {
session-close;
}
}
}
}
[edit]
root@srx3600n0# show security nat
destination {
pool SMTP-Server-v4 {
address 172.16.1.5/32;
}
pool SMTP-Server-v6 {
address fec0::ac10:0105/128;
}
pool Web-Server-v4 {
address 172.16.1.10/32;
}
pool Web-Server-v6 {
address fec0::ac10:010a/128;
}
pool Web-Server-8080 {
address 172.16.1.10/32 port 443;
}
rule-set Inbound-NAT {
from zone untrust;
rule SMTP-Server-V4 {
match {
destination-address 198.18.5.5/32;
destination-port 25;
protocol tcp;
}
then {
destination-nat pool SMTP-Server-v4;
}
}
rule SMTP-Server-V6 {
match {
destination-address 2001::5/128;
destination-port 25;
protocol tcp;
}
then {
destination-nat pool SMTP-Server-v6;
}
}
rule Web-Server-V4 {
match {
destination-address 198.18.5.5/32;
destination-port 80;
protocol tcp;
}
then {
destination-nat pool Web-Server-v4;
}
}
rule Web-Server-V6 {
match {
destination-address 2001::5/128;
destination-port 80;
protocol tcp;
}
then {
destination-nat pool Web-Server-v6;
}
}
rule Web-Server-8080-v6 {
match {
destination-address 2001::5/128;
destination-port 8080;
protocol tcp;
}
then {
destination-nat pool Web-Server-8080;
}
}
rule Web-Server-8080-v4 {
match {
destination-address 198.18.5.5/32;
destination-port 8080;
protocol tcp;
}
then {
destination-nat pool Web-Server-8080;
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
198.18.5.5/32;
}
}
}
proxy-ndp {
interface ge-0/0/0.0 {
address {
2001::5/128;
}
}
}
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security zones
security-zone dmz {
interfaces {
ge-0/0/2.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
family inet6 {
address fec0::ac10:0101/120;
}
}
}This example goes over a few different scenarios in Figure 9-4 for the inbound NAT for the web and SMTP server. Because these share the same address publically, we can’t use static NAT—and for the port translation from 8080 to 443 we must use destination NAT to accomplish this. Destination NAT requires that we have pools defined (even if just for one address or port combination). Because we’re doing this for both IPv4 and IPv6, we must have a pool for each, plus one to do the mapping for the web server to port 443 on 172.16.1.10. After that point, we craft the NAT policy, for which we used the untrust zone as the from context, although we could have used the interface as well. For the match criteria, we are primarily concerned with where the traffic is going, so we match on the destination address, port, or protocol for both IPv4 and IPv6, and then translate it with the correct pool.
The trickier part is the integration with the firewall policy. Because destination NAT happens before the policy lookup (including the port transform), we need to make sure that we properly account for this in our rules. We know that the destination address needs to map to the translated address, but in our third example we also transform the inbound ports from 8080 to 443. We had to reference the translated port (junos-https) to properly match the traffic.
Combination Source and Destination NAT
In one interesting scenario, you might want to have a host be accessible on the Internet by one address, but have it be translated to another address when it initiates connections out to the Internet. You cannot properly use static NAT in this scenario because it forms a 1:1 bidrectional mapping that also takes precedence over source or destination NAT. Instead we must leverage both source and destination NAT. Using our web server in Figure 9-4, we will have it accept inbound connections on 198.18.5.5 and 2001::5 on port 80, but when it makes a connection back out to the Internet, it should come from the egress interface ge-0/0/0 (198.18.5.1/2001::1).
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet6 address 2001::1/96
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 172.16.1.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet6 address fec0::ac10:0101/120
[edit]
root@srx3600n0# set security zones security-zone dmz interfaces ge-0/0/2
[edit]
root@srx3600n0# set security forwarding-options family inet6 mode flow-based
[edit]
root@srx3600n0# set security nat destination pool Web-Server-v4 address 172.16.1.10
[edit]
root@srx3600n0# set security nat destination pool Web-Server-v6 address fec0::ac10:010a
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT from zone untrust
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match destination-address 198.18.5.5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match destination-port 80
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V4 then destination-nat pool Web-Server-v4
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match destination-address 2001::5
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match destination-port 80
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound-NAT rule Web-Server-V6 then destination-nat pool Web-Server-v6
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust from zone trust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust to zone untrust
[edit]
root@srx3600n0# set security nat source rule-set Trust-Untrust rule WebServerOutbound match source-address-name [Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-fec0::ac10:010a/128]
[edit]
root@srx3600n0# ...ust rule WebServerOutbound then source-nat interface
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server match source-address any destination-address [Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ] application junos-http
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server then permit
[edit]
root@srx3600n0# set security policies from-zone untrust to-zone dmz policy Web-Server then log session-close
[edit]
root@srx3600n0# set security policeis from-zone trust to-zone untrust policy WebServerOutbound match source-address [ Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ] destination-address any application any
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy WebServerOutbound then permit
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy WebServerOutbound then log session-close
[edit]
root@srx3600n0# show security policies
from-zone untrust to-zone dmz {
policy Web-Server {
match {
source-address any;
destination-address [ Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ];
application junos-http;
}
then {
permit;
log {
session-close;
}
}
}
}
from-zone trust to-zone untrust {
policy WebServerOutbound {
match {
source-address [ Web-Server-Private-v4-172.16.1.10/32 Web-Server-Private-v6-fec0::ac10:010a/128 ];
destination-address any;
application any;
}
then {
permit;
log {
session-close;
}
}
}
}
[edit]
root@srx3600n0# show security nat
destination {
pool Web-Server-v4 {
address 172.16.1.10/32;
}
pool Web-Server-v6 {
address fec0::ac10:010a/128;
}
rule-set Inbound-NAT {
from zone untrust;
rule Web-Server-V4 {
match {
destination-address 198.18.5.5/32;
destination-port 80;
protocol tcp;
}
then {
destination-nat pool Web-Server-v4;
}
}
rule Web-Server-V6 {
match {
destination-address 2001::5/128;
destination-port 80;
protocol tcp;
}
then {
destination-nat pool Web-Server-v6;
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
198.18.5.5/32;
}
}
}
proxy-ndp {
interface ge-0/0/0.0 {
address {
2001::5/128;
}
}
}
root@srx3600n0# show security forwarding-options
family {
inet6 {
mode flow-based;
}
}
[edit]
root@srx3600n0# show security zones
security-zone dmz {
interfaces {
ge-0/0/2.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
family inet6 {
address 2001::1/96;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
family inet6 {
address fec0::ac10:0101/120;
}
}
}In many ways this example is a hybrid of the source and destination NAT, but with a unified example showing both coexisting to provide both inbound and outbound Internet connectivity to the web server with a customized access behavior. This scenario isn’t that uncommon because even when you use destination NAT to handle inbound NAT, typically these servers need to be able to connect out to the Internet, and because destination NAT is only a one-way transform, you will likely need to provide them with a publically available address. Alternatively, in this example we could have used a source NAT pool rather than the egress interface, but the methodology is essentially the same.
No-NAT with Source or Destination NAT
One final option that is available when configuring source and destination NAT is to specify rules to not perform NAT. The idea behind this is that sometimes you do not want or need to perform NAT. Because the rulebase is evaluated from top to bottom and is terminal, you can easily define the match criteria and exempt a rule from a NAT transform. As mentioned earlier, this is only available for source and destination NAT and not static NAT, due to the fact that static NAT is hardcoded and bidirectional without advanced match criteria, so it’s not likely you’ll need it for NAT.
Let’s take a look at simple example here using Figure 9-5 as a model. For this example, we configure the following:
All FTP servers in the DMZ are listening on port 21, so to prevent scanning attempts, all other ports and addresses should be NAT’d to the HoneyPot server for recording the behavior.
FTP server 1 and 2 have public IP addresses that they should use going out to the Internet, but the HoneyPot server and all future servers in the DMZ will have private addresses and will need to be NAT’d to the egress interface when they go out to the Internet for updates so they are publically routable.
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 198.18.8.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/2 unit 0 family inet address 172.16.1.1/24
[edit]
root@srx3600n0# set interfaces ge-0/0/0 unit 0 family inet address 198.18.5.1/24
[edit]
root@srx3600n0# set security zones security-zone untrust interfaces ge-0/0/0
[edit]
root@srx3600n0# set security zones security-zone dmz interfaces ge-0/0/2
root@srx3600n0# set security address-book global address FTP-Server-1-198.18.8.5/32 198.18.8.5/32
[edit]
root@srx3600n0# set security address-book global address FTP-Server-2-198.18.8.6/32 198.18.8.6/32
[edit]
root@srx3600n0# set security address-book global address HoneyNet-Server-172.16.1.7/32 172.16.1.7/32
[edit]
root@srx3600n0# set security nat destination pool HoneyNet address 172.16.1.7
[edit]
root@srx3600n0# set security nat destination rule-set Inbound from zone untrust
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 match destination-address-name FTP-Server-1-198.18.8.5/32
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 match destination-port 21
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 then destination-nat off
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 match destination-address-name FTP-Server-2-198.18.8.6/32
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-2 match destination-address-name FTP-Server-2-198.18.8.6/32
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-1 match destination-address-name FTP-Server-1-198.18.8.5/32
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-2 match destination-port 21
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-2 match protocol tcp
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule FTP-2 then destination-nat off
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule All-Else match destination-address 0/0
[edit]
root@srx3600n0# set security nat destination rule-set Inbound rule All-Else then destination-nat pool HoneyNet
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out from zone dmz
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out to zone untrust
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out rule FTP-Out match source-address-name [FTP-Server-1-198.18.8.5/32 FTP-Server-2-198.18.8.6/32]
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out rule FTP-Out then source-nat off
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out rule Else match source-address 0/0
[edit]
root@srx3600n0# set security nat source rule-set DMZ-Out rule Else then source-nat interface
[edit]
root@srx3600n0#set security policies from-zone untrust to-zone dmz policy Inbound-Permit match source-address any destination-address any application any
[edit]
root@srx3600n0#set security policies from-zone untrust to-zone dmz policy Inbound-Permit then permit
[edit]
root@srx3600n0#set security policies from-zone untrust to-zone dmz policy Inbound-Permit then log session-close
[edit]
root@srx3600n0#set security policies from-zone dmz to-zone untrust policy Outbound-Permit match source-address any destination-address any application any
[edit]
root@srx3600n0#set security policies from-zone dmz to-zone untrust policy Outbound-Permit then permit
[edit]
root@srx3600n0#set security policies from-zone dmz to-zone untrust policy Outbound-Permit then log session-close
[edit]
root@srx3600n0# show security nat
source {
rule-set DMZ-Out {
from zone dmz;
to zone untrust;
rule FTP-Out {
match {
source-address-name [ FTP-Server-1-198.18.8.5/32 FTP-Server-2-198.18.8.6/32 ];
}
then {
source-nat {
off;
}
}
}
rule Else {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
destination {
pool HoneyNet {
address 172.16.1.7/32;
}
rule-set Inbound {
from zone untrust;
rule FTP-1 {
match {
destination-address-name FTP-Server-1-198.18.8.5/32;
destination-port 21;
protocol tcp;
}
then {
destination-nat off;
}
}
rule FTP-2 {
match {
destination-address-name FTP-Server-2-198.18.8.6/32;
destination-port 21;
protocol tcp;
}
then {
destination-nat off;
}
}
rule All-Else {
match {
destination-address 0.0.0.0/0;
}
then {
destination-nat pool HoneyNet;
}
}
}
}
[edit]
root@srx3600n0# show security policies
from-zone dmz to-zone untrust {
policy Outbound-Permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-close;
}
}
}
}
from-zone untrust to-zone dmz {
policy Inbound-Permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-close;
}
}
}
}
[edit]
root@srx3600n0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 198.18.5.1/24;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 198.18.8.1/24;
address 172.16.1.1/24;
}
}
}
[edit]
root@srx3600n0# show security zones
security-zone untrust {
interfaces {
ge-0/0/0.0;
}
}
security-zone dmz {
interfaces {
ge-0/0/2.0;
}
}As you can see from the NAT rulebase, we have identified traffic that must be translated and other traffic that should not be translated. Some of the examples are a bit contrived for the sake of example, but overriding NAT isn’t that uncommon depending on the architecture of your network and use cases. It is far more common with some competitive platforms like CheckPoint that have a flat rulebase that cannot distinguish contexts and therefore you have to load no-NAT rules at the top. Using no-NAT rules definitely requires a good understanding of the order of precedence and ruleset evaluation. Because the rules at the top are evaluated first, and they are terminal, having them more specific is most ideal, just like placing the most specific security policies at the top of the firewall rulebase.
Best Practices
Just like security policies, NAT is best leveraged when your network is properly segmented to provide differing levels of security and logical separation. This phase is important not only as a physical boundary between interfaces separating segments, but also in how you address your network. Ideally, resources being accessed from the Internet should be in a separate security zone like a DMZ. You should not have Internet resources directly connecting to clients, and you should not make your core internal infrastructure available on the Internet.
Define both how internal resources should access external resources and how external resources should access those inside of your network. Based on the needs of your network, you can determine what NAT will be required. Source NAT is usually needed, but whether or not you need static or destination NAT depends on the available public address ranges and what type of access you need to provide. Static NAT provides the most flexibility, but it isn’t always possible if you don’t have 1:1 public:private IP addresses, so you might need to resort to source and destination NAT.
NAT is not a security mechanism! Although NAT does have some implicit security functions, it is not in and of itself a security mechanism; modern attackers have found ways to bypass both NAT and inbound access to resources via the firewall rules. NAT can provide an additional layer of obfuscation, but it is not enough to stop modern attacks. A properly tuned security policy will provide all of the same protection as NAT and more. NAT should primarily be used for its networking function and not as a security function.
Architect contiguous NAT ranges where possible. This will allow you to better classify access and reduce the number of rules and objects that you will need to define. For instance, if you have a contiguous range for static NAT you might be able to get away with one statement for a whole /24 rather than 254 separate statements.
With regard to NAT ruleset contexts, it is often best to be as specific as possible when creating a context if you are creating a large NAT ruleset with hundreds of rules. If your ruleset is going to be smaller, you can rely simply on the zone or even possibly the routing instance level. You can also structure your NAT rulebase to provide different NAT criteria based on the specific nature of the context match (Interface → Zone → Routing Instance).
Within a NAT context, make sure to place the most specific NAT rules first, and define the necessary criteria for the match. If criteria are needed to properly identify the matches, you should define them rather than omit them to avoid unintended consequences. For example, if you need to match on not only a destination IP address but a port and protocol, don’t leave out the port and protocol.
Sometimes it is best to leverage no-NAT rules for source and destination NAT rather than not matching criteria for the rulesets. For instance, if you have a specific rule that should be a no-NAT rule, put it at the top of the ruleset as a no-NAT rule, rather than not matching all of the match + NAT statements, as you are more likely to have a mistake.
If possible, it is usually best to have upstream routers route traffic to you rather than leveraging the same subnet as the upstream router for NAT addresses. This is because you will have to rely on Proxy-ARP/NDP and this can be a messy business. Besides the configuration, you cannot control the upstream router, so if there is a MAC address change, you might not be able to trigger a failover without waiting for the entry to expire. If you can leverage routing, then you merely need to make sure the upstream infrastructure points the subnet to your firewall. This does have design implications with the subnet configuration between you and the upstream network, but it is often best to keep that to a /30 while putting the network addresses behind the firewall.
Use address objects where possible. By using address objects rather than specifying the IP prefix, you will likely cut down on potential human errors when entering the configuration because you can use the same object for the network along with the NAT ruleset.
When using address pools, make sure that you properly scope the size of the address pool to match up with the number of hosts and sessions that are required to support in your environment (plus extra scale for the future). You have to be especially careful if you are not using address translation because you can only have one private host active per public IP in the NAT pool at any time. With the overflow pool, then, it will likely last for much longer because you get to multiplex hosts and sessions on demand per NAT IP or port, so there are far fewer unused network ports and IPs in the pool.
Ideally, you should also leverage overflow pools or interfaces to ensure that if you do use all of the IPs or ports in the main pool, your hosts won’t be left without an Internet connection due to lack of available public NAT elements.
Be sure to remember how NAT interacts with the security policies. If you don’t properly configure your security policies, then you will properly NAT the traffic but you won’t match the appropriate security policy. Static (destination) NAT then destination NAT occur (with static NAT taking precedence) before the security policy lookup, so you need to use the translated IP or port info in your security policy. Reverse static (source) NAT and source NAT happen after the security policy lookup, so you should use the original source addresses in the security policies.
Troubleshooting and Operation
Now that we have gone into great detail with the concepts and examples of NAT in the SRX, let’s take a look at some useful tools at your disposal to aid the deployment, operation, and troubleshooting of NAT.
NAT Rule and Usage Counters
Let’s take a look at a few of the NAT tools that we can
look at when troubleshooting NAT in the form of NAT counters and rule
views. To start, you can look at interface NAT with the port information
available there with the show security nat
interface-nat-ports command. The following additional commands
are available:
Source
show security nat source summaryShows the high-level rulebase configuration and information in a more user-friendly format than reading the configuration directly.
show security nat source ruleProvides an in-depth look at the source NAT rule configuration including hit counts.
show security nat source poolProvides information about the pool configuration for source NAT pools including hit counts.
Static
Destination
show security nat destination summaryShows the high-level rulebase configuration and information in a more user-friendly format than reading the configuration directly.
show security nat destination ruleProvides an in-depth look at the destination NAT rule configuration including hit counts.
show security nat destination poolProvides information about the pool configuration for destination NAT pools including hit counts.
root@SRX100HM> show security nat interface-nat-ports
node0:
----------------------------------------------------------------
Pool Total Single ports Single ports Twin ports Twin ports
index ports allocated available allocated available
0 64510 0 63486 0 1024
1 64510 0 63486 0 1024
2 64510 0 63486 0 1024
3 64510 0 63486 0 1024
4 64510 0 63486 0 1024
5 64510 0 63486 0 1024
6 64510 0 63486 0 1024
7 64510 0 63486 0 1024
{primary:node0}
root@SRX100HM> show security nat source summary
node0:
--------------------------------------------------------------------
Total port number usage for port translation pool: 64512
Maximum port number for port translation pool: 16777216
Total pools: 1
Pool Address Routing PAT Total
Name Range Instance Address
Host-Outbound 172.16.40.7-172.16.40.7 default yes 1
Total rules: 3
Rule name Ruleset From To Action
1 Inet-IF LAN Danger Host-Outbound
NoDNSNAT Self junos-host Danger off
2 Self junos-host Danger Host-Outbound
{primary:node0}
root@SRX100HM> show security nat source rule all
node0:
--------------------------------------------------------------------
Total rules: 3
Total referenced IPv4/IPv6 ip-prefixes: 3/0
source NAT rule: 1 Rule-set: Inet-IF
Rule-Id : 1
Rule position : 1
From zone : LAN
To zone : Danger
Match
Source addresses : Any - 255.255.255.255
Destination port : 0 - 0
Action : Host-Outbound
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 1341902
source NAT rule: NoDNSNAT Rule-set: Self
Rule-Id : 2
Rule position : 2
From zone : junos-host
To zone : Danger
Match
Source addresses : 172.16.40.0 - 172.16.40.15
Destination port : 53 - 53
IP protocol : udp
Action : off
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 8
source NAT rule: 2 Rule-set: Self
Rule-Id : 3
Rule position : 3
From zone : junos-host
To zone : Danger
Match
Source addresses : Any - 255.255.255.255
Destination port : 0 - 0
Action : Host-Outbound
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 101165
{primary:node0}
root@SRX100HM> show security nat source pool all
node0:
----------------------------------------------------------------
Total pools: 1
Pool name : Host-Outbound
Pool id : 4
Routing instance : default
Host address base : 0.0.0.0
Port : [1024, 63487]
port overloading : 1
Total addresses : 1
Translation hits : 1443081
Address range Single Ports Twin Ports
172.16.40.7 - 172.16.40.7 45 0
root@SRX100HM> show security nat static rule all
node0:
-----------------------------------------------------------------
Total static-nat rules: 5
Total referenced IPv4/IPv6 ip-prefixes: 10/0
Static NAT rule: 1 Rule-set: Danger
Rule-Id : 1
Rule position : 1
From zone : Danger
Destination addresses : 172.16.40.2
Host addresses : 172.16.42.220
Netmask : 32
Host routing-instance : LAN
Translation hits : 23106
Static NAT rule: 2 Rule-set: Danger
Rule-Id : 2
Rule position : 2
From zone : Danger
Destination addresses : 172.16.40.3
Host addresses : 172.16.42.230
Netmask : 32
Host routing-instance : LAN
Translation hits : 3033
Static NAT rule: 3 Rule-set: Danger
Rule-Id : 3
Rule position : 3
From zone : Danger
Destination addresses : 172.16.40.4
Host addresses : 172.16.42.204
Netmask : 32
Host routing-instance : LAN
Translation hits : 1491764
Static NAT rule: 4 Rule-set: Danger
Rule-Id : 4
Rule position : 4
From zone : Danger
Destination addresses : 172.16.40.5
Host addresses : 172.16.42.205
Netmask : 32
Host routing-instance : LAN
Translation hits : 17123
Static NAT rule: 5 Rule-set: Danger
Rule-Id : 5
Rule position : 5
From zone : Danger
Destination addresses : 172.16.40.6
Host addresses : 172.16.42.238
Netmask : 32
Host routing-instance : LAN
Translation hits : 2493
{primary:node0}
root@SRX100HM> show security nat destination pool all
node0:
---------------------------------------------------------------
Total destination-nat pools: 4
Pool name : 99
Pool id : 1
Routing instance: LAN
Total address : 1
Translation hits: 278
Address range Port
192.168.1.99 - 192.168.1.99 0
Pool name : 65
Pool id : 2
Routing instance: LAN
Total address : 1
Translation hits: 1153
Address range Port
192.168.1.65 - 192.168.1.65 0
Pool name : 46
Pool id : 3
Routing instance: LAN
Total address : 1
Translation hits: 334
Address range Port
192.168.1.46 - 192.168.1.46 0
Pool name : 45
Pool id : 4
Routing instance: LAN
Total address : 1
Translation hits: 11491
Address range Port
192.168.1.45 - 192.168.1.45 0
{primary:node0}
root@SRX100HM> show security nat destination pool all rule all
node0:
-----------------------------------------------------------------
Total destination-nat rules: 5
Total referenced IPv4/IPv6 ip-prefixes: 5/0
Destination NAT rule: 1 Rule-set: VIP
Rule-Id : 1
Rule position : 1
From zone : Danger
Destination addresses : 172.16.40.13 - 172.16.40.13
Destination port : 23
Action : 99
Translation hits : 278
Destination NAT rule: 2 Rule-set: VIP
Rule-Id : 2
Rule position : 2
From zone : Danger
Destination addresses : 172.16.40.13 - 172.16.40.13
Destination port : 25
Action : 65
Translation hits : 1153
Destination NAT rule: 3 Rule-set: VIP
Rule-Id : 3
Rule position : 3
From zone : Danger
Destination addresses : 172.16.40.13 - 172.16.40.13
Destination port : 80
Action : 46
Translation hits : 334
Destination NAT rule: 4 Rule-set: VIP
Rule-Id : 4
Rule position : 4
From zone : Danger
Destination addresses : 172.16.40.13 - 172.16.40.13
Destination port : 443
Action : 45
Translation hits : 3009
Destination NAT rule: 5 Rule-set: VIP
Rule-Id : 5
Rule position : 5
From zone : Danger
Destination addresses : 172.16.40.13 - 172.16.40.13
Destination port : 4500
Action : 45
Translation hits : 8482
{primary:node0}
root@SRX100HM> show security nat destination rule all summary
node0:
--------------------------------------------------------------------
Total pools: 4
Pool name Address Routing Port Total
Range Instance Address
99 192.168.1.99 - 192.168.1.99 LAN 0 1
65 192.168.1.65 - 192.168.1.65 LAN 0 1
46 192.168.1.46 - 192.168.1.46 LAN 0 1
45 192.168.1.45 - 192.168.1.45 LAN 0 1
Total rules: 5
Rule name Ruleset From Action
1 VIP Danger 99
2 VIP Danger 65
3 VIP Danger 46
4 VIP Danger 45
5 VIP Danger 45Viewing the Session Table
As we discussed earlier in this chapter and in Chapter 8, you can check the output of the session table including the extensive information for detailed translation information (how the packet arrives on or leaves the platform). This is definitely valuable information that can be a starting point to catch any obvious issues before doing a full flow debug.
{primary:node0}
root@SRX100HM> show security flow session interface reth0.0
node0:
------------------------------------------------------------------
Session ID: 1, Policy name: N/A, State: Active, Timeout: N/A, Valid
In: 99.182.0.14/31201 --> 172.16.40.13/60915;esp, If: reth0.0, Pkts: 0, Bytes: 0
Session ID: 2, Policy name: N/A, State: Active, Timeout: N/A, Valid
In: 99.182.0.14/0 --> 172.16.40.13/0;esp, If: reth0.0, Pkts: 0, Bytes: 0
Session ID: 12, Policy name: General-Outbound/14, State: Active, Timeout: 1722, Valid
In: 192.168.1.30/4532 --> 74.125.226.47/80;tcp, If: reth1.0, Pkts: 4, Bytes: 658
Out: 74.125.226.47/80 --> 172.16.40.7/45460;tcp, If: reth0.0, Pkts: 3, Bytes: 343
Session ID: 164, Policy name: General-Outbound/14, State: Active, Timeout: 1764, Valid
In: 192.168.1.30/4277 --> 64.12.24.29/443;tcp, If: reth1.0, Pkts: 767, Bytes: 51014
Out: 64.12.24.29/443 --> 172.16.40.7/60549;tcp, If: reth0.0, Pkts: 847, Bytes: 194757
Session ID: 452, Policy name: HoneyNet-Inbound/8, State: Active, Timeout: 2, Valid
In: 31.132.2.146/25345 --> 172.16.40.4/53;udp, If: reth0.0, Pkts: 1, Bytes: 64
Out: 172.16.42.204/53 --> 31.132.2.146/25345;udp, If: reth1.0, Pkts: 1, Bytes: 3891
Session ID: 660, Policy name: General-Outbound/14, State: Active, Timeout: 1718, Valid
In: 192.168.1.30/4517 --> 74.125.225.75/80;tcp, If: reth1.0, Pkts: 9, Bytes: 703
Out: 74.125.225.75/80 --> 172.16.40.7/57358;tcp, If: reth0.0, Pkts: 11, Bytes: 12020
Session ID: 682, Policy name: self-traffic-policy/1, State: Active, Timeout: 1778, Valid
In: 192.168.1.234/52772 --> 208.87.234.140/80;tcp, If: .local..0, Pkts: 16, Bytes: 2195
Out: 208.87.234.140/80 --> 172.16.40.7/45991;tcp, If: reth0.0, Pkts: 12, Bytes: 2732
Session ID: 1406, Policy name: General-Outbound/14, State: Active, Timeout: 1718, Valid
In: 192.168.1.30/4513 --> 74.125.225.75/80;tcp, If: reth1.0, Pkts: 9, Bytes: 1038
Out: 74.125.225.75/80 --> 172.16.40.7/63263;tcp, If: reth0.0, Pkts: 11, Bytes: 12251
{primary:node0}
root@SRX100HM> show security flow session interface reth0.0 extensive
node0:
Session ID: 164, Status: Normal, State: Active
Flag: 0x8100000
Policy name: General-Outbound/14
Source NAT pool: Host-Outbound, Application: junos-https/58
Dynamic application: junos:SSL,
Maximum timeout: 1800, Current timeout: 1632
Session State: Valid
Start time: 3621298, Duration: 105795
In: 192.168.1.30/4277 --> 64.12.24.29/443;tcp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x621
Route: 0x71f3c2, Gateway: 192.168.1.30, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 767, Bytes: 51014
Out: 64.12.24.29/443 --> 172.16.40.7/60549;tcp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x620
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 847, Bytes: 194757
Session ID: 243, Status: Normal, State: Active
Flag: 0x8c100000
Policy name: HoneyNet-Inbound/8
Source NAT pool: Null, Application: junos-dns-udp/16
Dynamic application: junos:DNS, Dynamic nested application: INCONCLUSIVE
Maximum timeout: 2, Current timeout: 2
Session State: Valid
Start time: 3727091, Duration: 2
In: 37.247.99.67/49542 --> 172.16.40.4/53;udp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x621
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 64
Out: 172.16.42.204/53 --> 37.247.99.67/49542;udp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x620
Route: 0x867bc2, Gateway: 192.168.1.24, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 3891
Session ID: 945, Status: Normal, State: Active
Flag: 0x8c100000
Policy name: HoneyNet-Inbound/8
Source NAT pool: Null, Application: junos-dns-udp/16
Dynamic application: junos:DNS, Dynamic nested application: INCONCLUSIVE
Maximum timeout: 2, Current timeout: 2
Session State: Valid
Start time: 3727093, Duration: 0
In: 37.247.99.67/57562 --> 172.16.40.4/53;udp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x621
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 64
Out: 172.16.42.204/53 --> 37.247.99.67/57562;udp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x620
Route: 0x867bc2, Gateway: 192.168.1.24, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 3891
Session ID: 2027, Status: Normal, State: Active
Flag: 0x8c100000
Policy name: HoneyNet-Inbound/8
Source NAT pool: Null, Application: junos-dns-udp/16
Dynamic application: junos:DNS, Dynamic nested application: INCONCLUSIVE
Maximum timeout: 2, Current timeout: 2
Session State: Valid
Start time: 3727093, Duration: 0
In: 31.132.2.146/25345 --> 172.16.40.4/53;udp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x621
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 64
Out: 172.16.42.204/53 --> 31.132.2.146/25345;udp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x620
Route: 0x867bc2, Gateway: 192.168.1.24, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 3891
Session ID: 2186, Status: Normal, State: Active
Flag: 0x8100000
Policy name: self-traffic-policy/1
Source NAT pool: Host-Outbound, Application: junos-http/6
Dynamic application: junos:HTTP, Dynamic nested application: junos:UNKNOWN
Maximum timeout: 1800, Current timeout: 1774
Session State: Valid
Start time: 3727006, Duration: 87
In: 192.168.1.234/57320 --> 208.87.234.140/80;tcp,
Interface: .local..0,
Session token: 0x2, Flag: 0x631
Route: 0xfffb0006, Gateway: 192.168.1.234, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 8, Bytes: 935
Out: 208.87.234.140/80 --> 172.16.40.7/34719;tcp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x620
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 5, Bytes: 534
Session ID: 3048, Status: Normal, State: Active
Flag: 0x8c100000
Policy name: HoneyNet-Inbound/8
Source NAT pool: Null, Application: junos-dns-udp/16
Dynamic application: junos:DNS, Dynamic nested application: INCONCLUSIVE
Maximum timeout: 2, Current timeout: 2
Session State: Valid
Start time: 3727092, Duration: 1
In: 37.247.99.67/46102 --> 172.16.40.4/53;udp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x621
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 64
Out: 172.16.42.204/53 --> 37.247.99.67/46102;udp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x620
Route: 0x867bc2, Gateway: 192.168.1.24, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 1, Bytes: 3891
Session ID: 3233, Status: Normal, State: Active
Flag: 0xc100000
Policy name: SSL-Inbound/4
Source NAT pool: Null, Application: junos-https/58
Dynamic application: junos:SSL,
Maximum timeout: 1800, Current timeout: 1800
Session State: Valid
Start time: 3726004, Duration: 1089
In: 66.129.232.2/48272 --> 172.16.40.13/443;tcp,
Interface: reth0.0,
Session token: 0x4006, Flag: 0x621
Route: 0x861bc2, Gateway: 172.16.40.14, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 7735, Bytes: 438290
Out: 192.168.1.45/443 --> 66.129.232.2/48272;tcp,
Interface: reth1.0,
Session token: 0x5007, Flag: 0x620
Route: 0x86dbc2, Gateway: 192.168.1.45, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 13866, Bytes: 13819678View NAT Errors
Each interface tracks its own NAT error information, which can be helpful when troubleshooting issues (particularly when running out of resources). You can view this on an interface-by-interface basis. In particular, are the NAT counters incrementing? If so, you might want to run a flow debug to determine why this is occurring.
{primary:node0}
root@SRX100HM> show interfaces reth0.0 extensive
Logical interface reth0.0 (Index 69) (SNMP ifIndex 531) (Generation 134)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Statistics Packets pps Bytes bps
Bundle:
Input : 37583250 19 18085283733 18304
Output: 51125926 71 36049681531 455928
Link:
fe-1/0/1.0
Input : 0 0 0 0
Output: 0 0 0 0
fe-0/0/1.0
Input : 37583250 19 18085283733 18304
Output: 51116766 71 36048862455 455928
Marker Statistics: Marker Rx Resp Tx Unknown Rx Illegal Rx
fe-1/0/1.0 0 0 0 0
fe-0/0/1.0 0 0 0 0
Security: Zone: Danger
Allowed host-inbound traffic : ike ping
Flow Statistics :
Flow Input statistics :
Self packets : 879427
ICMP packets : 937609
VPN packets : 10363870
Multicast packets : 0
Bytes permitted by policy : 14791682432
Connections established : 1561865
Flow Output statistics:
Multicast packets : 0
Bytes permitted by policy : 33694905891
Flow error statistics (Packets dropped due to):
Address spoofing: 0
Authentication failed: 0
Incoming NAT errors: 0
Invalid zone received packet: 0
Multiple user authentications: 0
Multiple incoming NAT: 0
No parent for a gate: 0
No one interested in self packets: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 57029
No SA for incoming SPI: 230
No tunnel found: 0
No session for a gate: 0
No zone or NULL zone binding 0
Policy denied: 278
Security association not active: 240039
TCP sequence number out of window: 38
Syn-attack protection: 11
User authentication errors: 0
Protocol inet, MTU: 1500, Generation: 148, Route table: 4
Flags: Sendbcast-pkt-to-re, Is-Primary
Input Filters: Inbound-QoS
Addresses, Flags: Is-Default Is-Preferred Is-Primary
Destination: 172.16.40.0/28, Local: 172.16.40.13, Broadcast: 172.16.40.15, Generation: 145View Firewall Logs with NAT
The firewall logs themselves provide historical information about the type of NAT translation that is occurring. The logs (both init and close) provide not only the original and translated information (source and destination IP or port), but also the NAT rules that are matched for this traffic. This lookup only occurs at the beginning of the session and cannot change midsession. What follows is an example of destination NAT, as we can see that there is no source or destination NAT rule present, but we are translating the destination from 172.16.42.204 to 172.18.42.204. At the time of writing this book, Junos doesn’t specify a static NAT rule, but you can see if a source or destination NAT rule is configured, and you can also determine how the traffic is being transformed by comparing the original information to the NAT output later in the log.
Session Close:
<14>1 2012-11-19T02:40:08.985 SRX210-HoneyNet RT_FLOW - RT_FLOW_SESSION_CLOSE [junos@2636.1.1.1.2.36 reason="timeout" source-address="64.40.9.8" source-port="51697" destination-address="172.16.42.204" destination-port="53" service-name="junos-dns-udp" nat-source-address="64.40.9.8" nat-source-port="51697" nat-destination-address="172.18.42.204" nat-destination-port="53" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="17" policy-name="Allow-Internet" source-zone-name="LAN" destination-zone-name="HoneyNet" session-id-32="23211" packets-from-client="1" bytes-from-client="64" packets-from-server="1" bytes-from-server="3863" elapsed-time="2" application="junos:DNS" nested-application="UNKNOWN" username="N/A" roles="N/A" packet-incoming-interface="ge-0/0/0.0" encrypted="UNKNOWN"]
Session Init (Create):
<14>1 2012-11-19T03:02:24.173 SRX210-HoneyNet RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2636.1.1.1.2.36 source-address="98.109.158.154" source-port="1329" destination-address="172.16.42.205" destination-port="139" service-name="junos-smb" nat-source-address="98.109.158.154" nat-source-port="1329" nat-destination-address="172.16.42.205" nat-destination-port="139" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="6" policy-name="Allow-Internet" source-zone-name="LAN" destination-zone-name="HoneyNet" session-id-32="30171" username="N/A" roles="N/A" packet-incoming-interface="ge-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN"]
Flow Debugging with NAT
In this section, we take a quick look at three excerpts from a flow debug on source, destination, and static NAT. This is the same process as enabling the flow debug in Chapter 8. The main thing to remember when configuring NAT is that when you’re using the packet filters they match the traffic as it arrives on the device, so the packet filters should match the original traffic before NAT translation.
Source NAT
In Example 9-1, we can see that we are using source NAT. There are a few statements that call that out. The first specifies that Src NAT is active and identifies the pool index. PST_NAT stands for persistent NAT, which is off. Then we see the second boldface statement, which identifies what the transform is (original → transformed). DIP ID is a legacy term from the ScreenOS days where this operation was called source translation to a Dynamic IP pool. You’ll also notice that the NAT action is taking effect after the security policy lookup, as we pointed out several times throughout this chapter.
{primary:node0}
root@SRX100HM> show log FlowTrace
Dec 1 21:49:11 SRX100HM clear-log[20146]: logfile cleared
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:<192.168.1.30/2537->184.85.87.148/80;6> matched filter 1:
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:packet [48] ipid = 2314, @0x423a9b1a
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x423a9900, rtbl_idx = 5
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: sysstats_inc_InCnts
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: flow process pak fast ifl 71 in_ifp reth1.0
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: reth1.0:192.168.1.30/2537->184.85.87.148/80, tcp, flag 2 syn
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: find flow: table 0x4cbeec78, hash 25339(0xffff), sa 192.168.1.30, da 184.85.87.148, sp 2537, dp 80, proto 6, tok 20487
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: flow_first_create_session
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: flow_first_in_dst_nat: in <reth1.0>, out <N/A> dst_adr 184.85.87.148, sp 2537, dp 80
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: chose interface reth1.0 as incoming nat if.
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 184.85.87.148(80)
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.1.30, x_dst_ip 184.85.87.148, in ifp reth1.0, out ifp N/A sp 2537, dp 80, ip_proto 6, tos 0
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:Doing DESTINATION addr route-lookup
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: routed (x_dst_ip 184.85.87.148) from LAN (reth1.0 in 1) to reth0.0, Next-hop: 172.16.40.14
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: policy search from zone LAN-> zone Danger (0x0,0x9e90050,0x50)
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: policy has timeout 900
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: app 6, timeout 1800s, curr ageout 20s
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:flow_first_src_xlate: src nat returns status: 1, rule/pool id: 1/32772, pst_nat: False.
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: dip id = 4/1, 192.168.1.30/2537->172.16.40.7/39174 protocol 6
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: choose interface reth0.0 as outgoing phy if
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:is_loop_pak: No loop: on ifp: reth0.0, addr: 184.85.87.148, rtt_idx:4
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: check nsrp pak fwd: in_tun=0x0, VSD 1 for out ifp reth0.0
Dec 1 21:49:15 21:49:15.591147:CID-1:RT: vsd 1 is active
Dec 1 21:49:15 21:49:15.591147:CID-1:RT:-jsf : Alloc sess plugin info for session 98784258070Destination NAT
In Example 9-2, we are using destination NAT to translate the inbound traffic to an internal server. As we know, this lookup happens before the security policy lookup—which we intentionally show because this traffic is denied by policy. You can see how the NAT transform is happening in the boldface text where both the DST XLATE fields show the original → transform rules as well as the route lookup that occurs after it.
Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:<66.129.232.2/60970->172.16.40.13/23;6> matched filter 1: Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:packet [52] ipid = 1079, @0x4236b89a Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x4236b680, rtbl_idx = 4 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: sysstats_inc_InCnts Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: flow process pak fast ifl 69 in_ifp reth0.0 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: reth0.0:66.129.232.2/60970->172.16.40.13/23, tcp, flag 2 syn Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: find flow: table 0x4cbeec78, hash 33768(0xffff), sa 66.129.232.2, da 172.16.40.13, sp 60970, dp 23, proto 6, tok 16390 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:check self-traffic on reth0.0, in_tunnel 0x0 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:retcode: 0x1301 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:pak_for_self : proto 6, dst port 23, action 0x0 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: flow_first_create_session Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: flow_first_in_dst_nat: in <reth0.0>, out <N/A> dst_adr 172.16.40.13, sp 60970, dp 23 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: chose interface reth0.0 as incoming nat if. Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:flow_first_rule_dst_xlate: DST xlate: 172.16.40.13(23) to 192.168.1.99(23), rule/pool id 1/32769. Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 66.129.232.2, x_dst_ip 192.168.1.99, in ifp reth0.0, out ifp N/A sp 60970, dp 23, ip_proto 6, tos 20 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT:Doing DESTINATION addr route-lookup Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: routed (x_dst_ip 192.168.1.99) from Danger (reth0.0 in 1) to reth1.0, Next-hop: 192.168.1.99 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: policy search from zone Danger-> zone LAN (0x110,0xee2a0017,0x17) Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: app 10, timeout 1800s, curr ageout 20s Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: Error : get sess plugin info 0x4fe5d970 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: Error : get sess plugin info 0x4fe5d970 Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: packet dropped, denied by policy Dec 1 22:06:55 22:06:54.1015362:CID-1:RT: packet dropped, policy deny.
Static NAT
In Example 9-3, we are using static NAT. Although the debug doesn’t explicitly call this out, there are a few clues. First, in the first boldface rule we can see that there is no reference to the port as there is in the destination NAT example (23). Second, there is no port transform occurring (although this is not a requirement of destination NAT), which static NAT cannot do. Also remember that static NAT will occur before destination NAT when you’re doing a debug with NAT.
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:<66.129.232.2/58887->172.16.40.5/22;6> matched filter 1:
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:packet [52] ipid = 2523, @0x422b551a
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x422b5300, rtbl_idx = 4
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: sysstats_inc_InCnts
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: flow process pak fast ifl 69 in_ifp reth0.0
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: reth0.0:66.129.232.2/58887->172.16.40.5/22, tcp, flag 2 syn
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: find flow: table 0x4cbeec78, hash 20615(0xffff), sa 66.129.232.2, da 172.16.40.5, sp 58887, dp 22, proto 6, tok 16390
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: flow_first_create_session
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: flow_first_in_dst_nat: in <reth0.0>, out <N/A> dst_adr 172.16.40.5, sp 58887, dp 22
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: chose interface reth0.0 as incoming nat if.
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:flow_first_rule_dst_xlate: packet 66.129.232.2->172.16.40.5 nsp2 0.0.0.0->172.16.42.205.
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 66.129.232.2, x_dst_ip 172.16.42.205, in ifp reth0.0, out ifp N/A sp 58887, dp 22, ip_proto 6, tos 20
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:Doing DESTINATION addr route-lookup
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: routed (x_dst_ip 172.16.42.205) from Danger (reth0.0 in 1) to reth1.0, Next-hop: 192.168.1.24
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: policy search from zone Danger-> zone LAN (0x114,0xe6070016,0x16)
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: app 22, timeout 1800s, curr ageout 20s
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: dip id = 0/0, 66.129.232.2/58887->66.129.232.2/58887 protocol 0
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: choose interface reth1.0 as outgoing phy if
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:is_loop_pak: No loop: on ifp: reth1.0, addr: 172.16.42.205, rtt_idx:5
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: check nsrp pak fwd: in_tun=0x0, VSD 1 for out ifp reth1.0
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT: vsd 1 is active
Dec 1 22:14:27 22:14:26.1488828:CID-1:RT:-jsf : Alloc sess plugin info for session 90194318307Also, remember that static NAT can also transform the source if it matches the bidirectional (implicit) reverse rule. It will look similar to source NAT except it won’t do any port translation or reference a pool, as shown in the following output, where we perform reverse static NAT.
Dec 1 22:28:30 22:28:30.749281:CID-1:RT:<192.168.1.55/40093->4.2.2.2/80;6> matched filter 1: Dec 1 22:28:30 22:28:30.749281:CID-1:RT:packet [60] ipid = 11363, @0x422e9e9a Dec 1 22:28:30 22:28:30.749281:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x422e9c80, rtbl_idx = 5 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: sysstats_inc_InCnts Dec 1 22:28:30 22:28:30.749281:CID-1:RT: flow process pak fast ifl 71 in_ifp reth1.0 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: reth1.0:192.168.1.55/40093->4.2.2.2/80, tcp, flag 2 syn Dec 1 22:28:30 22:28:30.749281:CID-1:RT: find flow: table 0x4cbeec78, hash 5142(0xffff), sa 192.168.1.55, da 4.2.2.2, sp 40093, dp 80, proto 6, tok 20487 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: flow_first_create_session Dec 1 22:28:30 22:28:30.749281:CID-1:RT: flow_first_in_dst_nat: in <reth1.0>, out <N/A> dst_adr 4.2.2.2, sp 40093, dp 80 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: chose interface reth1.0 as incoming nat if. Dec 1 22:28:30 22:28:30.749281:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 4.2.2.2(80) Dec 1 22:28:30 22:28:30.749281:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.1.55, x_dst_ip 4.2.2.2, in ifp reth1.0, out ifp N/A sp 40093, dp 80, ip_proto 6, tos 10 Dec 1 22:28:30 22:28:30.749281:CID-1:RT:Doing DESTINATION addr route-lookup Dec 1 22:28:30 22:28:30.749281:CID-1:RT: routed (x_dst_ip 4.2.2.2) from LAN (reth1.0 in 1) to reth0.0, Next-hop: 172.16.40.14 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: policy search from zone LAN-> zone Danger (0x0,0x9c9d0050,0x50) Dec 1 22:28:30 22:28:30.749281:CID-1:RT: policy has timeout 900 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: app 6, timeout 1800s, curr ageout 20s Dec 1 22:28:30 22:28:30.749281:CID-1:RT: found reversed mip 172.16.40.9 for 192.168.1.55 (on reth0.0) Dec 1 22:28:30 22:28:30.749281:CID-1:RT:flow_first_src_xlate: nat_src_xlated: True, nat_src_xlate_failed: False Dec 1 22:28:30 22:28:30.749281:CID-1:RT:flow_first_src_xlate: hip xlate: 192.168.1.55->172.16.40.9 at reth0.0 (vs. reth0.0) Dec 1 22:28:30 22:28:30.749281:CID-1:RT: dip id = 0/0, 192.168.1.55/40093->172.16.40.9/40093 protocol 0 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: choose interface reth0.0 as outgoing phy if Dec 1 22:28:30 22:28:30.749281:CID-1:RT:is_loop_pak: No loop: on ifp: reth0.0, addr: 4.2.2.2, rtt_idx:4 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: check nsrp pak fwd: in_tun=0x0, VSD 1 for out ifp reth0.0 Dec 1 22:28:30 22:28:30.749281:CID-1:RT: vsd 1 is active Dec 1 22:28:30 22:28:30.749281:CID-1:RT:-jsf : Alloc sess plugin info for session 107374185892
The key to identifying that this is not source NAT is the reverse MIP statement and the source NAT HIP statement. Mapped IP (MIP) is the same transform as ScreenOS (although there are differences in how it is implemented as we mentioned, but this is just a legacy statement). Also note that there is no DIP pool used. This translation would have used a source NAT rule, but because static NAT takes precedence over source and destination NAT, it was selected in this instance.
Of course, you could also see a combination of these types, such as source and destination NAT, which essentially just shows both source and destination operations taking place.
Sample Deployment
Throughout this chapter we provided several examples (including a holistic network example for both IPv4 and IPv6 for each type of NAT), so please refer to the examples in this chapter as this chapter’s sample deployments.
Summary
The original intention of NAT was to extend the lifeline of IPv4, but it has found a wide range of new uses in modern networks. NAT is likely to be a part of networks into the future as we migrate to IPv6 and nonroutable internal networks that must be translated to reach the Internet or access trading partners. Throughout this chapter we discussed the different NAT techniques available and how to implement them with best practices in mind for your network. By properly leveraging NAT in your SRX, you are less likely to run into configuration and support issues, and you can make the most efficient use of your available IP address space. NAT is more than likely to exist in our networks long into the future after IPv6 is deployed and the original need for NAT is nullified.
Study Questions
- Questions
Describe the three main NAT technologies supported on the SRX.
What does it mean that static NAT is bidirectional? Are the other NATs only translated in one direction of a flow?
What is the order of precedence when it comes to NAT in the flow lookup policy?
What happens if no NAT rule is matched during the policy lookup phase?
What is a NAT context, and what options are available for the three different types of NAT rulesets?
How are rule matches found when doing a NAT lookup?
What are Proxy-ARP and Proxy-NDP and when are they needed?
What translation options do you have for each type of NAT?
What source, destination, and application should you use in your security policy when using static, source, and destination NAT (discuss them separately)?
What is the best practice for crafting the rules in a NAT ruleset?
Why would you use no-NAT rules in your NAT policy, and which NAT types support them?
- Answers
The three NAT types are static, source, and destination. Static NAT is used for 1:1 bidirectional address translation. Source NAT translates the source address and ports for traffic leaving the firewall from one range to another. You can use this to both perform NAT where each internal IP gets its own IP address or you can overload the sources to individual interface IPs or pools of IP addresses. Finally, destination is used to translate the destination address or port of an inbound connection on the SRX. This is often used when you are limited with IP address space and want to multiplex multiple internal hosts to the same public IP address based on service.
Because the SRX is a stateful firewall, it handles translating the two directions of the flows for a given session regardless of what type is used. What we mean by bidirectional for static NAT is that the translation will happen for both initiated directions of traffic without having to configure a reverse rule. Source NAT and destination NAT only occur in one direction, and you would have to configure a reverse mapping if you wanted such a translation to happen (and it couldn’t be to the same address most likely). For instance, if you have a host in the DMZ, and you set up a static NAT rule from the untrust zone to perform the 1:1 NAT in the DMZ, the SRX will handle the NAT from untrust to DMZ and from DMZ to untrust (firewall rule permitting). Source NAT, on the other hand, might be set up from trust to untrust—but it will only happen for sessions initiated in that direction, not from untrust to trust. In the case of destination NAT, if you have a translation from untrust to DMZ, it only happens in that one direction, and you would need to configure source NAT to NAT the traffic from DMZ to untrust.
Before the security policy lookup, static NAT (destination address) is processed first. If there is no static NAT rule matched, then destination NAT will be examined for the destination address or port translation. Next comes the security policy lookup, followed by a lookup in the reverse static NAT rulebase. If there is no rule match there, then the source NAT rulebase will be examined to see if there is a match and then a transform.
The traffic will not be transformed by NAT.
A NAT context defines the high-level directionality match criteria for the NAT ruleset. You can match on one or more interfaces, zones, or routing instances (although only one type per context). The order of precedence is interfaces, then zones, then routing instances from highest to lowest priority match. Static NAT uses only “from” in its context, destination NAT uses only “from” in its context, and source NAT uses both “from” and “to” in its context.
For the respective NAT type (static, destination, source), first the NAT engine will try to match an actual context. If no match is found, no NAT will occur for that type. If a match occurs, NAT will start with the most specific NAT type (interface, then zone, then routing instance). Next, from the top down in the NAT ruleset for the first matched context, the NAT policy will attempt to match the packet to the same criteria defined in the rule. If a match occurs, that action will be taken. If no match occurs in that ruleset, the SRX will try to match it to another ruleset context and rule, or if none are available no NAT will occur for the traffic.
Proxy-ARP and its IPv6 relative Proxy-NDP allow the SRX to respond to an ARP request on behalf of the virtual destination’s IP address (which the SRX hosts) with its own MAC address to the peer device will properly forward the traffic to the SRX. This must be manually configured, and is required when you are using virtual IP addresses in the egress subnet shared between the SRX and the upstream device (because it hosts ARP for a MAC address on their local subnet). You do not need to use Proxy-ARP or Proxy-NDP if the upstream device is routing the traffic for that subnet to you, or if you are terminating NAT on the interface itself, in which case the SRX will respond to queries for MAC addresses that it owns.
Each type of NAT supports both IPv4 and IPv6 NAT, including translating IPv4 to IPv6 and vice versa. For static NAT, you can translate one address to another, or entire contiguous ranges from one network to another. Destination NAT allows you to translate matched traffic by altering the destination address and port. You can do this to one address or multiple addresses in a pool. Source NAT has the most options (some of which were only topically discussed in this book). You can translate source addresses to both interfaces and pools. When using source NAT, you can define whether to use port translation (overloading), and you can also use advanced options like persistent NAT and address shifting and control how addresses are allocated from the pool.
For static NAT, your source address should be the original (untranslated ) IP address, but the destination should be the translated IP address in the security policy (static NAT comes before the policy lookup, static NAT comes after the security policy). For source NAT, you should always use the original untranslated IP addresses in your security policy because the source NAT happens after the policy lookup. For destination NAT, you should use the translated addresses or ports in your security policy because it happens before the security policy lookup.
It is best to have the most specific NAT rule matches at the top of the ruleset with the less specific matches below so that you avoid shadowing wherever possible. This is the same as with the security policies.
Source and destination NAT support no-NAT as an option when you make a match. This is useful if you want to exclude certain conditions from being processed by NAT. Particularly with source NAT where you might have a catchall at the bottom of the rulebase, you might want to not match on any rule that might trigger NAT, so use this rule first and specify no-Nat for your action.
Get Juniper SRX Series now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
