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

5. Destination NAT

Welcome to this video. On the second type of Nat configuration, known as the destination net, If you found the concept of “source Nat” interesting, I promise you this is going to be even more interesting. In this lecture, we’ll talk about the concepts and the working mechanism of the destination net. And in the next lecture, we’ll understand how to configure that. So what is destination.net or what is it used for? Destination net is used to translate the destination IP address of a packet. This is commonly used to translate packets destined for a public address to a private address inside the network. For example, you may have a web server within the DMZ zone of your network.

And that web server needs to have a public IP address so that users on the Internet can connect to it. So when users on the Internet connect to the public IP address, that public IP address is the destination address of that packet. We can translate that to a private IP address assigned to the server. So destination Nat is used to translate the destination IP address of a packet. This type of NAT configuration only allows incoming connections. We saw earlier that source Nat only allowed incoming connections. Destination Nat, on the other hand, only allows incoming connections. Let’s understand this with an example. So here we have the SRX device. On the left side, we have a server, and on the right side, we have the Internet. Now users on the Internet are going to access the server with a public IP address. So the original destination of that server is going to be a public IP address.

As the packet crosses the SRX device, it will translate the destination IP address from a public IP address to a private IP address. Let’s look at some common uses for destination networks. Destination net is commonly used to translate a destination IP address to another address, like we just saw right now. It can also be used to translate a destination’s IP address and port number to another destination’s IP address and port number. and we’re going to take a look at an example. When we configure a destination network, the ports don’t have to be the same, meaning the untranslated and translated port numbers can be different. So it could be possible. A user on the Internet may try to access his public IP address on port 80, but when you perform a destination net, you can translate that port number to something else, maybe 80 80. So it doesn’t have to be the same port number before and after the destination net. Let’s understand this further with an example. So here we have an SRX device. On the left side, we now have three servers.

We have a Web server, a mail server, and an FTP server. And, as you may be aware, each of these uses a different port number. The web server responds on port 80. The mail server responds on port 25, and the FTP server responds on port 21. Now, as an organization, we only have one public IP address. And with that one public IP address, we need to map all three servers. So Internet users will only be able to access 200 dot one, dot one, the public IP address that we’ve been assigned. And based on the port number that they access, we will decide where the request must be forwarded to. So if they access 200 dot one on port 80, we’ll forward that to the Web server.

If they access 201 on port 25, we’ll forward that to the mail server. And if they access port 201 on port 21, we’ll forward that to the FTP server. So essentially, we’ve translated one public IP address into multiple private IP addresses. So here’s what the translation is going to look like: The untranslated destination is number 201 one. The untranslated port is port 80. Users are trying to access the web server. The translated destination is 101, and the translated port is 80. Now, like we discussed earlier, the translated port and the untranslated port do not have to be the same. It could be possible that users may be accessing the application on port 80, but internally the application may be responding on a different port number. So we could configure that as well. Similarly, when users access 201 on port 25, we translate that to 101120 on port 25. Moving on. Another common use case is to translate a contiguous block of addresses to another contiguous block of addresses of the same size. Now, let’s talk about the different types of destination networks.

And really, there’s only one. Unlike sourcenet, where we had interface-based and pool-based Nat, destination net only supports one type, and that’s pool-based Nat. We know what a pool is. A pool is a set of IP addresses used for translation. And since this is the only supported type for destination net, even if you’re translating a single IP address, you have to define that within a pool. The pool-based network supports translation of the original destination IP address to an address from a user-defined pool. Pat is not performed in this case. We are simply translating one destination IP address to another destination IP address. If the range of untranslated addresses is larger than the pool, untranslated packets will be dropped. Essentially, what this means is that the pool size of untranslated addresses should be the same as that of translated addresses. If you have more untranslated addresses than translated addresses, the ones that haven’t been able to be translated because of a lack of addresses are going to be dropped.

