Juniper JN0-230 JNCIA Security Associate – Network Address Translation Part 4

7. Static NAT

Welcome back. Let’s now talk about the third type of net, which is known as a static knit. In a way, static net is a combination of sourcenet and destination net. Since we’ve already understood what sourcenet and destination net are, it should be very easy for us to understand the concepts of static NAT. Static netting creates a one-to-one mapping of one IP subnet to another IP subnet. It allows source address translation in one direction and destination address translation in the reverse direction. So let’s understand this with a diagram. So here we have an SRX device. There’s a host on the left and the Internet on the right side. We spoke about sourcenet earlier. When the host sitting behind the SRX device initiates a connection outbound to the Internet, the source address is translated as it leaves the SRX device. And we also spoke about destination address translation.

When a device on the Internet wants to reach a host sitting behind the SRX device, we translate the destination IP address of that packet. Now these two types of NAT, source and destination, only allow communication in one direction. So source NAT only allows communication in the outbound direction, and destination NAT only allows communication in the inbound direction. A combination of this is called static nat, meaning it applies source nat translation in the outbound direction and destination nat translation in the inbound direction.

A common use case for this is with servers that are sitting in the DMZ. So if you have a web server sitting in the DMZ, you will need to allow inbound connections because users on the internet will need to access the server. So that is the case when you want to translate the destination address. But it could be possible that the server also needs to initiate connections outbound, maybe to download some updates. So the server needs to reach the internet as well. So static NAT will also allow the server to initiate the connection towards the Internet.

That is a very common use case for static netting. Whenever you want to have translation applied in both directions, you’ll configure static NAT. Let’s explain this with IP addresses. So here we have the SRX device. On the left, there is a server with the number 101. And we have an internet host with the IP address 2 2 2. On the SRX device, we have configured static NAT. So ten one 10 is being translated to three three three. Now let’s say the host on the internet wants to access the server sitting behind the SRX device. So when the host initiates a connection, the packet is going to look like this:

The source IP address is the address of the host, which is all tools, and the destination IP is the public IP address of the server, which is essentially a translated address. So the host is trying to access three three. The source address will remain the same as the packet passes through the SRX device, but the destination IP will be translated to 10 1110. Now, when the server responds back, these addresses will be flipped. The server 10 1110 is now the source, and the destination is 2 2 2. As the packet leaves the SRX device, the source address will now be translated. The source address is now three, and the destination IP is two, two, two. Now, looking at this, you may think, “Is this not the same as destination net?” The answer is yes; it is the same as destination net. But this static network is also going to apply if the server initiated the connection. So it’s not only allowing connections in the inbound direction; it’s also going to allow connections in the outbound direction. very important to keep in mind. Static native translation is always one-to-one. So you translate one IP address to another, or you translate one block of addresses to another block of the same size. For each private IP address, a public address must be allocated, and with static NAT, we do not need to configure an address pool. Port address translation is supported, so we can translate the port when the packet is being translated. Now let’s talk about configuring static NAT rules. Just like with destination NA, we need to provide two pieces of information.

The first one is traffic direction, and in this case you’re only going to provide it from information, meaning from the interface, from a zone, or from a routing instance. The reason we do not provide two pieces of information is because static can change the destination of the packet. As a result, we do not provide two types of information; we only provide one type of information. And the second piece of information required to configure the network is packet information.

We need to provide packet matching information so the SRX can know which packets qualify for static NAT translation. And we can provide this information by configuring source and destination IP addresses or source and destination port numbers. Make a note that with staticnet, we do not provide protocol or application information. Here’s an example of static network configuration, which is very similar to source or destination network. So we’re configuring a static net under edit security net. We configure a rule set that specifies where the traffic is coming from, in this case, the untrusted zone. Then we configure a rule to provide packet matching information. In this case, we’re saying that the packet’s source can be anything and its destination is a specific IP address. In the then statement, there is no pool here.

So we are saying “static Nat” and converting that to this prefix here. The last thing we’re going to talk about is the packet flow on the SRX device. So when a packet comes in, the first thing the SRX is going to do is check if it belongs to an existing session. If it does not, it will check for screen configuration, and the next thing that is applied is static NAT.

