Почему juniper vmx не поддерживает nat
Get full access to Juniper SRX Series and 60K+ other titles, with free 10-day trial of O’Reilly.
There’s also live online events, interactive content, certification prep materials, and more.
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 2 32 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.
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
Implicitly enabled when using MIP/DIP/VIP
Configurable entries per interface/IP address
Configurable per interface/IP address
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.
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.
At the time of writing this book, Junos NAT is only supported in Layer 3 mode, not in transparent mode.
Примеры конфигурации Junos настройка NAT на Juniper SRX
Здесь описывается настройка трансляции сетевых адресов (NAT) на шлюзе служб Juniper SRX для использовать в общих сетевых сценариях. Предполагается, что Вы уже знакомы с концепциями и терминологией NAT используемый на устройствах Juniper:
Настройка пулов адресов для NAT
В этом разделе показана конфигурация для создания различных типов источников NAT-пулов. Пулы, созданные в этих примерах будут использоваться в правилах NAT последующих примеров конфигурации. Выполняется вся конфигурация под иерархией «источник безопасности» в CLI Junos. По умолчанию все пулы источников IP будут включены. Пулы источников без PAT можно настроить, отключив PAT в пуле IP. Пулы IP не привязаны к интерфейсу. Прокси-сервер ARP должен быть настроен для того, чтобы устройство отвечало на ARP для адресов в пуле IP.
1. Настройка пула источников с диапазоном адресов и перевода порта:
2. Настройка пула источников с отключенным диапазоном адресов и перевода порта:
3. Настройка пула источников с диапазоном адресов с отключением порта с использованием пула переполнения. Пулы переполнения используются в качестве резерва в случае, если пул источников без PAT исчерпывает свободные IP-адреса. Пулы переполнения могут быть пулами источников IP с PAT или интерфейсом:
4. Настройка пула источников с одним адресом и переносом порта:
5. Настройка пулаисточников с диапазоном для IP-адреса и номеров портов:
Настройка NAT с использованием интерфейса IP
В этом примере весь трафик из зоны trust в зону untrust преобразуется в выходной интерфейс, интерфейс ge-0/0/2 IP
адрес.
Настройка NAT с использованием пула IP-адресов
В этом примере весь трафик из зоны trust в зону untrust переводится в исходный пул IP «src-nat-pool-1».
Настройка NAT с использованием нескольких правил
1. Трафик из подсети 10.1.1.0/24 и 10.1.2.0/24 переводится в пул src-nat-pool-1.
2. Трафик из подсети 192.168.1.0/24 переводится в пул src-nat-pool-2.
3. Трафик с хоста 192.168.1.250/24 освобождается NAT.
Destination NAT
Перевод нескольких адресов на несколько
1. Трафик до пункта назначения 1.1.1.100 переведен на 192.168.1.100
2. Трафик на пункт назначения 1.1.1.101 на порт 80 переводится на 192.168.1.200, а порт 8000
Реальный IP-адрес и номера портов хостов настраиваются как целевой IP-пул. Прокси-ARP должен быть настроен для того, чтобы устройство отвечало на ARP для адресов в пуле IP.
Должны быть созданы политики безопасности, позволяющие трафик от untrust зоны до зоны trust. Поскольку назначения правил NAT назначения оцененный до политики безопасности, адреса, указанные в политике безопасности, должны быть реальным IP-адресом.
Перевод одного адреса на несколько
1. Трафик до пункта назначения 1.1.1.100 на порту 80 переводится на 192.168.1.100 и порт 80.
2. Трафик до пункта назначения 1.1.1.100 на порту 8000 переведен на 192.168.1.200 и порт 8000.
Двойной NAT
Перевод исходного адреса и адреса назначения
В этом примере передается исходный и целевой IP-адрес пакета. Хост назначения 10.1.1.100 является доступом к источнику 192.168.1.3 с использованием IP-адреса 1.1.1.100. Когда пакет обходит устройство SRX, IP-адреса источника и назначения.
Приведенная выше политика безопасности позволяет обеспечить доступ всех исходящих из зоны trust в зону untrust. В результате сервер имеет доступ к которому осуществляется посредством переведенного или не транслируемого адреса.
Политику безопасности можно изменить, чтобы разрешить доступ к серверу только через переведенный адрес. Ключевое слово “dropuntranslated” выведет весь трафик на целевой адрес 10.1.1.100. Это ограничит доступ к серверу с помощью адресf назначения 1.1.1.100.
Статический NAT
В этом примере хосту 192.168.1.200 присваивается статическое отображение NAT на IP-адрес 1.1.1.200. Любой трафик на адрес назначения 1.1.1.200 будет переведен на 192.168.1.200. Любые новые сеансы, происходящие из хоста 192.168.1.200 будет иметь исходный IP-адрес пакета, переведенного в 1.1.1.200.
Почему juniper vmx не поддерживает nat
Инструкция по пробросу портов на Juniper SRX
What is NAT: Source, Destination, and Static NAT on Juniper (Junos OS)
NAT is a service that can translate any address to any other address. NAT is needed on current IPv4 networks because of the limitations of public IPv4. Thus, some network segments can only use private IPv4, usually a SOHO network or maybe on a data center (it also possible) because of IPv4 stock limitations.
As we know, all computers in the world (called the internet) are connected to each other should have public IPv4. Your computer can only access the internet and can be accessed from the internet when your computer have public IPv4.
Maybe you will see your laptop or cellphone only have IPv4 private configured. But why they can access the internet? That’s because NAT is running on your home router or at your ISP.
What is Source NAT (Src-NAT), Destination NAT (Dst-NAT), and Static-NAT?
I think, these are the keys to distinguish them:
Source-NAT translates the source address.
Destination-NAT translates the destination address.
Static-NAT translates both, the source and the destination address.
Let’s look at an example of source NAT below. There is client that only have IPv4 private, and server that have IPv4 public. Traditionally, the client cannot access internet or accessed from the internet because on the internet, there is no routing table that leads to ipv4 private. So, request traffic from the client might reach the computer on the internet, but response traffic from the computer on the internet cannot reach the client.
The solution for this problem is source NAT. When the client initiates communication to the server. The router will translate the source address 10.1.1.2 to 200.1.1.100. Then create a related session. So, the return traffic from the server (internet) can reach the client.
Wait, are you using ip 200.1.1.100? When return traffic from internet, how do (devices on the internet) find out which device has an IP 200.1.1.100?
Good question! In Juniper, when you configure a NAT with pool-based IP, whether it’s source, destination, or static nat. You are required to configure the ARP Proxy. What is Proxy ARP? Proxy ARP allow Junos devices to respond to ARP requests that seek the owner of the IP address resulting from NAT translation (in the example above: 200.1.1.100).
In Juniper Device, Source NAT has two types of address mapping. Namely, interface-based and pool-based.
Interface-based: The source IP address translated to the IP address of the egress interface. PAT is required and enable by default.
Pool-based: The source IP address translated to spesific user-defined pool address. It can be used with or without PAT.
Source NAT on Juniper device also requires a match condition. There are traffic direction and packet information.
First layer is traffic direction. It is required to indicate the directoin of the packet. From where and to where. We can spesify the direction based on interfaces, zones. and routing-instance.
The second layer is packet information. This option can be used to indicate from who to who, and what kind of application. Packet information match criteria should include a source-address or destination-address. Additionally, these can also include source-port, destination-port, and protocol.
But should be noted. Source NAT only translate the source address. I know, maybe you see a destination address translation in the example above, that is, on the router when it receives a return traffic from server to the client (200.1.1.100 transleted to 10.1.1.2). But that happens because there is already a session that translates the source address (10.1.1.2 to 200.1.1.100).
However, the translation of desination address will not occur when the server initiates communication to the client (the server initiates traffic to the client). To do that we need a Destination-NAT, which can translate destination addresses of the first traffic.
Destination-NAT
Destination-NAT also requires match criteria of traffic direction and packet information, same as source-NAT. The difference is in the traffic direction, there is only from option to determine where the traffic is coming from. Also, in the packet information criteria. In destination NAT, all options of packet information criteria (source-address, destination-address, source-port, destination-port, and protocol) are optional, except destination-address. And PAT also available in destination-NAT.
Let’s look at an example of destination NAT below. Our case is we only have 1 public IPv4 from the ISP, that is, the IP assigned to the router’s outbound interface (200.1.1.1). But we want the web services that are running on a local server to be accessed from the internet. The local server doesn’t have IPv4 public.
Destination-NAT can be the solution for this problem. We will translate the http (port 80) traffic destined for 200.1.1.1 to ip 10.1.1.2 port 80. So, when a computer on the internet wants to access our website on a local server. They can access it on 200.1.1.1 port 80.
With this destination-NAT the source address of return traffic (from local-server to internet) will be automatically translated to ip 200.1.1.1.
But if local-server initiates communication to the internet, the source address will not be translated. If local-server wants to initiate communication to the internet, we need to configure source NAT on the router to translate IP local-server 10.1.1.2 to public IPv4.
Or we can configure a static NAT. So, the local-server can access to the internet and also can be accessed from the internet. Let’s look at an example of Static-NAT below.
Based on the illustration above, we will translate IP 200.1.1.100 to the local-server (10.1.1.2). So, the local-server can access to the internet, and vise versa. Yups, we don’t need configure source-NAT and destination-NAT. When we create a static NAT, it will translate the destination address x.x.x.x to y.y.y.y. On the other hand, the vSRX will automatically create a reverse static NAT to translate source-address y.y.y.y to x.x.x.x.
This session shows the destination address translated with static NAT.
This session shows the source address translated with static NAT.
We only need to configure Static-NAT, because when we create a static NAT, it will automatically create a Reverse Static NAT. So, the translation is bidirectional, both source address and destination address. Static-NAT also has one-to-one address mapping characteristics (but PAT is available).
The match criteria (traffic direction and packet information) are required in Static-NAT. Same as Destination-NAT. The destination-address match criteria is mandatory.
On Juniper device (Junos OS), static NAT takes precedence over source and destination NAT.
If you want to see an explanation about NAT in Juniper Device using Bahasa Indonesia. Check out the following video. Penjelasan NAT pada Juniper dalam Bahasa Indonesia, tonton video berikut.
Tags: nat, source nat, destination nat, static nat, what is the difference between source and destination nat, what is the difference between source destination nat and static nat, dst nat, src nat, what is difference between src nat dst nat and static nat, nat topology example, what is nat?, how nat works?, juniper static nat, juniper source nat, juniper destination nat, juniper dynamic nat, juniper nat, junos staic nat, junos source nat, junos destination nat, junos nat.
[Tutorial] Destination NAT (проброс порта)
Configuring NAT in Juniper SRX Platforms Using JunOS
There are 3 kinds of NAT for the JunOS SRX devices. Source NAT, destination NAT, and static NAT. We will also cover Proxy ARP. This post will only cover the basic and most common concepts and usage of NAT in SRX. But with this knowledge you should be able to do NAT for almost any occasion.
This post assumes you know the basic concept of NAT and what it is and why we use it and why we need it.
JunOS NAT packet processing
Consider the image below of how a packet is flowing through an SRX in regards to NAT. 
In order for the SRX to process the policies, it first needs to know what zone the packet is trying to get to. That is why the destination of a static NAT and destination NAT takes place first. After the policy is evaluated then the source of the static NAT or source NAT gets translated.
As you might have guessed from looking at the diagram, static NAT takes precedence over any other kind of NAT.
If there are overlapping NAT rules, the most specific (longest prefix length) is used.
Source NAT
This generally refers to outgoing NAT only. Traffic from within your company that has private IPs that needs to get out to the internet is source NAT’d to a public IP.
Note: This NAT is UNIDIRECTIONAL. Meaning, traffic will be NAT’d one way, and be able to reply back, but it will not NAT going the other direction.
The config to conduct source NAT would look something like this:
To create a NAT you must create a rule-set and a rule within that rule-set. Only one rule-set can be applied on a zone pair. Multiple rules can then be applied in that rule-set.
In the example above, the traffic coming from 192.168.0.0/16 that is destined for anywhere that is traveling from the DMZ zone to the UNTRUST zone will be source NAT’d to the interface of the UNTRUST interface IP address. In this particular case we are PAT’ing the traffic, also known as NAT overload. This is where many IPs can use the same single source IP as they are NAT’d through the firewall.
Then Source-NAT Options
In the NAT config above you see the then source-nat portion last. There are three options that can be added here. In the case above we use the option interface . There is also pool and off .
Pool Option
Suppose you don’t want to NAT to the interface but instead you want to use another IP. To first do that you must define that IP in a pool . The configuration would look like so:
Even if you only have 1 IP you still make a pool. Take note that the pool will either be defined a source pool or destination pool.
If you have over 64,000 connections going through the firewall into a single IP, you can have multiple IP addresses in the pool and the SRX will alternate between the IP addresses defined in the pool.
Off Option
It is possible to identify traffic that you specifically don’t want to NAT. This would be useful if you are NAT’ing everything coming from DMZ going to UNTRUST, but you didn’t want to NAT a specific flow that is supposed to go over a VPN tunnel. To conduct something like that you would use the off option. Here is an example:
Notice there are two rules. The first is called NO-NAT which specifically says source-nat off if the traffic matches the criteria. That is because this traffic is going over a VPN and we don’t want it to be NAT’d but everything else must be source NAT’d to the interface IP.
This is the Cisco equivalent to doing a NAT Zero, NAT 0, No NAT, or Identity NAT.
Destination NAT
Destination NAT is usually referring to incoming NAT. Specifically someone on the internet needs to access a device inside the network can be destination NAT’d to be reachable from the outside.
Note: This NAT is UNIDIRECTIONAL. Meaning, traffic will be NAT’d one way, and be able to reply back, but it will not NAT going the other direction.
This type of NAT is likely to be used for the outside public network to get to a webserver which has a private IP. As the traffic comes into the SRX the destination IP will have to be changed from the public IP to the real IP or private IP.
In the example above any traffic coming into the SRX on the UNTRUST zone that is destined for 199.199.199.199 will be destination translated to go to 10.10.10.10. Keep in mind, 10.10.10.10 can respond to this traffic due to the SRX being a stateful firewall, however if it initiates traffic it will not be source NAT’d to 199.199.199.199.
If there are multiple IPs in the pool, the SRX will load balance between the IP’s in the pool. Sending some traffic to each of the IPs in the destination pool. Considered the poor mans way to load balance.
Port Forwarding
Sometimes you want to do port forwarding. This would be classified as destination NAT. Here is an example of that.
In the above example, anyone coming into this SRX from the UNTRUST interface trying to get to 199.199.199.199 on port 8080, will be translated to go to 10.10.10.10 on port 80.
Static NAT
This type of NAT is bidirection. It is one to one. Specifically one public IP can be NAT’d to one private IP. This would essentially create a source and destination NAT all in one rule.
Note: This NAT is BIDIRECTIONAL. Meaning, traffic will be NAT’d both if it’s going out or coming in.
Because this is bidirectional, you would use this type of NAT if you’d like to map a public IP to a private IP to allow traffic to that IP to be destination NAT’d and traffic from that IP to be source NAT’d.
Proxy ARP
If you are doing NAT and the destination is not the IP address of the interface of the SRX, then you need to tell the SRX to do proxy ARP.
Imagine the firewall has a UNTRUST IP of 99.99.99.99 and is doing a static NAT for 99.99.99.88 to be NAT’d to 10.10.10.88. In this case next hop internet router will do an ARP to look for whoever owns 99.99.99.88. By default the SRX will not respond to this ARP request. Proxy ARP must be enabled for the SRX to say “oh, that packet is for me, here’s my MAC address”.
Here is an example of proxy ARP configuration:
Now the SRX will ‘listen’ for any ARP requests for 99.99.99.88 and 99.99.99.89.
Show Commands
Here are a few show commands to watch how NAT is taking place as it passes through the firewall.
show security flow session
show security nat source summary
show security destination source summary
What is NAT: Source, Destination, and Static NAT on Juniper (Junos OS)
NAT is a service that can translate any address to any other address. NAT is needed on current IPv4 networks because of the limitations of public IPv4. Thus, some network segments can only use private IPv4, usually a SOHO network or maybe on a data center (it also possible) because of IPv4 stock limitations.
As we know, all computers in the world (called the internet) are connected to each other should have public IPv4. Your computer can only access the internet and can be accessed from the internet when your computer have public IPv4.
Maybe you will see your laptop or cellphone only have IPv4 private configured. But why they can access the internet? That’s because NAT is running on your home router or at your ISP.
What is Source NAT (Src-NAT), Destination NAT (Dst-NAT), and Static-NAT?
I think, these are the keys to distinguish them:
Source-NAT translates the source address.
Destination-NAT translates the destination address.
Static-NAT translates both, the source and the destination address.
Let’s look at an example of source NAT below. There is client that only have IPv4 private, and server that have IPv4 public. Traditionally, the client cannot access internet or accessed from the internet because on the internet, there is no routing table that leads to ipv4 private. So, request traffic from the client might reach the computer on the internet, but response traffic from the computer on the internet cannot reach the client.
The solution for this problem is source NAT. When the client initiates communication to the server. The router will translate the source address 10.1.1.2 to 200.1.1.100. Then create a related session. So, the return traffic from the server (internet) can reach the client.
Wait, are you using ip 200.1.1.100? When return traffic from internet, how do (devices on the internet) find out which device has an IP 200.1.1.100?
Good question! In Juniper, when you configure a NAT with pool-based IP, whether it’s source, destination, or static nat. You are required to configure the ARP Proxy. What is Proxy ARP? Proxy ARP allow Junos devices to respond to ARP requests that seek the owner of the IP address resulting from NAT translation (in the example above: 200.1.1.100).
In Juniper Device, Source NAT has two types of address mapping. Namely, interface-based and pool-based.
Interface-based: The source IP address translated to the IP address of the egress interface. PAT is required and enable by default.
Pool-based: The source IP address translated to spesific user-defined pool address. It can be used with or without PAT.
Source NAT on Juniper device also requires a match condition. There are traffic direction and packet information.
First layer is traffic direction. It is required to indicate the directoin of the packet. From where and to where. We can spesify the direction based on interfaces, zones. and routing-instance.
The second layer is packet information. This option can be used to indicate from who to who, and what kind of application. Packet information match criteria should include a source-address or destination-address. Additionally, these can also include source-port, destination-port, and protocol.
But should be noted. Source NAT only translate the source address. I know, maybe you see a destination address translation in the example above, that is, on the router when it receives a return traffic from server to the client (200.1.1.100 transleted to 10.1.1.2). But that happens because there is already a session that translates the source address (10.1.1.2 to 200.1.1.100).
However, the translation of desination address will not occur when the server initiates communication to the client (the server initiates traffic to the client). To do that we need a Destination-NAT, which can translate destination addresses of the first traffic.
Destination-NAT
Destination-NAT also requires match criteria of traffic direction and packet information, same as source-NAT. The difference is in the traffic direction, there is only from option to determine where the traffic is coming from. Also, in the packet information criteria. In destination NAT, all options of packet information criteria (source-address, destination-address, source-port, destination-port, and protocol) are optional, except destination-address. And PAT also available in destination-NAT.
Let’s look at an example of destination NAT below. Our case is we only have 1 public IPv4 from the ISP, that is, the IP assigned to the router’s outbound interface (200.1.1.1). But we want the web services that are running on a local server to be accessed from the internet. The local server doesn’t have IPv4 public.
Destination-NAT can be the solution for this problem. We will translate the http (port 80) traffic destined for 200.1.1.1 to ip 10.1.1.2 port 80. So, when a computer on the internet wants to access our website on a local server. They can access it on 200.1.1.1 port 80.
With this destination-NAT the source address of return traffic (from local-server to internet) will be automatically translated to ip 200.1.1.1.
But if local-server initiates communication to the internet, the source address will not be translated. If local-server wants to initiate communication to the internet, we need to configure source NAT on the router to translate IP local-server 10.1.1.2 to public IPv4.
Or we can configure a static NAT. So, the local-server can access to the internet and also can be accessed from the internet. Let’s look at an example of Static-NAT below.
Based on the illustration above, we will translate IP 200.1.1.100 to the local-server (10.1.1.2). So, the local-server can access to the internet, and vise versa. Yups, we don’t need configure source-NAT and destination-NAT. When we create a static NAT, it will translate the destination address x.x.x.x to y.y.y.y. On the other hand, the vSRX will automatically create a reverse static NAT to translate source-address y.y.y.y to x.x.x.x.
This session shows the destination address translated with static NAT.
This session shows the source address translated with static NAT.
We only need to configure Static-NAT, because when we create a static NAT, it will automatically create a Reverse Static NAT. So, the translation is bidirectional, both source address and destination address. Static-NAT also has one-to-one address mapping characteristics (but PAT is available).
The match criteria (traffic direction and packet information) are required in Static-NAT. Same as Destination-NAT. The destination-address match criteria is mandatory.
On Juniper device (Junos OS), static NAT takes precedence over source and destination NAT.
If you want to see an explanation about NAT in Juniper Device using Bahasa Indonesia. Check out the following video. Penjelasan NAT pada Juniper dalam Bahasa Indonesia, tonton video berikut.
Tags: nat, source nat, destination nat, static nat, what is the difference between source and destination nat, what is the difference between source destination nat and static nat, dst nat, src nat, what is difference between src nat dst nat and static nat, nat topology example, what is nat?, how nat works?, juniper static nat, juniper source nat, juniper destination nat, juniper dynamic nat, juniper nat, junos staic nat, junos source nat, junos destination nat, junos nat.