So you want to make sure that the size of untranslated addresses is the same as the size of translated addresses. Also, it supports translation of the original destination IP address and port number to a specific IP address and port number, which is what we were talking about earlier. We can have the incoming packet arrive on port 80, but we can translate that to another port number. And that is an example of where patis, or port address translation, is performed. Now we’re going to look at both of these examples when we configure destination NAT. When talking about the configuration of destination NAT rules, we need to provide two pieces of information. The first one is traffic direction, and unlike sourcenet, where you can provide from-to information, with destination NAT, you’re only going to provide from-to information. So you can provide from the interface,  from a zone, or from a routing instance. Now you might wonder, “Why are we not providing information?” The reason for that is that when you perform destination networking, the destination address is going to change, which could change the destination interface and the destination zone of the packet.

So we don’t specify the to information; we only specify the from information. The second piece of information that we need to provide is packet information. This allows the SRX to determine which packets should be translated. So we can provide source and destination IP addresses, source and destination port numbers, and protocol information to match packets for the destination net. Talking about the actions that we can configure, there are only two actions. The first is to use a pool-based net. And like we discussed earlier, even if you are translating to only one IP address, you must define that within a pool. And the second action is to turn it off. That is, you do not wish to perform destination net. Now here’s an example of what the configuration looks like. So, under Edit security net, we’re reconfiguring the destination net in the same way that we did the sourcenet. We will start by defining a rule set. The rule set only supports defining from information, such as a zone, an interface, or a routing instance. And then we specify a rule. The rule contains match conditions to identify which packets should be applied to the destination network and the clause that defines which pool of addresses should be used or if the destination network should be turned off.

Now, if you have overlapping destination NAT rules, the most specific rule will take precedence. For example, here we have overlapping rules. On the left side, we have a rule set called Rs 1, and on the right side, we have a rule set called Rs 2. The configuration on the left matches the zones, so we are matching on the zone. The configuration on the right matches the interface. The rest of the configuration is almost similar. We are matching any packet that is destined for 201 one. The same configuration is over here. The rule on the left says if that is a match, the destination NAT should be performed with the pool destination NAT pool one. But the rule on the right says the destination NAT should be performed with the pool destination NAT pool two. If you have overlapping rules like this, the rule that is more specific will take effect. Because the interface is more specific than the zone, and the zone is more specific than the routing instance, the one with the interface in the firm condition will take the lead in this case. The one thing we’re going to talk about is where in the packet flow does destination NAT fit in?

So here we have the ingress packet. When it arrives at the SRX device, it checks to see if it matches an existing session. If it does, it will take the fast path. but if it does not, it goes through some screen checks. It then checks for a static NAT configuration, and it then checks for a destination NAT configuration. So, as you can see here, the destination national evaluation occurs before route lookup, zone lookup, and policy lookup. And as you can imagine, there is a reason behind that. Because destination NAT changes the destination IP address, that could change the route that needs to be used to forward the packet. If the route changes, the outbound interface of the packet will change. And if the interface changes, so will the outbound zone, which is why destination nati uses route and zone lookup. All right, so that’s about the concepts of destination networks. The key takeaway here is that it is a mechanism that allows you to translate the destination IP address of a packet. And there’s only one type of destination network that you can define, which is pool-based networking. In the upcoming lecture, we’ll look at a configuration example for destination NAT.

6. Configure Destination NAT

Now that we’ve understood the concepts of “destination net,” let’s understand how to configure this on the SRX device. First, let’s take a look at the configuration scenario. So we have the SRX device, and behind the SRX device in the DMC zone is a server whose private IP address is 101 10 Now we have users on the Internet. They’re going to be connecting to the server using a public IP address. The public IP address is 1150, and as the packet crosses the SRX device, we’re going to apply the destination net and translate that public IP address into the original private IP address of the server. So on the untranslated packet, the destination address is 11:50, and as the packet crosses the SRX device, the destination address will be translated to ten 1110.The server is already up and running, and it has been configured to respond to ping requests and requests on port 80 and port 22. So we have multiple applications with which we can test the destination NAT configuration. Now let’s get to the terminal of the SRX device and see how to configure it.