As a result, static NAT is used before the destination network and before the source network. And also, keep in mind that policy lookup occurs after static NAT, which means that by the time the packet is going to match against a policy, the destination IP address of the packet may have already changed. So when you’re configuring a policy or when you’re reconfiguring a security policy, you only need to include the translated destination address because static NAT will translate the destination address of the packet. That concludes our discussion of staticknat concepts. The key takeaway here is that it’s a one-to-one translation between two IP addresses, and it performs two types of translation: source address translation in one direction and destination address translation in the reverse direction. In the next lecture, we’ll understand how to configure this on the SRX device.

8. Configure Static NAT

It’s now time to configure static Nat on the SRX device. Before we jump into the terminal and start configuring, let’s take a look at the configuration scenario. So here we have the SRX device, and on the right side, which is the DMZ zone of the SRX device, we have a server whose private IP address is 101 10 On the left side is the Internet, which is connected via the untrust zone of the SRX device. The public IP address that we will assign to the server is 201 150.

So, when an Internet request comes in to access the server, static Nat will be in charge of translating the destination IP address to 10 1110. So this is what will happen when the request first comes into the SRX device: the destination IP address is 201 150, and as the packet crosses the SRX device, the destination address will be translated to 101 10. Now, since it is static NAT, the reverse should also be true, meaning the server should also be able to access the Internet. So when the server makes a request to access the Internet, static Nat will be responsible for translating the source IP address of the packet. So when the packet comes in on the SRX device, the source address is private IP addresses 1000 and 110. The source address will be translated to 201 150 as the packet passes through the SRX device. Now, let’s get to the terminal and see how to configure this. All right, I’m here at the terminal of the SRX device. We’ll first enter the Edit security net, and we’re going to perform static NAT. So let’s do some editing, and let’s start with a question mark. The keyword we are looking for is “static.” So edit the static.

Now, just like source NAT or destination NAT, we need to begin by configuring a rule set. So, let’s add a space question mark to the edit space. The keyword is “rules set.” We need to provide a name. Let us simply refer to this as Rs 1. Press Enter. So we’re now in the rule set configuration mode. Let’s use the set command and provide the firm information, which means where the traffic is coming from. We could provide an interface, a routing instance, or a zone.

Let’s set the zone from zone, and the packet will come from the untrusted zone. Set from the zone of distrust. Now we need to provide packet matching information by configuring a rule. So let’s start with the edit space question mark. The keyword is rule, and we need to provide a rule name. Let’s just call it as R One. Now we’ll provide some match conditions. The keyword is match, with a question mark. You can provide source and destination IP addresses or source and destination port numbers. But we do not have the option to provide protocol information. Set the match, and then proceed to the destination address. And here we’re going to provide the public IPaddress because when traffic is coming in from theuntrust zone or from the Internet, it is goingto be destined to the public IP address. As a result, 200 dots, one dot 1150 slashes 32. Okay, let’s do a show. We now need to configure the next part.

So put a question mark there. There’s only one possible option: static nat. Question mark. Now we have a couple of options that we can use. We can use a prefix, and we can provide the IP address. Or if we have configured the IP address as an entry in the address book, we could use the prefix name. Right now we’re only going to use the prefix, and we’ll type in that IP address. So the IP address of the server is 10, 1110, 32. Let’s go up a couple of levels, and let’s do a show. All right, that configuration looks good. The next thing we need to configure is the proxy ARP.

And now we know the reason why we need to configure proxy ARP: this IP address is not assigned to any interface or any host. So when an ARP request comes in for this IP address, there is going to be no response because nobody owns this IP address. So we’ll configure this on the interface that’s linked to the untrust zone. So when an ARP request comes in for this IP address, the interface will respond on its behalf of that. Let’s do that. Let’s go up one level, and let’s say you set a proxy ARP. Make a note that this is configured under edit security, Nat. So, question mark, configure proxy ARP. The keyword is “interface question mark.” We need to specify the interface. In this case, it is f. That’s the interface that’s tied to my “untrust zone” question mark. The keyword is address. And we want the interface to respond to our requests for this address. 201, 152.

All right, so that’s all from the NAT configuration perspective. Nat will only translate the addresses, so we’ll need to configure security policies next. It’s the security policies that will determine whether traffic is going to be allowed or not. Now, for static Nat, we need to configure two policies. one policy that allows inbound connections, and another policy that allows outbound connections. So far, we’ve only configured one policy for source Nat and one policy for destination Nat. And that’s because those two types of Nat only allow communication in one direction. But static Nat allows communication in both directions. So we need to configure two policies. So let’s go up one level. From here, we’ll say “edit policies,” and let’s first create the policy from the DMZ zone to the untrusted zone. This policy will allow the server to reach the Internet. As a result, change policies from zone DMZ to zone untrust. And we need to provide a policy name. Let us refer to this as the “DMZ” for distrust. Okay, so now we are in policy configuration mode. Set the match source address. The source address should be the untranslated address of the server, which is ten one. Press Enter. Now the reason I’m able to use the iPad address over here is because I’ve already configured this as an address book entry, and that is the name of my address book entry. Let me quickly show you the configuration. So that’s the top-level security address book, and you can see that over here under the global address book I’ve defined an address called Ten One Maps for the same IP address, which is why I’m able to use that in my security policy.

So make sure that you already have the address defined in your address book. So we’ve matched the source address. Now we need to match the destination address. Set the destination address to any because the server could access any address on the Internet. Set Match Application You could limit this access to specific applications, but for now, let’s keep it simple and say set, then permit, set, then log into the session in it. All right, let’s perform a show. So that policy looks good. We must now define one more policy that will allow traffic to flow from Untrust to DMZ. So let’s use the edit command from zone untrusted to zone DMZ, and we’ll provide a policy name. Let’s call this untrustworthy behaviour toward the DMZ, and we’ll get you the rest of the information as soon as possible. Set Match Source Address to any because any host on the Internet could attempt to connect to the server.

Set Match Destination Address, and here we need to provide the translated address of the server because, keep in mind, policy evaluation or policy lookup happens after static Nat in the packet processing flow. So by the time the policy is looked up, the destination address has already been translated because staticknat is applied right at the beginning of the packet flow. So we need to provide the translated address.

This is similar to what we saw while configuring the destination ad. So Match destination address is 10 1100:32; Match Application is set to This will be set to any except in a production network. You may not want to configure it this way. You may want to lock it down to specific applications that are allowed on the server. Set then permit and Ven log in the session. Let’s go up a couple of levels, and let’s do a show. So we have a policy from the DMZ to Untrust and a policy from Untrust to the DMZ. Let’s start at the top and do a quick show-pipeline comparison to see what’s changed. As a result, we’ve added static Nat configuration. We’ve also configured a proxy ARP and configured a couple of security policies. That looks good. Let’s go ahead and commit the changes. All right, so the commitment has been completed. It’s now time to put everything to the test. So I’m going to hop onto another terminal window.

And from here, I’m going to ping the server’s IP address. And this device that I’m performing a ping from is sitting in the untrusted zone of the firewall. So ping 201 150 and press Enter. So that’s working. Let’s go back to the SRX device and perform some verifications from here. So the command is “run show security nat question mark.” The keyword is “static question mark rule.” We can provide a rule name or use the all keyword. Let’s do all of them. And we can see that we have some translation hits here. We could also do a run-show security flow vice that I’m And that’s also going to show us the packet translation. So here we can see that this is my IP address. I tried to access the server using the public IP address 201 150.But when the response is coming back, it is responding from 111, the translated address, and it’s responding to my computer. We can also see this from the log file. So let’s do that. Run the show log and the traffic log. And let’s look at the last portion of the log. Okay, we’re going to look at the last line over here. So 201 150 is the original source address we attempted to access: 11 1 10. The packet has been translated. The source address remains the same, but the destination address has been translated to 10 1110. So this confirms that Nat is working in one direction, from the untrust zone to the DMZ zone. Now it’s time to test in the other direction. So let’s go back over here, and let’s terminate the ping. We’ll come back over here, and I’ll clear my log file. Run a clear log of traffic log. Now we’re going to perform a ping from the server, and we won’t see it here because that’s a different machine.

The machine is sitting right next to me. I’m just going to initiate a ping from there, and we’ll see the output on the SRX device. Okay, so I have the ping going. Let’s start with the Run show security flow session. Okay. And here we can see that the server is initiating a ping of 10 1110 towards my computer, 11 110. And when the response comes back, take a look at how “10, 1110” is now being translated to “200.” Dot one, dot one, dot 50. Let’s also take a look at the log. So run show logs and traffic logs. Let’s look at the last portion of that output. And here also, we can see that 1011 is trying to ping 1110. The source address is being translated to 201 150.All right, so that’s how we configure static NAT. As we saw right now, the configuration is almost identical to what we would do with a source or destination network. The major difference here is that when you’re configuring the security policy, you need to allow traffic in both directions, and that’s because static NAT allows connections to be initiated from both directions. From an examination standpoint, all three Nat configurations are important. So make sure you’ve understood the concepts well and that you’ve also performed some configuration examples to reinforce the concepts.