All right, I’m here at the terminal of the SRX device. We are first going to navigate to edit security net, and let’s begin with the show command. So we’ve got no configuration here. Let’s navigate to edit destination because we’re configuring destination net, and we’ll start by defining a pool. So insert a question mark in the space. Because the keyword is “pool,” we’ll just call this “pool.” One question mark The keyword we are looking for is address (question mark). And now we can type in the IP address. Notice that we also have the option to provide a range using the two keywords. But right now we are only going to provide a single IP address. And here we will provide the translated IP address or the server’s real address, which is 10 1 100:32. Let’s do a show. So that’s our pool configuration. Now, to perform the destination Nat, we need to define a rule set. So, let’s add a space question mark to the edit space. The keyword is “rules set,” and let’s give this a name. Let us simply refer to this as Rs 1, or Ruleset 1. Under the rule set, we need to provide traffic information. So let’s use the setspace command with a question mark. And the keyword we are looking for is “question.” As a result, we can use it from the interface, the routing instance, or the zone. Right now, let’s do it from the zone. The request is going to come from the Internet. So that means the packets will be arriving in the untrusted zone. So set Zone Untrust, and then we need to configure a rule. So let’s do that edit rule, and let’s provide a rule name. Let’s just call this one as R One.

Press Enter. Now we are in the specific rule configuration mode, and we need to provide matching information for the packets on which we need to apply the destination net. So let’s begin with the setspace question mark. We’ll use the match keyword here to set the match questionmark, and as you can see, there are multiple criteria that we can use to match specific packets. Now in our configuration scenario, we want to apply the destination net to any packet that is bound to the address 1150. So we want to match any packet that is destined for 1150. So we’ll say “set match,” “destination address,” “question mark,” and here we’ll provide the destination address, which is 1150 32. If you wanted to lock it down to specific port numbers, you could do that with the destination port option here. Or you could also use the protocol information. Right now, we’re only going to match the IP address. So set the destination address. We then need to define the then statement. So, first set, then question mark. The only option we have available here is destination (net question mark. We have two options. We can turn off Nat or define a destination network using a pool. So we’ll use the pool keyword, and we’ll provide the pool name. So let’s go up one level, two levels, and let’s do a show. So we’ve defined a pool, and we’ve defined a ruleset that matches traffic coming from the untrusted zone. And then we have a rule that looks for all packets destined for this IP address. Pool one is used to configure the action for destination Nat. Now there’s one more configuration that we need to apply here, and that is proxy ARP.

And the reason for that is that this IP address here, 1150, does not belong to any interface, as we understood in the lecture on sourcenet. For communication to happen, that IP address must resolve to a Mac address. In this case, the IP address is not assigned to any interface. So no interface is going to respond when an ARP request comes in. And as a result, the IP address cannot be resolved to a Mac address. So we’ll set up proxy ARP on the interface where this packet will arrive so that it can respond to the ARP request. So let’s do that. Let’s do a setspace question mark. In fact, that’s not under this Iraqi administration. So we need to go one level up—that’s under “Edit security net setspace question mark.” The keyword we are looking for is “proxy ARP question mark interface.” Now we need to provide the interface name on which a packet with that destination address will arrive. Now, according to my topology, that interface is feet, which belongs to the Untraz zone because traffic is coming from the internet, so it will arrive on the intra zone, and the interface that is bound to the Untrazone is festion mark address, and we must provide the IP address. So that is eleven (1152). Press Enter. This interface will now respond when the SRX device receives an ARPrequest for this IP address. So from a natural perspective, that’s all the configuration we need. We need a poll definition, we need a ruleset, and we need a proxy ARP configuration.

Now there’s one more thing that we need to do, and that is configure a security policy. because the Nat definition only defines what IP addresses to translate. But Nat cannot decide if the packet should be allowed or not. That is the function of the security policy. So let’s quickly configure that. I’ll go up one level, and we’ll say “edit policies.” Now the packet is going to arrive in the untrusted zone. The next keyword is zone, and the final definition of the packet is in the DMZ zone, the zone where the server is sitting, question mark. And we need to provide a policy name. Let’s just call this “untrustworthy” to DMZ. So we’re now in the policy configuration mode. We’ll define the source and destination addresses. So set the match source address. The packet could be coming from any source address on the internet.

So we’ll set that to any. Next, we need to match the destination address. Set the match destination address, and we need to provide the address of the server. Now I’ve already configured that address in my address book. So I’m going to add that over here. Eleven (1150) and 32 That is an address that I’ve defined in the global address book, and then we can match the application. Now we can be very specific in terms of what applications we want to allow.

So if it’s a web server, you may choose to allow only HTTP or HTTPS. If it’s a DNS server, you may choose to allow only DNS traffic, and so on. But right now, we’re going to keep it very simple. “Set match application any,” we’ll just say. We’ll say “set,” then “permit,” and we’ll also “log.” So configure it, then sign in and add a session to it. All right? So that’s all the configuration that we need. We’ve configured destination Nat, we’ve configured proxyARP, and we’ve configured the security policies. Let’s go to the top and commit the changes. All right, so commit has been completed, and now it’s time to test. So I’m going to hop over to my terminal window, which is over here, and from here I’m going to ping the server on its public IP address or its untranslated IP address. So let’s do that. Ping 1150 and that’s not working. So let’s go back to the SRX device and see what’s going on here. So let’s go edit the security net. Let’s do a show. We’ve got a pool configuration, we’ve got a rule set configuration, and we’ve got the proxy ARP as well. And we already have the policy defined here. What do you think could be the issue? We’ve configured everything, but it’s not working.

I’m going to give you a hint. The answer lies in this diagram. So, take a moment, pause the video if necessary, and try to figure out why destination net isn’t working. All right, I’m going to give you the answer. Let’s first go back to the terminal here and take a look at the policy that we configured. So revise policies. And if we do a show here, notice that the policy is from the untrust zone to the DMZ zone. It is matching any source address, and it’s matching the untranslated destination IP address. Now let’s go back to the traffic flow diagram.

So when a packet comes in, it’s going to go through the screen configuration, static Natif configured, but that’s not the case here. Then there’s the destination net. Now, when this is applied, the destination IP address of the packet is going to be translated. which means in our case, the destination address before the net was eleven 1150.Now, the destination net has been applied. So the destination address now is 101, 10. And by the time the policy lookup happens, the destination address has already been changed. So the policy should be configured to look for this translated address. The destination address that the policy should match is the translated address, not the untranslated address, because destination net has already taken effect. So if we go back over here, this is the configuration that is causing the problem. We need to change that to the translated address of that packet.

Let’s quickly do that. So change zone untrust to zone DMC, policy untrust to policy DMC, and set match destination address. And I’ve already configured an address object for the translated address. I’m just going to call that 10: 11: 10: 32. And we also need to delete this. As a result, remove match destination address 1150. If we do a show now, it looks good. The translated address matches any source or destination address. So let’s commit now. All right, so the commitment has been completed. Now it’s time to test. So let’s ping eleven1150, which is now operational. Okay, let’s try to test on some other port numbers because the server has also been configured as a web server and it also accepts incoming SSH requests. So let’s also try that SSH 11 or SSH username. At eleven.150. Press enter. It is responding, and it is asking me for a password.

So that’s working fine. And to test the access on port 80, I’m going to use the curl utility. We could use a browser, but it’s just easier to use curl. So, eleven and 1150. And that shows me the configuration of that web page. As you can see, it’s a really simple web page there. So it’s all working. Now let’s go back to the SRX device and perform some verifications. Now we’ll keep the ping running for a little while so we can see that traffic back over here to the SRX device. Let’s quickly go to the operational mode, and we’ll show the security net destination and take a look at pool one. Okay, so we can see there have been a lot of translation hits over there.

We can also do a security flow demonstration. and that’s also going to show us the translation. So we can see here where the IP address is coming from. We’re trying to access server 1150, and you can see the response packet there; it is coming back from server 1110. Now we could also show the security net destination, and we can take a look at the rule. We’ll just say that all rules apply here as well. We’ve got quite a few translation hits, and the last thing we’re going to check is the log. So we’ll show the log and the traffic log, and we’ll look at the last portion of the log, and here we can see the translation happening. So that’s my starting point, and I’m attempting to connect to eleven1150, which is then translated to ten 1110. Okay, let’s go back over here and terminate that ping. Now the reason this has stopped working is because the server, which is sitting right next to me, has shut down, and I’m just going to power it on again, and we should see the ping responses come back. All right, there you go. Okay, so we’re going to close the ping session and we’re going to perform some more configuration back over here. Let’s take it a step further. So let’s go back to configuration mode and add some port information there.

So let’s go ahead and edit security and destination. And if we do a show here in this configuration, we are performing a translation for any port number. Let’s limit this to a specific port number only. We’ll change the rule set edit rule set Rs 1, and we’ll change the rule R 1, and we’ll say set match destination port 80. And if we do a show now, we are not only matching the destination address; we are also matching the destination port. So that means the destination net is only going to apply if both of these conditions are met. All right, let’s commit.

Okay, so that’s complete. Now let’s go back to the terminal and perform some verification. Let’s do curl 11/1 on port 80, and that works. But what happens if we try to SSH? So let’s do SSH username at 11:50, and that’s not going to work because we’ve specifically defined that the translation should only occur if the packet is bound to port 80. So let’s go back over here and see what’s happening in the logs. So display the log log name or log file name, which is traffic log, as well as the last portion of that log. And here we can see that this is the translation that occurred. We attempted to access 1150 on port 80, which was automatically translated to 10 on port 80. So it automatically picked up that port number for the translated IP address. Now, it doesn’t have to be this way.

Like we discussed earlier, it could be possible that here we have a different port number and here we have a different port number. In fact, let’s give that a try. So let’s start with a show here. Let’s change that definition to destination port 80 80.So “set match destination port 80” will be used. And if we do a show here, then that’s been changed. Now let’s also add a port definition within the pool itself. So let’s go up and edit the pool. Pool one should be edited. If we do a show here right now, we do not have any port information configured, but let’s do that. Assume you set address 10: 11:10:32. And we’re going to add a port number here. For this one, we’re going to add port 80. So essentially what’s going to happen is when somebody tries to access this IP address on port 80, the SRX will translate that to this IP address on port 80. Let’s go up one level and just do a show to make sure everything is fine. It looks all right. Let’s commit. Okay, let’s go back over here, and let’s do curl 1150. And this time we’ll use port 80 to connect. and that works perfectly. Now let’s go back and check the logs. So run “Show Log” or let’s clear the screen first. Okay, run show log and print the name of the log file as well as the last portion of the output.

And here we can see that we tried to access on port 80, which has been translated to 1011 on port 80. As you can see, this serves a really, really powerful use case. Imagine a situation where we had to make some changes to the application and that feature was no longer available on that application. We now have the application responding to web requests on, let’s say, port 80. For example, for the end user, nothing has to change. They can continue to access this IP address on port 80 80.We can simply change the port definition or the port configuration to translate that to 1011 on port 8000. So even though we’ve made a change to the application, the end user doesn’t have to be aware of that. They can simply continue to access the server on the same port number they’ve always been using. All right, so that’s how you configure destinationnap. The most important takeaway from here is is that when you’re configuring a security policy, make sure you’re matching the translated address as the destination address in your security policy. Because in the traffic flow diagram we’ve seen, security policy lookup happens after destination networking. So by the time the security policy is looking at a packet, the destination address has already been translated. So when you configure the security policy, the destination address should be looking at the translated address, not the untranslated address.